Re: [Xen-devel] [RFC PATCH 09/12] libxl: Xen Platform device support for Q35

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 20, 2018 at 01:05:32AM +1000, Alexey G wrote:
> On Tue, 13 Mar 2018 04:33:54 +1000
> Alexey Gerasimenko <x1917x@xxxxxxxxx> wrote:
> 
> >Current Xen/QEMU method to control Xen Platform device is a bit odd --
> >changing 'xen_platform_device' option value actually modifies QEMU
> >emulated machine type, namely xenfv <--> pc.
> >
> >In order to avoid multiplying machine types, use the new way to control
> >Xen Platform device for QEMU -- xen-platform-dev property. To maintain
> >backward compatibility with existing Xen/QEMU setups, this is only
> >applicable to q35 machine currently. i440 emulation uses the old method
> >(xenfv/pc machine) to control Xen Platform device, this may be changed
> >later to xen-platform-dev property as well.
> >
> >Signed-off-by: Alexey Gerasimenko <x1917x@xxxxxxxxx>
> >---
> > tools/libxl/libxl_dm.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> >index 7b531050c7..586035aa73 100644
> >--- a/tools/libxl/libxl_dm.c
> >+++ b/tools/libxl/libxl_dm.c
> >@@ -1444,7 +1444,11 @@ static int
> >libxl__build_device_model_args_new(libxl__gc *gc,
> >         break;
> >     case LIBXL_DOMAIN_TYPE_HVM:
> >         if (b_info->device_model_machine ==
> > LIBXL_DEVICE_MODEL_MACHINE_Q35) {
> >-            machinearg = libxl__sprintf(gc, "q35,accel=xen");
> >+            if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> >+                machinearg = libxl__sprintf(gc, "q35,accel=xen");
> >+            } else {
> >+                machinearg = libxl__sprintf(gc,
> >"q35,accel=xen,xen-platform-dev=on");
> >+            }
> >         } else {
> >             if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> >                 /* Switching here to the machine "pc" which does not
> > add
> 
> Regarding this one -- QEMU maintainers suggested that supplying '-device
> xen-platform' directly should be a better approach than a machine
> property, so this patch is kinda obsolete.

I agree with QEMU maintainers.

> 
> Right now "xenfv" machine usage for qemu-xen seems to be limited to
> controlling the Xen platform device and applying the HVM_MAX_VCPUS
> value to maxcpus + minor changes related to IGD passthrough. Both
> should be applicable for a "pc,accel=xen" machine as well I think, which
> in fact currently lacks the HVM_MAX_VCPUS check for some reason.
> 
> Adding a distinct method to control Xen platform device for the q35
> machine suggests to propagate the same approach to i440 machine types,
> but... it depends on who else can use xenfv for qemu-xen (not to be
> confused with xenfv usage on qemu-traditional).
> 
> Is there any other toolstacks/code which use xenfv machine solely to
> turn on/off Xen platform device?

Check libvirt?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel