WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] x86: allow NMI injection

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: allow NMI injection
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 28 Feb 2007 12:21:51 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 28 Feb 2007 04:22:12 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C20B1F3E.A50E%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: <45E57803.76E4.0078.0@xxxxxxxxxx> <C20B1F3E.A50E%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>Notably this patch changes the way that a NMI handler is registered to use
>the native-like vector 2. This changes the guest interface though. Do you

But only in a benign fashion - registering the old way is still possible,
registering through set_trap_table now works where it previously didn't.

>really need to be able to specify a custom CS? Can you not vector to the
>flat CS and then far jump?

I probably could, but I'm generally opposed to making assumptions about
the guest where this is unnecessary (i.e. I dislike all callback pointers
registered without selectors).

>I'm not sure about making the IPI function a physdev_op(), since this is
>still a virtual NMI (it has nothing to do with real hardware NMIs). It might

I didn't find a good fit really. This seemed (from guest perspective) the
most reasonable choice.

>be better to make it a vcpu_op. Then it would not be a great fit to allow
>send-to-all send-to-all-butself overrides, but I'm not sure how important
>that optimisation is (or is to make the NMI deliveries as simultaneous as
>possible)?

The delivery shortcuts aren't a strict requirement to our NetWare guys,
yet keeping this close to how hardware IPIs can be sent seemed like a
good idea to me. For that reason, vcpu_op didn't get into the set of
hypercalls I considered for putting this under. If you really feel like not
having the shortcuts, then it could certainly go there.
Also, the cross domain sending of NMIs, if I saw this correctly, has just
recently got a domctl added (though currently implemented only for
ia64 and only for INIT), so maybe that part should really be split out.

Jan

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

<Prev in Thread] Current Thread [Next in Thread>