[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



At 16:52 +0000 on 15 Nov (1352998340), Andrew Cooper wrote:
> It is also possible to get a reentrant NMI if there is a pagefault (or
> handful of other possible faults) when trying to execute the iret of
> the NMI itself; NMIs can get re-enabled from the iret of the
> pagefault, and we take a new NMI before attempting to retry the iret
> from the original NMI.

Yes, I hadn't thought of that case.

> > All of this would be moot except for the risk that we might take an MCE
> > while in the NMI handler.  The IRET from the MCE handler re-enables NMIs
> > while we're still in the NMI handler, and a second NMI arriving could
> > break the NMI handler.  In the PV case, it will also clobber the NMI
> > handler's stack.  In the VMX case we would need to see something like
> > (NMI (MCE) (NMI (MCE) (NMI))) for that to happen, but it could.
> 
> There is the MCIP bit in an MCE status MSR which acts as a latch for
> MCEs.  If a new MCE is generated while this bit is set, then a triple
> fault occurs.  An MCE handler is required to set this bit to 0 to
> indicate that it has dealt with the MCE.  However, there is a race
> condition window between setting this bit to 0 and leaving the MCE stack
> during which another MCE can arrive and corrupt the stack.

Sure.  Nested MCEs aren't very interesting to me.  If you're taking MCEs
faster than you can handle them, the difference between one of your CPUs
resetting and the stack getting blasted isn't that much. :)

> I have been looking at appling a similar fix to Linuses fix
> (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3f3c8b8c4b2a34776c3470142a7c8baafcda6eb0)
> to Xen, for both the NMI and MCE stacks.
> 
> Work is currently in the preliminary stages at the moment.

Sounds great!

Tim.

_______________________________________________
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®.