Re: [PATCH v5 1/6] libxl: do not add a vkb backend to hvm guests

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Fri, 24 Jul 2015, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> > bounces@lists.xen.org] On Behalf Of Stefano Stabellini
> > Sent: 23 July 2015 18:28
> > To: xen-devel@lists.xensource.com
> > Cc: Wei Liu; Ian Jackson; Ian Campbell; Stefano Stabellini
> > Subject: [Xen-devel] [PATCH v5 1/6] libxl: do not add a vkb backend to hvm
> > guests
> > 
> > When QEMU restricts its xenstore connection, it cannot provide PV
> > backends. A separate QEMU instance is required to provide PV backends in
> > userspace, such as qdisk. With two separate instances, it is not
> > possible to take advantage of vkb for mouse and keyboard, as the QEMU
> > that emulates the graphic card (the device model), would be separate
> > from the QEMU running the vkb backend (PV QEMU).
> > 
> > Removing this functionality is acceptable, because is only useful for
> > power saving when usb emulation is off, letting QEMU sleep for longer
> > periods of time.  However usb emulation is on by default, and how to
> > take advantage of this configuration has never been documented.
> > 
> 
> I don't think I agree. Turning off USB emulation for HVM guests (particularly Windows) has been shown to be highly advantageous in performance and scalability terms, and we have a prototype HID driver (not yet part of the XenProject driver set, but hopefully soon will be) which uses vkb.

I would appreciate if this kind of comments were made at v1 or v2, not
v5 of a series :-)


I know that turning USB emulation off is a big win, but nobody is really
doing it. The reason is that we didn't properly documented how to do it.
As you say, not even the Xen Project Windows PV drivers take advantage
of vkb yet, even though they might soon. I still think that removing vkb 
cannot be considered a regression.

If it comes to a choice, I think that securing QEMU is more important
that turning USB emulation off and the two are fundamentally
incompatible.

Even if we run two QEMUs, one for emulation, one for the backends, the
vkb backend would need to be running in the same QEMU that offers vga
emulation because of the cursor rendering. It is a no go.

We could expose vkb but only together with vfb, so the vkb cursor would
only affect the vfb screen and not the vga screen. I don't know if you
would like that solution, but in any case it could still be introduced
after this work as it is independent.

Another possibility would be to add an option to request a vkb backend
for HVM guests in the config file. If the option is selected QEMU would
run as root. I wouldn't dare to recommend it to anybody.


> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  tools/libxl/libxl_create.c |    5 -----
> >  1 file changed, 5 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index f0da7dc..a74b340 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1275,17 +1275,12 @@ static void domcreate_launch_dm(libxl__egc
> > *egc, libxl__multidev *multidev,
> >      {
> >          libxl__device_console console;
> >          libxl__device device;
> > -        libxl_device_vkb vkb;
> > 
> >          init_console_info(gc, &console, 0);
> >          console.backend_domid = state->console_domid;
> >          libxl__device_console_add(gc, domid, &console, state, &device);
> >          libxl__device_console_dispose(&console);
> > 
> > -        libxl_device_vkb_init(&vkb);
> > -        libxl__device_vkb_add(gc, domid, &vkb);
> > -        libxl_device_vkb_dispose(&vkb);
> > -
> >          dcs->dmss.dm.guest_domid = domid;
> >          if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
> >              libxl__spawn_stub_dm(egc, &dcs->dmss);
> > --
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>