On 09/24/2010 01:07 AM, Ian Campbell wrote:
> NMI injection on 2.6.18 was one of the first Xen things I worked on (for
> injecting h/w NMI button faults) so something worked once upon a time. I
> can see CALLBACKTYPE_nmi and VCPUOP_send_nmi which seems promising that
> it's still around (and extended since I didn't do VCPUOP_send_nmi), even
> if its bit-rotted or not made it to pvops yet.
>
> In 2.6.18-xen the guest side of receiving an NMI was pretty ugly IIRC
> since we needed to force a return via the iret hypercall (to allow the
> hypervisor to simulate the NMI interrupt window).
>
> There is a small amount of residual support even in pvops
> (XEN_EFLAGS_NMI is defined, and tested once on 32 bit, but never set).
> It might be possible to do something nicer with all the pvops
> infrastructure, I'm also not sure it isn't a premature optimisation to
> save a compare by putting the NMI flag into a reserved bit of the saved
> EFLAGS anyway.
>
I think the Intel MCE people have made NMI work in pvops, but I didn't
look closely.
But from a pvops perspective, I think the tricky part is sending an NMI
rather than receiving. As I said in my mail to Timo, the simplest
option is to disable that code for now.
J
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c9cf394.90...@goop.org
