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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 1 Jul 2015, Konrad Rzeszutek Wilk wrote:
> 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@xxxxxxxxxx>
> 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.
 
And at the same time it works on ARM because CONFIG_XEN_PVHVM is not
defined there, right?

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