[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5366D163.9000503@redhat.com>
Date: Mon, 05 May 2014 01:46:43 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...capital.net>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <h.peter.anvin@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Gleb Natapov <gleb@...nel.org>
Subject: Re: [RFC/HACK] x86: Fast return to kernel
Il 02/05/2014 21:51, Linus Torvalds ha scritto:
>> > Also, are you *really* sure that "popf" has the same one-instruction
>> > interrupt shadow that "sti" has? Because I'm not at all sure that is
>> > true, and it's not documented as far as I can tell. In contrast, the
>> > one-instruction shadow after "sti" very much _is_ documented.
> Yeah, I'm pretty sure about this. The only instructions with an
> interrupt shadow are "sti", "mov ss" and "pop ss".
Yep.
> There may be specific microarchitectures that do it for a "popf" that
> enables interrupts too, but that is not documented _anywhere_ I could
> find.
>
> Btw, on the "really easy to get wrong in emulation" note and looking
> at the kernel sources: it looks like KVM gets "pop ss" wrong, and only
> does the shadow on "mov ss".
Thanks, that's useful to know (and easy to fix). Note that in practice
arch/x86/kvm/emulate.c will only emulate POP SS in big real mode or if
the stack is in MMIO memory. The interrupt shadow will be handled by
the processor in all other cases, and Intel calls the bit "Blocking by
MOV SS" even if it also applies to POP SS.
Your suggested trick of splitting the return paths for IF=0/IF=1 can be
also done like this:
movq EFLAGS-ARGOFFSET(%rsp), %rdi
btrq $9, %rdi # Clear IF, save old value in CF
movq %rdi, (%rsi)
...
popfq
jnc 1f # If IF was 0, just return
sti # Using STI gets us an interrupt shadow
1f:
retq
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists