Re: Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-03-03 at 10:44 +0000, Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 02, 2015 at 02:38:50PM +0000, David Vrabel wrote:
> > > On 02/03/15 14:25, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Mar 02, 2015 at 10:47:12AM +0000, David Vrabel wrote:
> > > >> On 27/02/15 21:24, Konrad Rzeszutek Wilk wrote:
> > > >>> This has been in queue for some time.
> > > >>>
> > > >>> In our kernels (UEK3) we had to revert said patch. The patch says:
> > > >>>
> > > >>> "    xen/fb: allow xenfb initialization for hvm guests
> > > >>>
> > > >>>     There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
> > > >>>     As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
> > > >>>     Given that no Xen toolstacks configure a xenfb backend for x86 HVM
> > > >>>     guests, they are not affected.
> > > >>>
> > > >>>     Please note that at this time QEMU needs few outstanding fixes to
> > > >>>     provide xenfb on ARM:
> > > >>>
> > > >>>     http://marc.info/?l=qemu-devel&m=138739419700837&w=2
> > > >>> "
> > > >>>
> > > >>> which is a lie. The "no Xen toolstacks configure a xenfb backend for
> > > >>> x86 HVM" is actually a lie. If you try to boot this kernel under
> > > >>> Xen with Xend it will be a problem - as Xend does setup an 'vfb'
> > > >>> device.
> > > >>>
> > > >>> The end result is that during the bootup - up until X starts, there is
> > > >>> no console output on the VNC window. As the Linux kernel tries to use
> > > >>> the vfb console driver.
> > > >>
> > > >> This looks like a toolstack bug to me.  If the toolstack has configured
> > > >> a vfb backend surely that should be preferred to the emulated VGA?
> > > > 
> > > > This is Xend. It is a bit brain dead in this category.
> > > > 
> > > >>
> > > >>> Any suggestsion on how to fix this? Should we just wrap the
> > > >>> whole thing with #ifdef, like this?
> > > >>
> > > >> No.  We want to avoid frontend drivers behaving differently on different
> > > >> architectures.
> > > > 
> > > > We could try detecting that it is Xend (not sure how?) - or that it is
> > > > Xen 4.4 or below - which would be the only versions that could be run with
> > > > Xend.
> > > 
> > > That's even worse.  Please just fix your toolstack to not create the vfb
> > > backend if you don't want to use it.
> > 
> > That is mighty hard from me looking at the code. Xend treats the 'vfb' as au
> > dumping ground for VNC and VFB configurations - and it depends on them when
> > an migration is progress.
> > 
> > I am afraid that Xend is still widespread enough that we need some way to
> > deal with it.
> > 
> > The #idef hackery - while not a nice way can make this work.
> > 
> > Or we can add this in an header/function as a quirk.
> > 
> > boolean xen_pvfb_dont_init_quirk(void)
> > {
> > #ifdef CONFIG_X86
> 
> I would be OK with having such a quirk without the ifdef (no xend has
> been known to work on ARM anyway).
>  
> 
> > 	if (xen_running_on_version_or_later(4, 5) && xen_hvm_domain())
> 
> Shouldn't this be xen_running_on_version_or_earlier(4, 4)?
> Xend has been removed in 4.5.

This all sounds pretty gross, but if it is the way folks want to go,
shouldn't it try and determine that it is running on xend somehow
instead of guessing based on version number? 4.4 had xl in it too for
instance...

> 
> 
> > 	{
> > 		/* Do some XenStore keys to check if we might be running
> > 		 a brain dead Xend. */
> > 
> > 		if (xen_keys_blah_blah(''))..
> > 			return true;
> > 	}
> > #else
> > 	return false;
> > #endif
> > }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel