From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests Date: Thu, 2 Jul 2015 12:04:43 +0100 Message-ID: References: <1435249141.32500.111.camel@citrix.com> <1435654263.21469.19.camel@citrix.com> <1435671177.21469.163.camel@citrix.com> <1435673633.21469.186.camel@citrix.com> <20150630203837.GF7546@l.oracle.com> <20150701184123.GB22498@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150701184123.GB22498@l.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, Wei Liu , Ian Campbell , Stefano Stabellini , Ian.Jackson@eu.citrix.com, Roger Pau Monne List-Id: xen-devel@lists.xenproject.org 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 > 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?