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
