From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752644AbbIPNFs (ORCPT ); Wed, 16 Sep 2015 09:05:48 -0400 Received: from foss.arm.com ([217.140.101.70]:55283 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbbIPNFr (ORCPT ); Wed, 16 Sep 2015 09:05:47 -0400 Date: Wed, 16 Sep 2015 14:05:49 +0100 From: Will Deacon To: Daniel Thompson Cc: "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , "linux-kernel@vger.kernel.org" , "patches@linaro.org" , "linaro-kernel@lists.linaro.org" , John Stultz , Sumit Semwal , Marc Zyngier , Andrew Thoelke , Dave P Martin Subject: Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Message-ID: <20150916130549.GJ28771@arm.com> References: <1442237181-17064-1-git-send-email-daniel.thompson@linaro.org> <1442237181-17064-4-git-send-email-daniel.thompson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442237181-17064-4-git-send-email-daniel.thompson@linaro.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 On Mon, Sep 14, 2015 at 02:26:17PM +0100, Daniel Thompson wrote: > Currently alternatives are applied very late in the boot process (and > a long time after we enable scheduling). Some alternative sequences, > such as those that alter the way CPU context is stored, must be applied > much earlier in the boot sequence. > > Introduce apply_alternatives_early() to allow some alternatives to be > applied immediately after we detect the CPU features of the boot CPU. > > Currently apply_alternatives_all() is not optimized and will re-patch > code that has already been updated. This is harmless but could be > removed by adding extra flags to the alternatives store. > > Signed-off-by: Daniel Thompson > --- > arch/arm64/include/asm/alternative.h | 1 + > arch/arm64/kernel/alternative.c | 15 +++++++++++++++ > arch/arm64/kernel/setup.c | 7 +++++++ > 3 files changed, 23 insertions(+) > > diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h > index d56ec0715157..f9dad1b7c651 100644 > --- a/arch/arm64/include/asm/alternative.h > +++ b/arch/arm64/include/asm/alternative.h > @@ -17,6 +17,7 @@ struct alt_instr { > u8 alt_len; /* size of new instruction(s), <= orig_len */ > }; > > +void __init apply_alternatives_early(void); > void __init apply_alternatives_all(void); > void apply_alternatives(void *start, size_t length); > void free_alternatives_memory(void); > diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c > index ab9db0e9818c..59989a4bed7c 100644 > --- a/arch/arm64/kernel/alternative.c > +++ b/arch/arm64/kernel/alternative.c > @@ -117,6 +117,21 @@ static void __apply_alternatives(void *alt_region) > } > > /* > + * This is called very early in the boot process (directly after we run > + * a feature detect on the boot CPU). No need to worry about other CPUs > + * here. > + */ > +void apply_alternatives_early(void) > +{ > + struct alt_region region = { > + .begin = __alt_instructions, > + .end = __alt_instructions_end, > + }; > + > + __apply_alternatives(®ion); > +} How do you choose which alternatives are applied early and which are applied later? AFAICT, this just applies everything before we've established the capabilities of the CPUs in the system, which could cause problems for big/little SoCs. Also, why do we need this for the NMI? Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Wed, 16 Sep 2015 14:05:49 +0100 Subject: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process In-Reply-To: <1442237181-17064-4-git-send-email-daniel.thompson@linaro.org> References: <1442237181-17064-1-git-send-email-daniel.thompson@linaro.org> <1442237181-17064-4-git-send-email-daniel.thompson@linaro.org> Message-ID: <20150916130549.GJ28771@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Sep 14, 2015 at 02:26:17PM +0100, Daniel Thompson wrote: > Currently alternatives are applied very late in the boot process (and > a long time after we enable scheduling). Some alternative sequences, > such as those that alter the way CPU context is stored, must be applied > much earlier in the boot sequence. > > Introduce apply_alternatives_early() to allow some alternatives to be > applied immediately after we detect the CPU features of the boot CPU. > > Currently apply_alternatives_all() is not optimized and will re-patch > code that has already been updated. This is harmless but could be > removed by adding extra flags to the alternatives store. > > Signed-off-by: Daniel Thompson > --- > arch/arm64/include/asm/alternative.h | 1 + > arch/arm64/kernel/alternative.c | 15 +++++++++++++++ > arch/arm64/kernel/setup.c | 7 +++++++ > 3 files changed, 23 insertions(+) > > diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h > index d56ec0715157..f9dad1b7c651 100644 > --- a/arch/arm64/include/asm/alternative.h > +++ b/arch/arm64/include/asm/alternative.h > @@ -17,6 +17,7 @@ struct alt_instr { > u8 alt_len; /* size of new instruction(s), <= orig_len */ > }; > > +void __init apply_alternatives_early(void); > void __init apply_alternatives_all(void); > void apply_alternatives(void *start, size_t length); > void free_alternatives_memory(void); > diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c > index ab9db0e9818c..59989a4bed7c 100644 > --- a/arch/arm64/kernel/alternative.c > +++ b/arch/arm64/kernel/alternative.c > @@ -117,6 +117,21 @@ static void __apply_alternatives(void *alt_region) > } > > /* > + * This is called very early in the boot process (directly after we run > + * a feature detect on the boot CPU). No need to worry about other CPUs > + * here. > + */ > +void apply_alternatives_early(void) > +{ > + struct alt_region region = { > + .begin = __alt_instructions, > + .end = __alt_instructions_end, > + }; > + > + __apply_alternatives(®ion); > +} How do you choose which alternatives are applied early and which are applied later? AFAICT, this just applies everything before we've established the capabilities of the CPUs in the system, which could cause problems for big/little SoCs. Also, why do we need this for the NMI? Will