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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.11.12 at 11:56, Tim Deegan <tim@xxxxxxx> wrote:
> At 08:07 +0000 on 16 Nov (1353053247), Jan Beulich wrote:
>> > We could potentially solve the problem by having the MCE handler check
>> > whether it's returning to the NMI stack, and do a normal return in that
>> > case.  It's a bit of extra code but only in the MCE handler, which is
>> > not performance-critical. 
>> 
>> Yes, that could solve that nesting case (again not very difficult
>> to implement).
> 
> How about we just have the MCE handler return without IRET in _all_
> cases where it's returning to ring 0?  I think that entirely solves the
> MCE-in-NMI problem, without all the extra mechanism meeded for the
> linux-style solution.

Good suggestion.

>  (Unless we want to allow other traps in either
> the NMI or MCE handlers).

We should absolutely avoid that.

> [And it occurs to me that the linux-style solution is tricky because
> detecting the case where you've taken an NMI and not yet set the
> nmi-in-progress flag is hard in both SVM (in the NMI handler but on the
> normal stack) and VMX (in the _vmexit_ handler and on the normal
> stack).]

Agreed.

> So I guess now I'm suggesting:
>  - MCE never returns to Xen with IRET;

Yes. But that might need care with regard to EFI runtime services
(or maybe not, as we're, at least at present, not switching stacks
there). Nevertheless, to be on the safe side, we could restrict
avoiding the IRET to "Ring 0 and RIP in hypervisor space", as we
know we won't have interrupted the NMI handler if that's not the
case.

>  - NMI handling in handle_vmexit() moves to beside the MCE handling;

Yes.

>  - Explicit IRET-to-self at the end of do_nmi() to unmask NMIs; and

This IRET must then switch to the normal stack, if currently on
the NMI one, which might be a little tricky/fragile.

But then again we're on the NMI one only when we got there
from hypervisor context, and in that specific case we return
without handling softirqs anyway. So perhaps the stack switch
isn't needed, but the IRET-to-self must only be done when the
origin wasn't in hypervisor context.

>  - no int $2. :)

Yippee.

Jan


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