Denys Vlasenko <dvlas...@redhat.com> writes: > On 03/23/2015 04:30 AM, Rusty Russell wrote: >> + * They may be about to iret, where they asked us never to >> + * deliver interrupts. In this case, we can emulate that iret >> + * then immediately deliver the interrupt. This is bascially >> + * a noop: the iret would pop the interrupt frame and restore >> + * eflags, and then we'd set it up again. So just restore the >> + * eflags word and jump straight to the handler in this case. >> */ >> + if (cpu->regs->eip >= cpu->lg->noirq_start && >> + (cpu->regs->eip < cpu->lg->noirq_end)) { >> + restore_eflags(cpu); > > In truth, this is not _exactly_ true for irets to CPL3. > > If a new interrupt comes right after iret, then > a new transition to CPL0 will happen. > > This means ss:esp will be loaded from tss.ss0:tss.sp0. > > Meaning, that the new iret frame may be in a different place > than the one which was used by iret.
True. We could check the to-be-restored-CPL and reset the sp. Instead, I've added this comment: /* * They may be about to iret, where they asked us never to * deliver interrupts. In this case, we can emulate that iret * then immediately deliver the interrupt. This is basically * a noop: the iret would pop the interrupt frame and restore * eflags, and then we'd set it up again. So just restore the * eflags word and jump straight to the handler in this case. * * Denys Vlasenko points out that this isn't quite right: if * the iret was returning to userspace, then that interrupt * would reset the stack pointer (which the Guest told us * about via LHCALL_SET_STACK). But unless the Guest is being * *really* weird, that will be the same as the current stack * anyway. */ > There is no good reason for CPL0 code to move iret frame around, > but who knows. As an example, look what 32-bit Linux kernel does > with NMI iret frames... it's mind bending. Fortunately, lguest is allergic to NMIs :) Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/