[Xen-devel] [PATCH] Re: cs:21768 causes guest spend more time on boot up

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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