From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754607AbbDTJoK (ORCPT ); Mon, 20 Apr 2015 05:44:10 -0400 Received: from foss.arm.com ([217.140.101.70]:44150 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754084AbbDTJoH (ORCPT ); Mon, 20 Apr 2015 05:44:07 -0400 Date: Mon, 20 Apr 2015 10:44:01 +0100 From: Mark Rutland To: Vinicius Tinti Cc: "Richard W.M. Jones" , Will Deacon , Kyle McMartin , Catalin Marinas , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH] arm64: annotate psci invoke functions as notrace Message-ID: <20150420094400.GC15875@leverpostej> References: <20150218172638.GB1772@redacted.bos.redhat.com> <20150224175950.GA28145@redhat.com> <20150224181137.GY9714@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >> > -static noinline int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1, > >> > +static noinline notrace int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1, > >> > u64 arg2) [...] > >> > -static noinline int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1, > >> > +static noinline notrace int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1, > >> > u64 arg2) [...] > > As I mentioned in my reply, Will was waiting for -rc1 to post our > > patches (which move this out to asm for arm and arm64). He's out of the > > office today, but I expect they will be posted tomorrow (and hopefully > > queued shortly thereafter). > > > > Mark. [...] > Hi, > > I notice that the mainline kernel moved these psci calls to a separate > file but I > was wondering how can it guarantee that the function register > placement will hold? The commit in question [1] moves the issuing of the HVC and SMC into an assembly file, and the C code calls these as opaque functions. Due to this the compiler *must* respect the AAPCS and place the values into the expected registers (x0 to x3). > If you build the kernel with -O0 some function register allocation changes as > opposed to -O2 or if you use another compiler such as Clang. Surely this is only true if all the functions live in the same compilation unit? Or perhaps with LTO (surely this cannot modify assembly which was not generated by the compiler)? If the compiler is rearranging registers for a function call it knows nothing about, in violation of the AAPCS, then that compiler sounds broken. > In LLVMLinux we solved this by using one of Andy's solution which is > to use register placement: > > register u32 function_id_r0 asm ("r0") = function_id; > register u32 arg0_r1 asm ("r1") = arg0; > register u32 arg1_r2 asm ("r2") = arg1; > register u32 arg2_r3 asm ("r3") = arg2; Surely this is only necessary when the call issuing function is implemented in C? Mark. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f5e0a12ca2d939e47995f73428d9bf1ad372b289 From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Mon, 20 Apr 2015 10:44:01 +0100 Subject: [PATCH] arm64: annotate psci invoke functions as notrace In-Reply-To: References: <20150218172638.GB1772@redacted.bos.redhat.com> <20150224175950.GA28145@redhat.com> <20150224181137.GY9714@leverpostej> Message-ID: <20150420094400.GC15875@leverpostej> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > >> > -static noinline int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1, > >> > +static noinline notrace int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1, > >> > u64 arg2) [...] > >> > -static noinline int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1, > >> > +static noinline notrace int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1, > >> > u64 arg2) [...] > > As I mentioned in my reply, Will was waiting for -rc1 to post our > > patches (which move this out to asm for arm and arm64). He's out of the > > office today, but I expect they will be posted tomorrow (and hopefully > > queued shortly thereafter). > > > > Mark. [...] > Hi, > > I notice that the mainline kernel moved these psci calls to a separate > file but I > was wondering how can it guarantee that the function register > placement will hold? The commit in question [1] moves the issuing of the HVC and SMC into an assembly file, and the C code calls these as opaque functions. Due to this the compiler *must* respect the AAPCS and place the values into the expected registers (x0 to x3). > If you build the kernel with -O0 some function register allocation changes as > opposed to -O2 or if you use another compiler such as Clang. Surely this is only true if all the functions live in the same compilation unit? Or perhaps with LTO (surely this cannot modify assembly which was not generated by the compiler)? If the compiler is rearranging registers for a function call it knows nothing about, in violation of the AAPCS, then that compiler sounds broken. > In LLVMLinux we solved this by using one of Andy's solution which is > to use register placement: > > register u32 function_id_r0 asm ("r0") = function_id; > register u32 arg0_r1 asm ("r1") = arg0; > register u32 arg1_r2 asm ("r2") = arg1; > register u32 arg2_r3 asm ("r3") = arg2; Surely this is only necessary when the call issuing function is implemented in C? Mark. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f5e0a12ca2d939e47995f73428d9bf1ad372b289