This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
Subject: [Xen-devel] [PATCH] Re: cs:21768 causes guest spend more time on boot up
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Mon, 19 Jul 2010 11:55:48 +0100
Cc: "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>, "Zhang, Jianwu" <jianwu.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Keir
Delivery-date: Mon, 19 Jul 2010 03:57:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100715153355.GI13291@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <749B9D3DBF0F054390025D9EAFF47F221F579513@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100715094857.GC13291@xxxxxxxxxxxxxxxxxxxxxxx> <20100715122235.GE13291@xxxxxxxxxxxxxxxxxxxxxxx> <749B9D3DBF0F054390025D9EAFF47F221F579629@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100715152026.GH13291@xxxxxxxxxxxxxxxxxxxxxxx> <749B9D3DBF0F054390025D9EAFF47F221F57962D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100715153355.GI13291@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
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

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

<Prev in Thread] Current Thread [Next in Thread>