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

I am afraid it could confuse some unprepared frontends. For example a
PV on HVM linux user might be confused by the outcome. I would rather go
with allowing people to ask for QEMU to run as root.

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