Re: [QEMU][PATCH v5 09/10] hw/arm: introduce xenpvh machine

[Stefano Stabellini]

On Thu, 2 Feb 2023, Paul Durrant wrote:
> On 01/02/2023 18:22, Vikram Garhwal wrote:
> > Hi Paul,
> > 
> > Thanks for reviewing this and other patches in series.
> > 
> > Please see my reply below.
> > 
> > On 2/1/23 12:30 AM, Paul Durrant wrote:
> > > On 31/01/2023 22:51, Vikram Garhwal wrote:
> > > > Add a new machine xenpvh which creates a IOREQ server to
> > > > register/connect with
> > > > Xen Hypervisor.
> > > > 
> > > 
> > > Is this really the right way? Is it not possible to do the Xen
> > > initialization (including ioreq server registration) off the back of the
> > > accelerator init (i.e. AccelOpsClass ops_init function), which seems like
> > > the right place to do it now that it's no longer architecture specific.
> > > 
> > There are few other machines using the "accel=xen" option and few of these
> > machines aren't using IOREQ and other Xen related initialization. Example:
> > /xenpv/ machine under /hw/xenpv/xen_machine_pv.c /and few other machines
> > under /hw/i386/pc_piix.c//.
> 
> Ok. TBH the concept of 'accel=xen' is probably somewhat broken then. (QEMU
> isn't even running the VM in question, so how can it be accelerated?). Maybe
> abstract machine types really are the right way then.

Yes, it doesn't quite match QEMU as device model for Xen. However, as an
internal API in QEMU it can be useful to Xen as well occasionally. It is
just that in this specific case it doesn't look like it is the right
fit.


> > /So, that's//why we moved the IOREQ and other common initialization parts in
> > hw/xen/xen-hvm-common.c and call them as needed for the particular machine.
> > 
> > @stefano, just checking if you want to add any other suggestion here.
> > 
> > >   Paul
> > > 
>