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, 23 May 2007 11:03:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 23 May 2007 03:02:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4651CA2F.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: AcedIaMl4X9PsAkUEdyD7QAX8io7RQ==
Thread-topic: [Xen-devel] NMI deferral on i386
User-agent: Microsoft-Entourage/
Well, this sounds fine to me. If you port it I'll apply it. I would prefer
it as a separate patch from the rest of the MCA/MCE changes really, but if
that's a pain then don't worry about it.

 -- Keir

On 21/5/07 15:34, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> 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