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: Mon, 21 May 2007 16:01:28 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 21 May 2007 06:59:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2707F36.772A%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: <464ADA4F.76E4.0078.0@xxxxxxxxxx> <C2707F36.772A%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 16.05.07 10:28 >>>
>On 16/5/07 09:17, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>> Yes, it's good enough for watchdog and oprofile. Level-triggered external
>>> NMIs will of course be a problem. We could possibly work around this by
>>> masking LINT1 if we are CPU0 (and, of course, if LAPIC is enabled) and then
>>> unmasking only at the end of real NMI handler. And of course x86/64 doesn't
>>> have this problem at all, and practically speaking is pretty much the only
>>> hypervisor build that vendors seem to care about.
>> What if we removed the deferral altogether, and made the NMI handler
>> store into the outer most frame (after all, selector registers have fixed
>> places on that frame), marking the that frame accordingly so that
>> overwriting the values saved this way can be avoided in the
>> interrupted save sequence (would be necessary only if both %ds and
>> %es are neither __HYPERVISOR_DS nor null [neatly avoiding special
>> casing the vm86 mode entry in the outer frame], and would add an extra
>> branch to __SAVE_ALL_PRE plus splitting the selector register stores
>> into moving %ds and %es into general purpose registers, testing the
>> flag NMI or MCE handlers may set, and storing the GPRs into the frame
>> if the flag was clear).
>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.

I think I found a pretty reasonable solution, which I'm attaching in its current
(3.1-based) form, together with the prior (untested) variant that copied the
NMI behavior. Even if it doesn't apply to -unstable, I'd be glad if you could
have a brief look to see whether you consider the approach too intrusive (in
which case there would be no point in trying to bring it forward to -unstable).


Attachment: x86-machine-check.patch.0
Description: Binary data

Attachment: x86-machine-check.patch
Description: Text document

Xen-devel mailing list