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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 30 Jun 2015, Konrad Rzeszutek Wilk wrote:
> 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).

But even with xend it only happens with a vfb line is in the config
file, right? That's why we didn't fix it back when the issue was
reported, if I remember correctly.


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

Yeah, we need xen-fbfront for ARM.


Given that xen-fbfront is likely to go away for HVM guests, I wouldn't
be opposed to stop the driver initialization in Linux on x86/HVM. Unless
Roger's work on HVMlite is going to need xen-fbfront again, but in that
case we'll be able to distinguish a regular HVM guest from an HVMlite
guest, I think.

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