[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |