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
_______________________________________________
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
