On 03/12/2016 07:05 PM, Andy Lutomirski wrote: > On Sat, Mar 12, 2016 at 9:53 AM, Denys Vlasenko <dvlas...@redhat.com> wrote: >> On 03/12/2016 04:38 PM, Ingo Molnar wrote: >>> >>> * Denys Vlasenko <dvlas...@redhat.com> wrote: >>> >>>> Use of a temporary R8 register here seems to be unnecessary. >>>> >>>> "push %r8" is a two-byte insn (it needs REX prefix to specify R8), >>>> "push $0" is two-byte too. It seems just using the latter would be >>>> no worse. >>>> >>>> Thus, code had an unnecessary "xorq %r8,%r8" insn. >>> >>> Neat! >>> >>>> It probably costs nothing in execution time here since we are probably >>>> limited by store bandwidth at this point, but still. >>>> >>>> Run-tested under QEMU: 32-bit calls still work: >>>> >>>> / # ./test_syscall_vdso32 >>> >>> Did you manage to test all 3 compat variants: >>> >>>> @@ -72,24 +72,23 @@ ENTRY(entry_SYSENTER_compat) >>>> @@ -205,17 +204,16 @@ ENTRY(entry_SYSCALL_compat) >>>> @@ -316,11 +314,10 @@ ENTRY(entry_INT80_compat) >> >> Yes. >> >> test_syscall_vdso32 checks vdso syscall (if available) >> and direct int80 syscall. >> Booting two times, with different qemu flags: >> >> qemu-system-x86_64 -cpu Opteron_G4 >> qemu-system-x86_64 -cpu SandyBridge >> >> makes kernel choose either SYSCALL or SYSENTER vdso. >> So it's all covered. > > How carefully did you check the latter bit?
To double-check, I built a kernel with intentionally crippled SYSENTER handling (infinite loop). qemu-system-x86_64 -cpu Opteron_G4 - works qemu-system-x86_64 -cpu SandyBridge - ./test_syscall_vdso_32 hung This proves that -cpu SandyBridge does cause SYSENTER path to be used.
