Date: Fri, 8 Nov 2019 10:19:01 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-xen@freebsd.org Subject: Re: Xen (HVM) and NMI Message-ID: <a95f4a92-dc5f-35e2-9f81-b26c2b3d0369@FreeBSD.org> In-Reply-To: <62c12d1e-658c-93fc-fad8-3d97d45b4dd1@FreeBSD.org> References: <e543673e-d55f-af0d-5aed-b00ad75de7cc@FreeBSD.org> <62c12d1e-658c-93fc-fad8-3d97d45b4dd1@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a95f4a92-dc5f-35e2-9f81-b26c2b3d0369>