[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 17:15, Tim Deegan wrote:
At 17:03 +0000 on 15 Nov (1352998993), Mats Petersson wrote:
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".
My reading of svm_ctxt_switch_{to,from} makes me disagree with this.
AFAICT, on SVM we're not using dedicated stacks at all.
In SVM, the VMRUN returns to whatever stack you had before the VMRUN. This is not what I'm talking about, however. The stack used for the NMI and MCE comes from the interrupt descriptor entry for those respective vectors.

I'm fairly sure (but I haven't followed all the code-paths to verify this) that both AMD and Intel HVM code uses the same stack when a VMEXIT happens (as in, the the value in RSP, at least nominally, the same value each time you end up in the {svm,vmx}_exit_handler(), but the value may vary from one time to another, and probably isn't the exact same on an Intel vs. AMD comparison). The Intel solution is slightly different as to "how you end up with the RSP value you want to be at", but that's a beside the point.

Either way, what stack we are on at VMEXIT shouldn't matter to the handling of NMI or MCE, but we should avoid using the "current" stack to handle NMI, in case it's somehow causing further problems to do so, and we need the NMI to "get out of a problem". Similarly for MCE - if the memory used by RSP is bad, we probably don't want to reboot the machine by using it to store the return address for MCE (although I'm not sure we can completely avoid that)...

So in conclusion, the do_mce_exception() call probably should be a __asm__ __volatile__("int $X"), where X is the relevant vector. [Although I admit that when we take an MCE exception from HVM, it hopefully isn't using the Hypervisor stack that the VMEXIT happens to use... That would be rather bad in all manner of ways, and of course, the MCE stack may also be equally bad!]

--
Mats

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".
Yes.  As I said, we should take the fix to the VMX NMI handling now, and
sort out the nesting separately.

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