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


[Xen-devel] NMI Race

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] NMI Race
From: "Peter Teoh" <tthtlc@xxxxxxxxxxxxxx>
Date: Thu, 2 Aug 2007 22:16:53 +0800
Delivery-date: Thu, 02 Aug 2007 07:14:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
I saw the following in xen\arch\x86\domain.c:
     * Map Xen segments into every VCPU's GDT, irrespective of whether every
     * VCPU will actually be used. This avoids an NMI race during context
     * switch: if we take an interrupt after switching CR3 but before switching
     * GDT, and the old VCPU# is invalid in the new domain, we would otherwise
     * try to load CS from an invalid table.

Can someone please elaborate on this "NMI race"?  Ie, Between which functions called, for example?
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>