[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.