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, Stefano Stabellini wrote:
> On Fri, 24 Jul 2015, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: 24 July 2015 11:56
> > > To: Paul Durrant
> > > Cc: Stefano Stabellini; xen-devel@lists.xensource.com; 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@eu.citrix.com]
> > > > > Sent: 24 July 2015 11:21
> > > > > To: Paul Durrant
> > > > > Cc: Stefano Stabellini; xen-devel@lists.xensource.com; 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@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 :-)
> > > > >
> > > >
> > > > 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.

Actually Paul is right, no confusion. I can just drop this patch and
everything works as it should. In the depriv case, we just have one more
backend that is never going to receive any events from the user or
inject any into the guest.