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

[Tim Deegan <tim@xen.org>]

At 14:56 +0000 on 13 Nov (1352818572), Jan Beulich wrote:
> >>> On 13.11.12 at 15:43, Tim Deegan <tim@xen.org> wrote:
> > The fact that there was a loop and not just a delay in the NMI handling
> > suggests that VMENTER does indeed re-enable NMIs (or at least
> > NMI-exiting) but I couldn't find that in the manual.  In any case, I
> > think the int $2 version is correcter than the direct call as it also
> > disables normal interrupts.
> 
> You're not commenting on the stack aspect and previous approach
> at all: Assuming your self_nmi() approach at least worked
> somewhere, that somewhere would be the place where the "int $2"
> approach would break. In other words - are you confident that
> NMI is _always_ masked when we get there (and hence your
> earlier approach _never_ worked)?

ISWYM.  No, having thought about it a bit more, I'm not confident of
that at all -- at this point in the exit handlers, interrupts are
enabled, so we may already have had an IRET.  So we'd be risking taking
one NMI while handling another (whether we do int $2 or a direct call;
it's bad in either case). :(

I think that the NMI case needs to move to the top of the vmexit
handler, beside the machine_check cases.  Once it's there, either the
direct call (+ artifical iret to clear the masking) or int $2 should be
fine.

Tim.