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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 24 Jul 2015, Paul Durrant wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > Sent: 24 July 2015 11:21
> > To: Paul Durrant
> > Cc: Stefano Stabellini; xen-devel@xxxxxxxxxxxxxxxxxxx; Wei Liu; Ian Jackson;
> > Ian Campbell
> > Subject: RE: [Xen-devel] [PATCH v5 1/6] libxl: do not add a vkb backend to
> > hvm guests
> > 
> > On Fri, 24 Jul 2015, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> > > > bounces@xxxxxxxxxxxxx] On Behalf Of Stefano Stabellini
> > > > Sent: 23 July 2015 18:28
> > > > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > 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 :-)
> > 
> 
> Yes, I realise that, but I've been busy... sorry.
> 
> > 
> > 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.
> 
> It's documented for XenServer and we have toolstack support to do it.

You could still use it if you call libxl_device_vkb_add explicitely and
you avoid creating any of depriv QEMU users (xen-qemudepriv-domid* and
xen-qemudepriv-shared).



> > 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.
> 
> I realise it would be a bit odd typing into one window and seeing output in 
> another, but is that a reason to disallow it?

The reason is that it is a complex solution: we would need 2 vnc
servers, one for the QEMU that does emulation and one for the QEMU that
runs the PV backends. They would need to bind to different ports. And
the benefit is doubtful because, as you wrote, it would be difficult to
use. I wouldn't want to add code to handle this case to libxl as part of
this series.



> > 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@xxxxxxxxxxxxx>
> > > > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > > ---
> > > >  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@xxxxxxxxxxxxx
> > > > http://lists.xen.org/xen-devel
> > >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel