On Fri, 2010-09-24 at 11:53 -0700, Jeremy Fitzhardinge wrote: > 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. It's not just "HYPERVISOR_vcpu_op(VCPUOP_send_nmi, cpu, NULL)"? > As I said in my mail to Timo, the simplest option is to disable that code for now. Agreed. -- Ian Campbell Your business will assume vast proportions.
Attachment:
signature.asc
Description: This is a digitally signed message part