Re: [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote:
> On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote:
> > On Tue, 30 Jun 2015, Ian Campbell wrote:
> > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote:
> > > > On Tue, 30 Jun 2015, Ian Campbell wrote:
> > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote:
> > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote:
> > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote:
> > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote:
> > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote:
> > > > > > > > > > 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).
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The question is that how would this affect the non-split setup.
> > > > > > > > 
> > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more often.
> > > > > > > > However there is no way around it.
> > > > > > > 
> > > > > > > Does pvfb+vkb continue to work due to code somewhere else?
> > > > > > 
> > > > > > Yes, it continues to work as usual for PV guests.
> > > > > > 
> > > > > > 
> > > > > > > Do we think anyone will actually be using emulated VGA + PV input
> > > > > > > devices?
> > > > > > 
> > > > > > VGA + PV input only works with Linux and is only useful for power
> > > > > > efficiency, because if you disable usb emulation in QEMU, then QEMU
> > > > > > would be able to wake up less often. Given that usb emulation is still
> > > > > > on by default, I don't think that this change will have a big impact.
> > > > > 
> > > > > My question was whether we thought anyone would be using this
> > > > > non-default configuration, not what the impact on the default is.
> > > > > 
> > > > > You gave a good reason why people might be using this facility, do you
> > > > > think anyone is actually using it?
> > > >  
> > > > I don't know of anybody using it. I don't think we made clear enough how
> > > > to use this non-default configuration and its advantages for users to go
> > > > out of their ways to use it. 
> > > 
> > > That's good enough for me, thanks,.
> > 
> > Can I add your acked-by?
> 
> If you put some distillation of the reasoning given in this subthread
> for why we think we can get away with it into the commit message then
> yes.

Why don't we also make the Linux code not expose this driver for HVM guests?

I've had an go for this last year (can't find the link) as it would unduly
cause the Linux kernel to take an extra 30 seconds to boot. That is because
'xend' by default exposes the PV configuration even for HVM guests - and of
course there are no PV drivers (as the VGA in QEMU is enabled).

The only use case I had was for ARM - where there are no VGA - and the
patch I think I had just disabled the xen-fbfront under X86 HVM.

Thanks.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel