On Tue, 18 Oct 2022, Julien Grall wrote:
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.
I think that's fair.
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
Yeah
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.
Let's think some more about the naming strategy. From a QEMU point of
view we could choose any name we like (Vikram please confirm), the issue
is really on the libxl side.
Today libxl understands two QEMU "machines": xenpv and xenfv
(pc,accel=xen is the same as xenfv, I'll use xenfv in this email for
simplicity).
xenpv is for PV guests and only provides PV backends, no emulation. It
is used on both ARM and x86.
xenfv is only used on x86, and it is for HVM guests, with a full set of
emulated hardware (PIIX3, etc.).
The purpose of this series is to introduce a QEMU machine that:
- works on ARM (but could maybe work on other archs as a stretch goal)
- provides PV backends
- no emulated devices by default
- also can emulate selected devices on request
Certainly it is not xenfv or pc,accel=xen because they would with more
emulation by default. This is more like "xenpvh": an extension to PV
with also the capability of emulating one device as requested. It is not
intended to emulate a full PC and doesn't do that by default like xenfv.
This is also how I would imagine it would get integrated in libxl: as a
xenpv + individual emulated devices. Not as HVM for ARM. The other QEMU
command line arguments are inline with the xenpv command line arguments
rather than xenfv command line arguments. This is why the libxl changes
are small to zero to make it work today.
So, I think the following options work:
a) call it "xenpv" because it is an extension of the old xenpv machine
b) call it "xenpvh" because it is PV + few individual emulated devices
If we call it xenpv there are fewer changes in libxl. If we call it
xenpvh there are more changes in libxl but we can distinguish xenpv from
xenpvh (I don't see why we need it right now, but I could imagine it
could turn out useful in the future.)