From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler
Date: Thu, 22 Nov 2012 10:52:08 +0000 [thread overview]
Message-ID: <50AE03D8.80703@citrix.com> (raw)
In-Reply-To: <50ADF75F02000078000AA8BB@nat28.tlf.novell.com>
On 22/11/12 08:58, Jan Beulich wrote:
>>>> On 13.11.12 at 21:08, Malcolm Crossley <malcolm.crossley@citrix.com> 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.
>>
>> 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. We must ensure that
>> the
>> IRET from the INT 2 IRET is the first IRET issued to prevent losing an NMI.
>> Moving the INT 2 call to before the interrupts are enabled should ensure we
>> don't lose the NMI.
>>
>> Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
>> Acked-by: Tim Deegan <tim@xen.org>
> As (I think) we agreed to not use "int $2", and as I don't recall
> having seen a v3 of this patch - is that something that can be
> expected any time soon? Ideally, I would want to incorporate
> the changes here (and hopefully also the PV issue described
> during the discussion) in the pending 4.2.1 (and, if applicable,
> 4.1.4) release(s).
>
> Jan
Malcolm is out of the office this week. I will see about respinning a
v3 later today.
~Andrew
>
>> diff -r 62885b3c34c8 -r 7d6fd0219dd7 xen/arch/x86/hvm/vmx/vmx.c
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2269,6 +2269,14 @@ void vmx_vmexit_handler(struct cpu_user_
>> vector = intr_info & INTR_INFO_VECTOR_MASK;
>> if ( vector == TRAP_machine_check )
>> do_machine_check(regs);
>> + else if ( vector == TRAP_nmi &&
>> + ( (intr_info & INTR_INFO_INTR_TYPE_MASK) ==
>> + (X86_EVENTTYPE_NMI << 8) ) )
>> + /* Must be called before interrupts are enabled to ensure
>> + * the NMI handler code is run before the first IRET. The
>> + * IRET unblocks subsequent NMI's (Intel SDM Vol 3, 6.7.1)
>> + */
>> + asm volatile("int $2"); /* Real NMI, vector 2: normal
>> processing */
>> break;
>> case EXIT_REASON_MCE_DURING_VMENTRY:
>> do_machine_check(regs);
>> @@ -2442,7 +2450,6 @@ 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. */
>> break;
>> case TRAP_machine_check:
>> HVMTRACE_0D(MCE);
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
prev parent reply other threads:[~2012-11-22 10:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 20:08 [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler Malcolm Crossley
2012-11-14 10:06 ` Jan Beulich
2012-11-15 16:41 ` Tim Deegan
2012-11-15 16:52 ` Andrew Cooper
2012-11-15 17:25 ` Tim Deegan
2012-11-16 8:17 ` Jan Beulich
2012-11-16 9:59 ` Mats Petersson
2012-11-16 10:18 ` Keir Fraser
2012-11-15 17:03 ` Mats Petersson
2012-11-15 17:15 ` Tim Deegan
2012-11-15 17:33 ` Mats Petersson
2012-11-15 17:44 ` Tim Deegan
2012-11-15 18:23 ` Mats Petersson
2012-11-16 8:07 ` Jan Beulich
2012-11-16 10:56 ` Tim Deegan
2012-11-16 11:23 ` Jan Beulich
2012-11-16 11:52 ` Andrew Cooper
2012-11-16 13:53 ` Tim Deegan
2012-11-16 14:11 ` Andrew Cooper
2012-11-22 8:58 ` Jan Beulich
2012-11-22 10:52 ` Andrew Cooper [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50AE03D8.80703@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.