Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 23 Sep 2014, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 23, 2014 at 04:57:26PM +0100, Ian Campbell wrote:
> > On Tue, 2014-09-23 at 16:43 +0100, David Vrabel wrote:
> > > On 23/09/14 15:30, Ian Campbell wrote:
> > > > create !
> > > > title it "30s delay loading xenfb driver on some systems"
> > > > owner it Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > > thanks
> > > > 
> > > > Hi James,
> > > > 
> > > > Some of the other Xen devs were discussing an issue which sounded
> > > > awfully similar to this one, so I am copying the xen-devel list and
> > > > creating a Xen bug to track the issue, please CC xen-devel (no need to
> > > > subscribe but you may be moderated the first time), since the tracker
> > > > slurps mails from the list.
> > > > 
> > > > I'm not sure of the details of the other issue but it involved
> > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1a3b1c8a8d963424c4699efa64dd8986b2f76d7
> > > >  hopefully Konrad or one of the others will follow up.
> 
> That was with an HVM guest running under Xen 4.1 in which this
> guest config was used:
> 
> vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
> 
> Xend would create an XenStore keys for the PV framebuffer and also making
> sure that QEMU VGA driver was running. The end result was that the guest
> would boot up to Xorg VGA driver, but the frame buffer console (so from
> the moment GRUB2 started Linux up to Xorg) would try to use the xen-fbfront.
> 
> And since this is HVM guest and VNCviewer was slurping contents from the
> VGA buffer - which was not used at all - we wouldn't get anything.
> 
> Reverting the above patch fixed the issue.

If you have a vfb line in your config file, aren't you actually
explicitly requesting a vfb frontend/backend pair?
XenD is just doing what the user asked him to do, I wouldn't call this a
bug.

What is strange is that given that there is no running vfb backend for
HVM guests in a regular Xen 4.1 installation, xen-fbfront could never
reach the "connected" state ("4" on xenstore): so why is Linux trying to
use vfb when the frontend is not even connected?

The reason is that xenfb_probe calls register_framebuffer and
xenfb_make_preferred_console too early, before even knowing if the
backend is alive.

I would move the register_framebuffer and xenfb_make_preferred_console
calls in xenfb_backend_changed, case XenbusStateConnected. That should
fix it.



> > > > 
> > > > For xen-devel, the first two mails in this thread are
> > > > https://lists.debian.org/debian-kernel/2014/09/msg00229.html and 
> > > > https://lists.debian.org/debian-kernel/2014/09/msg00233.html
> > > 
> > > The wait stuff for xenbus devices looks like pre-dates distros handling
> > > asynchronous devices with suitable initrds etc.
> > 
> > Perhaps, but I think most distros still don't use rootwait by default so
> > unless / turns up reasonably promptly (single digit seconds) the boot
> > may fail.
> > 
> > > I think we need a command line configurable white list of device types
> > > to wait for.  The default should be (to match what was done historically):
> > > 
> > > PV: vbd, vif, pci, vfb, vkbd.
> > > HVM: vbd, vif.
> > > 
> > > I also think it should be possible to default (via a config option) to
> > > an empty white list.
> > 
> > Irrespective of the above this seems like a reasonable enough idea to
> > me.
> 
> What about ARM?

On ARM (and on PV on HVM x86) we want vfb to work by default if the
xenstore keys are there.  But I don't think that it means we need to
wait 30 secs for it at boot.  What is a reasonable amount of time to
wait for on a slow and overcommitted system? Maybe 5 to 10 secs?

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