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

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

On Wed, Jul 01, 2015 at 11:29:46AM +0100, Stefano Stabellini wrote:
> 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

And the link:

http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00160.html
> > 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.

Both. If you had 'vnc' or 'vfb' it would setup the 'vfb' key.
> 
> 
> > 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.

Correct. Right now the 'xen_pvh_domain' is based on it being PV and auto-translate.
That whole thing will need some help.


But I am looking at the xen-fbfront.c driver and it might be that
I had already fixed this issue! (inadvertly it seems)

51c71a3bbaca868043cc45b3ad3786dd48a90235
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Nov 26 15:05:40 2013 -0500

    xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

..
   - if running in HVM, check if user wanted 'xen_emul_unplug=never',
       in which case bail out and don't load any PV drivers.
     - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
       does not exist, then bail out and not load PV drivers.
     - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
       then bail out for all PV devices _except_ the block one.
       Ditto for the network one ('nics').
     - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
       then load block PV driver, and also setup the legacy IDE paths.
       In (v3) make it actually load PV drivers.

.. which means that if the driver does not use the 'xen_has_pv_XXX_devices'
but only the 'xen_has_pv_devices' then for a normal HVM guest it won't load
it.

And sure enough we have:

+       if (!xen_has_pv_devices())
+               return -ENODEV;

so we bail out and not load it under HVM.