Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

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

On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote:
> On Wed, 22 Oct 2014, Ian Campbell wrote:
> > On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
> > > Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> > > > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > > > > As a side note to this - if I use pygrub as a bootloader vs using
> > > > > pvgrub, then VNC works perfectly.
> > > > > 
> > > > > So, what options exist to make pvgrub behave properly for booting with
> > > > > VNC enabled?
> > > > 
> > > > ISTR (vaguely) that way back when the backends needed to be modified to
> > > > cope with kexec (which is effectively what pvgrub does) by not exiting
> > > > when the frontend disconnects, instead sticking around waiting for a new
> > > > frontend, this relates somehow to the "online" key in xenstore.
> > > > 
> > > > Perhaps the pvfb backend never got that treatment, which would explain
> > > > #2? 
> > > 
> > > Probably, yes.
> > 
> > Adding Stefano and Anthony, since the backend in this case is in qemu.
> > 
> > When the frontend disconnects and the online node == 1 then the backend
> > is supposed to go from Closed back to InitWait and wait for a new
> > connection, as opposed to shutting down. This is needed for kexec (which
> > pvgrub uses).
> > 
> > I can see some handling of the online node in hw/xen/xen_backend.c but
> > it doesn't look like it would do what is needed here. I also don't see
> > any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
> > makes me suspect that as well as pvfb not working with kexec/pvgrub
> > neither does the qdisk backend, which would be unfortunate.
> 
> Looking at the code in xen_backend.c, it seems that on XenbusStateClosed
> xen_backend is going to try to reset to XenbusStateInitialising, unless
> the frontend state is XenbusStateInitialising (no idea why).  See:
> xen_be_try_reset and xen_be_check_state.
> 
> Maybe it should go to XenbusStateInitWait instead?

Possibly?

Doesn't xen_be_check_state do that though, i.e. once you hit
XenbusStateInitialising you have:
        case XenbusStateInitialising:
            rc = xen_be_try_init(xendev);
which will push on to XenbusStateInitWait?

There's quite a few xen_be_printf surrounding these state transitions,
which ought to be printed at level >= 2. How can Steven control the
loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?)

Ian.


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