[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
|
