At 16:33 +0100 on 15 Jul (1279211635), Tim Deegan wrote:
> At 16:30 +0100 on 15 Jul (1279211440), Zhang, Yang Z wrote:
> > ok, I get it. Will you work on this issue ? it has block our nightly
> > test. Hope will be fixed as soon as possible.
>
> Yes, I am still looking into it. I think the address of the table is
> not causing it, though, so it might take some time to find the real
> cause.
The hang turned out to be entirely unrelated to the SMBIOS tables; the
xenbus client zeroes out teh xenstore ring entirely, and it looks like
newer dom0 xenbus backends can't handle that, so:
hvmloader: don't zero out the xenbus page.
Not all xenbus backends accept that gracefully. Instead rely on the
xenbus frontend in the guest being able to start up with non-zero ring
offsets.
Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
diff -r c4a83e3cc6b4 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c Thu Jul 15 18:18:16 2010 +0100
+++ b/tools/firmware/hvmloader/xenbus.c Mon Jul 19 11:51:11 2010 +0100
@@ -53,14 +53,14 @@
(unsigned long) rings, (unsigned long) event);
}
-/* Reset the xenbus connection so the next kernel can start again.
- * We zero out the whole ring -- the backend can handle this, and it's
- * not going to surprise any frontends since it's equivalent to never
- * having used the rings. */
+/* Drop the Xenbus connection, leaving it ready for the next user.
+ * There should be no messages on the ring but make sure the rsp
+ * consumer is up to date just in case. */
void xenbus_shutdown(void)
{
ASSERT(rings != NULL);
- memset(rings, 0, sizeof *rings);
+ ASSERT(rings->req_cons == rings->req_prod);
+ rings->rsp_cons = rings->rsp_prod;
rings = NULL;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home