xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Mats Petersson <mats.petersson@citrix.com>
To: xen-devel@lists.xen.org
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, 15 Nov 2012 17:03:13 +0000	[thread overview]
Message-ID: <50A52051.9010807@citrix.com> (raw)
In-Reply-To: <20121115164156.GE75988@ocelot.phlegethon.org>

On 15/11/12 16:41, Tim Deegan wrote:
> Hi,
>
> At 10:06 +0000 on 14 Nov (1352887560), Jan Beulich wrote:
>>> +            asm volatile("int $2"); /* Real NMI, vector 2: normal processing */
>> And I still don't like this use of "int $2" here: An aspect we didn't
>> consider so far is that a nested MCE would break things again
> OK, I think I understand the problem[s], but I'm going to spell it out
> slowly so you can correct me. :)
>
> [ tl;dr I agree that do_nmi() is better, and we should do that in this
>    patch, but maybe we need to solve the general problem too. ]
>
> On a PV guest, we have to use dedicated stacks for NMI and MCE in case
> either of those things happens just before SYSRET when we're on the user
> stack (no other interrupt or exception can happen at that point).
>
> On an AMD CPU we _don't_ have dedicated stacks for NMI or MCE when we're
> running a HVM guest, so the stack issue doesn't apply (but nested NMIs
> are still bad).
>
> On an Intel CPU, we _do_ use dedicated stacks for NMI and MCE in HVM
> guests.  We don't really have to but it saves time in the context switch
> not to update the IDT.  Using do_nmi() here means that the first NMI is
> handled on the normal stack instead.  It's also consistent with the way
> we call do_machine_check() for the MCE case.  But it needs an explicit
> IRET after the call to do_nmi() to make sure that NMIs get re-enabled.

Both AMD and Intel has an identical setup with regard to stacks and 
general "what happens when we taken one of these interrupts". As Andy 
Cooper is about to post, there are ways to solve the nesting of either 
of these interrupts.

There are subtle differences between Intel and AMD in how the actual 
interrupt gets handled when the processor is currently running a HVM 
guest, which is why the patch in this thread is "Intel only", because 
the Intel system "eats" the NMI, and it needs to be "reissued". On AMD, 
the interrupts are held pending until the guest has exited into the 
Hypervisor, and then taken after the processor executes the STGI (Set 
Global Interrupt Enable) instruction - analogous to what happens when 
you have a CLI and STI for ordinary interrupts.

The issues with regards to nesting of NMI and MCE is completely 
different from the "how do we issue an NMI from the HVM handling code 
when the guest got interrupted by NMI".

Nested NMI and nested MCE is the same problem on both AMD and Intel 
processors, and need a completely separate solution [Andy is working on 
this].

--
Mats

  parent reply	other threads:[~2012-11-15 17:03 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 [this message]
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

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=50A52051.9010807@citrix.com \
    --to=mats.petersson@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).