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

[Oleksandr <olekstysh@xxxxxxxxx>]

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