[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] NMI Race


  • To: "Peter Teoh" <tthtlc@xxxxxxxxxxxxxx>,<xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Mats Petersson <mats@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 02 Aug 2007 15:23:49 +0100
  • Delivery-date: Thu, 02 Aug 2007 07:21:45 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:x-mailer:date:to:from:subject:in-reply-to:references:mime-version:content-type:sender:message-id; b=uLcIPGXflJ6ZBRECEmkzYV/Xjr2KyH8AWegTJ95Axsr0eCk2dh3oiUzucXAJAdOuZd/Dhz9Ynj8AldJOfdAsqdmTEqd8Hq0TeKOfbC2ZjRalKklV8+Zo+CG0r18ahp4EthJj8qKAvjSCIQLpyOJMe8B0WFot6izmqfAqWvLcg5E=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

At 15:16 02/08/2007, Peter Teoh wrote:
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?

Not sure if there is a "function call" as such - it's more a case of "if someone changes CR3, followed by an NMI", then if not all GDT are in visible on all VCPU's, the NMI will fail because it's trying to read the GDT, and the GDT is unavailable in the memory map pointed to by CR3.

So the race is between setting CR3 and setting GDT and NMI's.

--
Mats


(X-Ref:
<http://osdir.com/ml/emulators.xen.cvs/2005-10/msg00300.html>http://osdir.com/ml/emulators.xen.cvs/2005-10/msg00300.html for more details).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.