Re: [PATCH v1 10/12] hw/arm: introduce xenpv machine

[Julien Grall]

Hi Stefano,

On 18/10/2022 02:26, Stefano Stabellini wrote:
> On Sun, 16 Oct 2022, Julien Grall wrote:
> > Hi,
> >
> > There seem to be some missing patches on xen-devel (including the cover
> > letter). Is that expected?
> >
> > On 15/10/2022 06:07, Vikram Garhwal wrote:
> > > Add a new machine xenpv which creates a IOREQ server to register/connect
> > > with
> > > Xen Hypervisor.
> >
> > I don't like the name 'xenpv' because it doesn't convey the fact that some of
> > the HW may be emulated rather than para-virtualized. In fact one may only want
> > to use for emulating devices.
> >
> > Potential name would be 'xen-arm' or re-using 'virt' but with 'accel=xen' to
> > select a Xen layout.
>
> The benefit of 'xenpv' is that it doesn't require any changes to libxl.

I am quite surprised. Looking at the code, it seems to work more by 
chance than it is intentional as the code is gated by 
libxl__need_xenpv_qemu(). So it would not start if there were no 
emulated devices.

> It is even backward compatible so it could be used with an older version
> of Xen/libxl.
We don't really gain much here. IOREQ is a tech preview and anyone that 
wants to try it should really use the latest Xen.

> Backward compatibility aside, if we come up with a
> different name then we'll need changes to libxl and to manage those
> changes. For instance, if we use 'xen-arm' that would mean we would need
> to handle per-arch QEMU machine names.

Right, so the main argument here is for simplicity in libxl
Looking at how 'xenpv' is built, this is really expected to deal with PV 
backend rather than emulated device. I do expect some changes as we go 
along to be able to add emulated device.

Furthermore, libxl is not the only toolstack out. So I am not convinced 
this is a good argument to keep the name the same.

Cheers,

--
Julien Grall