|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] x86: allow NMI injection
>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
|
|
|
|
|