Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753618AbcCLVlc (ORCPT ); Sat, 12 Mar 2016 16:41:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58183 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752487AbcCLVlY (ORCPT ); Sat, 12 Mar 2016 16:41:24 -0500 Message-ID: <56E48D00.6060009@redhat.com> Date: Sat, 12 Mar 2016 22:41:20 +0100 From: Denys Vlasenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Ingo Molnar , Steven Rostedt , Borislav Petkov , "H. Peter Anvin" , Frederic Weisbecker , Will Drewry , Kees Cook , X86 ML , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] x86/asm/entry/32: simplify pushes of zeroed pt_regs->REGs References: <1457715214-7432-1-git-send-email-dvlasenk@redhat.com> <20160312153808.GC17873@gmail.com> <56E4577C.1030107@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Sat, 12 Mar 2016 21:41:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1645 Lines: 50 On 03/12/2016 07:05 PM, Andy Lutomirski wrote: > On Sat, Mar 12, 2016 at 9:53 AM, Denys Vlasenko wrote: >> On 03/12/2016 04:38 PM, Ingo Molnar wrote: >>> >>> * Denys Vlasenko 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.