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 09:28:22 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 16 May 2007 01:24:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <464ADA4F.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: AceXlCoQaKdsgwOHEdyYUgAWy6hiGQ==
Thread-topic: [Xen-devel] NMI deferral on i386
User-agent: Microsoft-Entourage/
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.

 -- Keir

Xen-devel mailing list