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

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

On Mon, Mar 02, 2015 at 10:03:35AM +0000, Stefano Stabellini wrote:
> On Fri, 27 Feb 2015, 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.
> > 
> > Any suggestsion on how to fix this? Should we just wrap the
> > whole thing with #ifdef, like this?
> 
> Is vfb properly setup by Xend? Does the console show on the vfb framebuffer?

The vfb xenstore keys are. The VFB framebuffer (QEMU) is not - as it
in most cases runs as qemu-traditional which would not set it up.
> 
> If the vfb console works but is undesirable because the user expects the
> output on the main vnc window (the vga framebuffer), then could we find
> a way to prioritize the vga console over vfb on x86?

This is all about Xend and QEMU traditional. Fixing the bug in Xend would
be nice but I don't see anybody accepting the patch as those are
kind of 'dead'.
> 
> If the vfb console doesn't work, for example because the backend is not
> running, then maybe we could find a way in Linux to avoid vfb if it is
> not actually "connected".


That sounds complicated. Especially during early bootup.
> 
> 
> > diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
> > index 09dc447..584be8e 100644
> > --- a/drivers/video/fbdev/xen-fbfront.c
> > +++ b/drivers/video/fbdev/xen-fbfront.c
> > @@ -696,7 +696,10 @@ static int __init xenfb_init(void)
> >  {
> >  	if (!xen_domain())
> >  		return -ENODEV;
> > -
> > +#ifdef CONFIG_X86
> > +	if (!xen_pv_domain())
> > +		return -ENODEV;
> > +#endif
> >  	/* Nothing to do if running in dom0. */
> >  	if (xen_initial_domain())
> >  		return -ENODEV;
> >