Re: [RFC PATCH V1 01/12] hvm/ioreq: Make x86's IOREQ feature common

[Oleksandr <olekstysh@xxxxxxxxx>]

On 05.08.20 19:15, Andrew Cooper wrote:

Hi Andrew

> On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index 06881d0..f6fc3f8 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -70,6 +70,7 @@ extra-y := symbols-dummy.o
> >   
> >   obj-$(CONFIG_COVERAGE) += coverage/
> >   obj-y += sched/
> > +obj-$(CONFIG_IOREQ_SERVER) += hvm/
> >   obj-$(CONFIG_UBSAN) += ubsan/
> >   
> >   obj-$(CONFIG_NEEDS_LIBELF) += libelf/
> > diff --git a/xen/common/hvm/Makefile b/xen/common/hvm/Makefile
> > new file mode 100644
> > index 0000000..326215d
> > --- /dev/null
> > +++ b/xen/common/hvm/Makefile
> > @@ -0,0 +1 @@
> > +obj-y += ioreq.o
> > diff --git a/xen/common/hvm/ioreq.c b/xen/common/hvm/ioreq.c
> > new file mode 100644
> > index 0000000..7e1fa23
> > --- /dev/null
> > +++ b/xen/common/hvm/ioreq.c
> > <snip>
> HVM is an internal detail of arch specific code.  It should not escape
> into common code.
>
>  From x86's point of view, there is nothing conceptually wrong with
> having an IOREQ server for PV guests, although it is very unlikely at
> this point that adding support would be a good use of time.
Got it.


> Please make this into a proper top-level common set of functionality.
ok.


--
Regards,

Oleksandr Tyshchenko