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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/11/12 11:23, Jan Beulich wrote:
>>>> 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.

But we never need to detect this case.  If we take an NMI and ensure
there is no possibility for a trap before setting the nmi-in-progress
flag (which is not very hard, with it being a handful of instructions in
the handler), then we guarantee that NMIs are still blocked, and thus
cant be reentrant.

Also, for what it is worth, we do have traps on the NMI path in the form
of BUG()s, WARN()s and panic gubbins, although the host is in a fairly
dire state if we actually ever hit any of these.

~Andrew

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

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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