Re: [Xen-devel] Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


>       {
>               /* 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel