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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] NMI deferral on i386
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 16 May 2007 13:32:06 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 16 May 2007 05:30:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <464AF4A9.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceXtjaldPdG9QOpEdyPGgAX8io7RQ==
Thread-topic: [Xen-devel] NMI deferral on i386
User-agent: Microsoft-Entourage/
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.
Personally I've never seen a #MC or had one reported to me, restartable or
not. Maybe I'm lucky. :-)

 -- Keir

Xen-devel mailing list