[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] [RFC PATCH] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler
At 14:56 +0000 on 13 Nov (1352818572), Jan Beulich wrote: > >>> On 13.11.12 at 15:43, Tim Deegan <tim@xxxxxxx> 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |