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>