[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

  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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.