[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V3 04/23] xen/ioreq: Make x86's IOREQ feature common




On 07.12.20 13:41, Jan Beulich wrote:

Hi Jan

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/asm-x86/hvm/ioreq.h
+++ b/xen/include/asm-x86/hvm/ioreq.h
@@ -19,8 +19,7 @@
  #ifndef __ASM_X86_HVM_IOREQ_H__
  #define __ASM_X86_HVM_IOREQ_H__
-#define HANDLE_BUFIOREQ(s) \
-    ((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
+#include <xen/ioreq.h>
Is there a strict need to do it this way round? Usually the common
header would include the arch one ...
The reason was to make a bunch of x86 files (which included asm/hvm/ioreq.h so far) to not suffer from moving IOREQ interface location and as the result to limit the number of files which needed touching. If a common rule is to another way around, I will follow it. So will change to include arch header from the common one. Or even will include arch header only where it is required (common ioreq.c right now and Arm io.c in future).


@@ -38,42 +37,6 @@ int arch_ioreq_server_get_type_addr(const struct domain *d,
                                      uint64_t *addr);
  void arch_ioreq_domain_init(struct domain *d);
As already mentioned in an earlier reply: What about these? They
shouldn't get declared once per arch. If anything, ones that
want to be inline functions can / should remain in the per-arch
header.
Don't entirely get a suggestion. Is the suggestion to make "simple" ones inline? Why not, there are a few ones which probably want to be inline, such as the following for example:
- arch_ioreq_domain_init
- arch_ioreq_server_destroy
- arch_ioreq_server_destroy_all
- arch_ioreq_server_map_mem_type (probably)


--
Regards,

Oleksandr Tyshchenko




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.