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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> Sent: 24 July 2015 11:56
> 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: 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.
> 

You'd need a console in both QEMUs but I don't think that's necessarily a 
problem is it? Clearly, if you are going to use a simple VNC client, it's going 
to look weird. But it would be feasible to write a client that sends kbd/mouse 
messages to two servers whilst only displaying the framebuffer of one. I really 
don't think there's any reason to enforce no vkb for HVM guests.

  Paul

> 
> 
> > > 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