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

[Mats Petersson <mats.petersson@citrix.com>]

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