Xen (HVM) and NMI

Andriy Gapon avg at FreeBSD.org
Fri Nov 8 08:19:06 UTC 2019


On 08/11/2019 10:03, Andriy Gapon wrote:
> On 07/11/2019 20:08, Andriy Gapon wrote:
>> For CPUs that do get interrupted I see stack traces like:
>> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
>> intr_event_handle+0x8b intr_execute_handlers+0x58 xen_intr_handle_upcall+0x15a
>> xen_intr_upcall_u+0x96 ...
>> So, it looks like the NMI is delivered by the same mechanism as normal
>> interrupts.  If a processor has interrupts disabled then the NMI would not get
>> delivered?
>>
>> Is there anything we could do to improve this?
> 
> I found this in Linux code:
>     HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
> It's in xen_send_IPI_one().
> I wonder if that's that or if there is more to this than meets the eye.

I also found this in an old post.
Ian Campbell wrote:
> You need to register a callback with CALLBACKOP_register
> CALLBACKTYPE_nmi. You also need to write the code in entry.S to receive
> that callback. IIRC you also need to arrange that returning from an NMI
> is always done with HYPERVISOR_iret and not optimised to a direct iret
> as it can be otherwise. This is to allow the hypervisor to implement NMI
> masking correctly.

But I could not find a single use of CALLBACKTYPE_nmi in the Linux code (it's
defined but not referenced).
I did find this:
    hypercall_iret = hypercall_page + __HYPERVISOR_iret * 32
    ENTRY(xen_iret)
        pushq $0
        jmp hypercall_iret


-- 
Andriy Gapon


More information about the freebsd-xen mailing list