[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [RFC PATCH] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler
On 13/11/12 11:38, Jan Beulich wrote: >>>> On 13.11.12 at 12:23, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote: >> 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. > But it does, eventually? I ask because ... > >> 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. > ... this blocking of NMIs should last until you enter the guest > again, so I would actually expect this to be an infinite loop ... The observed behaviour was some other event like a timer interrupt breaking it out of the loop and taking a different path through the vmexit handler. > >> So we believe it is safe to directly invoke the INT call as NMI's should >> already be blocked. > ... and this not only be safe, but actually required. > >> diff -r 62885b3c34c8 -r ea756059a8da 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. */ > In any case - why can't you call do_nmi() directly from here? > > Jan Actually, thinking about it that is a better idea than my suggestion, because if for some reason another, different NMI occurs (the Intel SDM is not exactly clear on exactly when NMIs are blocked till), the other NMI will enter on the real NMI stack and not trample over itself. ~Andrew > >> break; >> case TRAP_machine_check: >> HVMTRACE_0D(MCE); >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxx >> http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |