From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, keir.fraser@eu.citrix.com
Cc: konrad.wilk@oracle.com
Subject: [PATCH 1 of 1] mini-os: PV fronted MUST be in XenbusStateConnected not XenbusStateInitialized during init
Date: Wed, 30 Jun 2010 10:30:41 -0400 [thread overview]
Message-ID: <76e7d0258f65e4ab1b10.1277908241@phenom.dumpdata.com> (raw)
In-Reply-To: <patchbomb.1277908240@phenom.dumpdata.com>
# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1277908182 14400
# Node ID 76e7d0258f65e4ab1b105cd70a96f2a411d5ca22
# Parent a24dbfcbdf695f49867d5881ea20ab40f18aea98
mini-os: PV fronted MUST be in XenbusStateConnected not XenbusStateInitialized during init.
With the QEMU change 805ed3b20492d2f4bb465bfda65cedd286e23209
("Wait for frontend state Connected before connecting the backend"),
where QEMU backend (say VNC framebuffer) will ONLY call ops->connect
(which when successfull, will move the backend state from XenbusStateInitWait
to XenbusStateConnected) when the frontend state is in XenbusStateConnected.
Previous to that git commit it would call ops->connect also
if the frontend was in XenbusStateInitialized state.
Without this patch, the MiniOS (in my case pvgrub) would hang
in the fbfront and kbfront threads waiting for the backend to change
its state from InitWait to Connected. Which the backend would not do
as the ops->connect in QEMU was never called.
The c/s 21260 "mini-os: Revert 21106:b20f897d6010 "Fix xenbus initialisation"
fixes this for the blkfront and netfront. Unfortunately
it did not fix it for the fbfront, kbdfront and pcifront which
this patch does.
The patch fixes pv-grub hanging at:
"
******************* FBFRONT for device/vfb/0 **********
******************* KBDFRONT for device/vkbd/0 **********
" and makes it now go to:
"
******************* FBFRONT for device/vfb/0 **********
******************* KBDFRONT for device/vkbd/0 **********
backend at /local/domain/0/backend/vkbd/11/0
/local/domain/0/backend/vkbd/11/0 connected
************************** KBDFRONT
Thread "kbdfront" exited.
backend at /local/domain/0/backend/vfb/11/0
/local/domain/0/backend/vfb/11/0 connected
"
and you use VNC to see the GRUB menu.
diff -r a24dbfcbdf69 -r 76e7d0258f65 extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c Tue Jun 22 07:19:38 2010 +0100
+++ b/extras/mini-os/fbfront.c Wed Jun 30 10:29:42 2010 -0400
@@ -124,7 +124,12 @@
}
snprintf(path, sizeof(path), "%s/state", nodename);
- err = xenbus_switch_state(xbt, path, XenbusStateInitialised);
+ /* In the past we would have made this Initialized. But with a QEMU
+ * update 805ed3b that requires the frontend to be Connected state
+ * to progress the backend to move from InitWait to Connected.
+ * The QEMU bug fix was meant _only_ for XenFB but it affects every
+ * device. */
+ err = xenbus_switch_state(xbt, path, XenbusStateConnected);
if (err) {
printk("error writing initialized: %s\n", err);
free(err);
@@ -485,7 +490,12 @@
}
snprintf(path, sizeof(path), "%s/state", nodename);
- err = xenbus_switch_state(xbt, path, XenbusStateInitialised);
+ /* In the past we would have made this Initialized. But with a QEMU
+ * update 805ed3b that requires the frontend to be Connected state
+ * to progress the backend to move from InitWait to Connected.
+ * The QEMU bug fix was meant _only_ for XenFB but it affects every
+ * device. */
+ err = xenbus_switch_state(xbt, path, XenbusStateConnected);
if (err) {
message = "switching state";
goto abort_transaction;
diff -r a24dbfcbdf69 -r 76e7d0258f65 extras/mini-os/pcifront.c
--- a/extras/mini-os/pcifront.c Tue Jun 22 07:19:38 2010 +0100
+++ b/extras/mini-os/pcifront.c Wed Jun 30 10:29:42 2010 -0400
@@ -204,7 +204,12 @@
}
snprintf(path, sizeof(path), "%s/state", nodename);
- err = xenbus_switch_state(xbt, path, XenbusStateInitialised);
+ /* In the past we would have made this Initialized. But with a QEMU
+ * update 805ed3b that requires the frontend to be Connected state
+ * to progress the backend to move from InitWait to Connected.
+ * The QEMU bug fix was meant _only_ for XenFB but it affects every
+ * device. */
+ err = xenbus_switch_state(xbt, path, XenbusStateConnected);
if (err) {
message = "switching state";
goto abort_transaction;
next prev parent reply other threads:[~2010-06-30 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-30 14:30 [PATCH 0 of 1] PV-GRUB fix (actually MiniOS) when PV guest launched with vfb=[..] entry Konrad Rzeszutek Wilk
2010-06-30 14:30 ` Konrad Rzeszutek Wilk [this message]
2010-07-01 11:32 ` [PATCH 1 of 1] mini-os: PV fronted MUST be in XenbusStateConnected not XenbusStateInitialized during init Stefano Stabellini
2010-07-01 14:05 ` Konrad Rzeszutek Wilk
2010-07-01 14:32 ` Stefano Stabellini
2010-07-01 15:07 ` Ian Jackson
2010-06-30 16:24 ` [PATCH 0 of 1] PV-GRUB fix (actually MiniOS) when PV guest launched with vfb=[..] entry Keir Fraser
2010-07-01 11:36 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76e7d0258f65e4ab1b10.1277908241@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).