From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932104AbbFQKAT (ORCPT ); Wed, 17 Jun 2015 06:00:19 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:33305 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753516AbbFQKAP (ORCPT ); Wed, 17 Jun 2015 06:00:15 -0400 Date: Wed, 17 Jun 2015 12:00:09 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: x86@kernel.org, linux-kernel@vger.kernel.org, =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Rik van Riel , Oleg Nesterov , Denys Vlasenko , Borislav Petkov , Kees Cook , Brian Gerst , Linus Torvalds Subject: Re: [RFC/INCOMPLETE 08/13] x86/entry/64: Migrate 64-bit syscalls to new exit hooks Message-ID: <20150617100009.GA5673@gmail.com> References: <0ee44a97cf6ffd9a948425b27fa8d48fa271c440.1434485184.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ee44a97cf6ffd9a948425b27fa8d48fa271c440.1434485184.git.luto@kernel.org> 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 * Andy Lutomirski wrote: > This is separate for ease of bisection. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/entry_64.S | 68 +++++------------------------------------------ > 1 file changed, 7 insertions(+), 61 deletions(-) > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index 33acc3dcc281..a5044d7a9d43 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -229,6 +229,11 @@ entry_SYSCALL_64_fastpath: > */ > USERGS_SYSRET64 > > +GLOBAL(int_ret_from_sys_call_irqs_off) > + TRACE_IRQS_ON > + ENABLE_INTERRUPTS(CLBR_NONE) > + jmp int_ret_from_sys_call Any reason why irq state tracking cannot be done in C as well, like the rest of the irq state tracking code? (Btw., context tracking could in theory be merged with irq state tracking, they have similar needs.) One complication would be that we have not saved pt_regs yet: > @@ -272,69 +277,10 @@ tracesys_phase2: > * Has correct iret frame. > */ > GLOBAL(int_ret_from_sys_call) > SAVE_EXTRA_REGS > + movq %rsp, %rdi > + call syscall_return_slowpath /* returns with IRQs disabled */ > RESTORE_EXTRA_REGS ... but we can stipulate that IRQs can be enabled after we've constructed pt_regs. The few cycles constant added latency there isn't an issue - maintainability of the code is. ... this would also allow us to get rid of paravirt interface uglies like 'CLBR_NONE' which has no place in generic entry code. With such a conversion very little 'high level, complex logic' should be left in assembly and as much as possible should be moved to C: that way we can integrate it all on the C level and achieve similar speedups as with assembly. Half-done will reduce that potential of speedups through integration. A bit like how we have done it with do_page_fault(): there's very little left at the assembly level, still it has not kept people from micro-optimizing the heck out of the low level page fault code. Thanks, Ingo