[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler
The self_nmi() code cause's an NMI to be triggered by sending an APIC message to the local processor. Unfortunately there is a delay in the delivery of the APIC message and we may already have re-entered the HVM guest by the time the NMI is taken. This results in the VMEXIT code calling the self_nmi() function again. We have seen hundreds of iterations of this VMEXIT/VMENTER loop before the HVM guest resumes normal operation. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. So we believe it is safe to directly invoke the INT call as NMI's should already be blocked. The INT 2 call will perform an IRET which will unblock later calls to the NMI handler, according to Intel SDM Volume 3 Chapter 6.7.1. Signed-off-by: Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> diff -r 62885b3c34c8 -r e1fbee58b25c xen/arch/x86/hvm/vmx/vmx.c --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2442,7 +2442,7 @@ void vmx_vmexit_handler(struct cpu_user_ (X86_EVENTTYPE_NMI << 8) ) goto exit_and_crash; HVMTRACE_0D(NMI); - self_nmi(); /* Real NMI, vector 2: normal processing. */ + asm("int $2"); /* Real NMI, vector 2: normal processing. */ break; case TRAP_machine_check: HVMTRACE_0D(MCE); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |