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:34:55 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 21 May 2007 07:32:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C277687F.F456%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: <4651C258.76E4.0078.0@xxxxxxxxxx> <C277687F.F456%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 21.05.07 16:17 >>>
>On 21/5/07 15:01, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> 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).
>You'll have to explain how the changes to the x86_32 entry.S work. The rest
>of the patch looks good.

The idea is to always check values read from %ds and %es against 
and only store into the current frame (all normal handlers) or the outer-most
one (NMI and MCE) if the value read is different. That way, any NMI or MCE
occurring during frame setup will store selectors not saved so far on behalf of
the interrupted handler, with that interrupted handler either having managed
to read the guest selector (in which case it can store it regardless of whether
NMI/MCE kicked in between the read and the store) or finding __HYPERVISOR_DS
already in the register, in which case it'll know not to store (as the nested
handler would have done the store).

For the restore portion this makes use of the fact that there's exactly one
such code sequence, and by moving the selector restore part past all other
restores (including all stack pointer adjustments) the NMI/MCE handlers can
safely detect whether any selector would have been restored already (by
range checking EIP) and move EIP back to the beginning of the selector
restore sequence without having to play with the stack pointer itself or any
other gpr.


Xen-devel mailing list