WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Need help with fixing the Xen waitqueue feature

To: Olaf Hering <olaf@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Tue, 08 Nov 2011 22:05:41 +0000
Cc:
Delivery-date: Tue, 08 Nov 2011 14:09:10 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=1nT32tXylBcOUvv79kqTLSYIH9Qi/WQe7QsFfgfa5wc=; b=WxZXGfOP8xJiz3Y/JYXV+MKnbcLZk6k364GdjVV/nIzFIJbAiY8PkaVC+GsIMfAW/I wUlqHtIDctPGcfW7ZKmSbt2/vqdDeOYHxpS6O4ifwby+Yw5F26IpSYB5/WRjxsWlhIS4 Bao3kg7ANlr+Fa0tbD0tIe1dqIEP2kYSAftk4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111108212024.GA5276@xxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyeYo3OrP4N8Ihww06cxS9uKo6mbg==
Thread-topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
User-agent: Microsoft-Entourage/12.31.0.110725
On 08/11/2011 21:20, "Olaf Hering" <olaf@xxxxxxxxx> wrote:

> Another thing is that sometimes the host suddenly reboots without any
> message. I think the reason for this is that a vcpu whose stack was put
> aside and that was later resumed may find itself on another physical
> cpu. And if that happens, wouldnt that invalidate some of the local
> variables back in the callchain? If some of them point to the old
> physical cpu, how could this be fixed? Perhaps a few "volatiles" are
> needed in some places.

>From how many call sites can we end up on a wait queue? I know we were going
to end up with a small and explicit number (e.g., in __hvm_copy()) but does
this patch make it a more generally-used mechanism? There will unavoidably
be many constraints on callers who want to be able to yield the cpu. We can
add Linux-style get_cpu/put_cpu abstractions to catch some of them. Actually
I don't think it's *that* common that hypercall contexts cache things like
per-cpu pointers. But every caller will need auditing, I expect.

A sudden reboot is very extreme. No message even on a serial line? That most
commonly indicates bad page tables. Most other bugs you'd at least get a
double fault message.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel