Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 22 Oct 2014, Ian Campbell wrote:
> 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?)


I think that this should do:


diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..d1d5d8e 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -50,7 +50,7 @@ const char *xen_protocol;
 
 /* private */
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = 
QTAILQ_HEAD_INITIALIZER(xendevs);
-static int debug = 0;
+static int debug = 9;
 
 /* ------------------------------------------------------------- */

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