Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753168AbbFIJd3 (ORCPT ); Tue, 9 Jun 2015 05:33:29 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36273 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752672AbbFIJdU (ORCPT ); Tue, 9 Jun 2015 05:33:20 -0400 Date: Tue, 9 Jun 2015 11:33:14 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , Denys Vlasenko , Brian Gerst , Peter Zijlstra , Borislav Petkov , "H. Peter Anvin" , Linus Torvalds , Oleg Nesterov , Thomas Gleixner Subject: Re: [PATCH 2/4] x86/asm/entry: Untangle 'ia32_sysenter_target' into two entry points: entry_SYSENTER_32 and entry_SYSENTER_compat Message-ID: <20150609093314.GA9675@gmail.com> References: <1433752501-15901-1-git-send-email-mingo@kernel.org> <1433752501-15901-3-git-send-email-mingo@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2867 Lines: 79 * Andy Lutomirski wrote: > On Mon, Jun 8, 2015 at 1:34 AM, Ingo Molnar wrote: > > So the SYSENTER instruction is pretty quirky and it has different behavior > > depending on bitness and CPU maker. > > > > Yet we create a false sense of coherency by naming it 'ia32_sysenter_target' > > in both of the cases. > > > > Split the name into its two uses: > > > > ia32_sysenter_target (32) -> entry_SYSENTER_32 > > ia32_sysenter_target (64) -> entry_SYSENTER_compat > > > > Now that I'm rebasing my pile on top of this, I have a minor gripe > about this one. There are (in my mind, anyway), two SYSENTER > instructions: the 32-bit one and the 64-bit one. (That is, there's > SYSENTER32, which happens when you do SYSENTER in 32-bit or compat > mode, and SYSENTER64, which happens when you do SYSENTER in long > mode.) SYSENTER32, from user code's perspective, does the same thing > in either case [1]. That means that it really does make sense that > we'd have two implementations of the same entry point, one written in > 32-bit asm and one written in 64-bit asm. > > The patch I'm rebasing merges the two wrmsrs to MSR_IA32_SYSENTER, and > this change makes it uglier. > > [1] Sort of. We probably have differently nonsensical calling > conventions, but that's our fault and has nothing to do with the > hardware. Did you intend to merge these two wrmsr()s: #ifdef CONFIG_X86_64 void syscall_init(void) { ... wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat); ... } #endif #ifdef CONFIG_X86_32 void enable_sep_cpu(void) { ... wrmsr(MSR_IA32_SYSENTER_EIP, (unsigned long)entry_SYSENTER_32, 0); ... } ... and the new bifurcated names preserve the #ifdef, right? So I mostly agree with you, but still I'm a bit torn about this, for the following reason: - SYSENTER on a 32-bit kernel behaves a bit differently from SYSENTER on a 64-bit kernel: for example on 32-bit kernels we'll return with SYSEXIT, while on 64-bit kernels we return with SYSRET. The difference is small but user-space observable: for example EDX is 0 on SYSRET while it points to ->sysenter_return in the SYSEXIT case. This kind of user-observable assymmetry does not exist for other unified syscall ABIs, such as the INT80 method. So I think that despite having to preserve a small non-unified #ifdef for this initialization, we are still better off naming the two entry points differently, along the pattern we use, because the behavior is slightly different depending on the bitness of the kernel. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/