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 15:11
> To: Stefano Stabellini
> Cc: Paul Durrant; 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, Stefano Stabellini wrote:
> > 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.
> 
> 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.

Excellent. Thanks for that :-)

  Paul

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