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


Re: [Xen-devel] NMI deferral on i386

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] NMI deferral on i386
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 16 May 2007 16:19:53 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 16 May 2007 07:17:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C270B856.F060%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <464AF4A9.76E4.0078.0@xxxxxxxxxx> <C270B856.F060%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 16.05.07 14:32 >>>
>On 16/5/07 11:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>> It sounds a bit painful. Also it's the exit-to-guest path that is more of a
>>> pain to deal with. In this case we may have restored a segment register by
>>> the time we take the NMI. What do we do in this case about restoring the
>>> segment register safely? Races in updating GDT/LDT may mean that the reload
>>> still may fault, even though it didn't just before; also we may need to do
>>> work in Xen (e.g., shadow-mode stuff) in interrupts-enabled context to fix
>>> up a #GP or #PG.
>> Indeed. Nevertheless, for non-restartable MCEs, deferral is impossible, and
>> hence some mechanism would still be needed (unless we say the machine's
>> going down anyway in this case and we don't care about getting a proper
>> reason logged).
>You mean, like with a #DF, that sometimes a #MC may have bogus CS:EIP and so
>you cannot IRET from it? I'm not sure how much we care about losing these
>and turning a possibly-informative crash into an ugly and confusing crash.

Yes, that's what I mean. And I'm not so much concerned about turning a (very
rare) 'nice' crash into an 'ugly' one, but more about that fact that until the
system actually crashes it may continue to execute for a short while, possibly
making the data corruption situation worse.

>Personally I've never seen a #MC or had one reported to me, restartable or
>not. Maybe I'm lucky. :-)

I did see quite a few non-restartable ones (on native Linux), and it took me
some time to actually get the system into a state where I could see the
related messages before it rebooted. I don't have that system anymore,
though, otherwise I might be have been able to use it for testing purposes


Xen-devel mailing list