[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.