Received: by 10.192.165.148 with SMTP id m20csp5592487imm; Wed, 9 May 2018 07:29:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpRjvayYjjThm8GgAosaqnoJzcewn+JBoT/NSdd8IpJlh3tBl+Q0HHHiEfymTrR/3r7f10r X-Received: by 10.98.0.194 with SMTP id 185mr44273216pfa.238.1525876173899; Wed, 09 May 2018 07:29:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525876173; cv=none; d=google.com; s=arc-20160816; b=ghtaORAmIB0CFfWVSB1ZCIwvOBqQ5D6v34CyMnuGRR6x/kmUjOcPP4OZzD0diGVVmy K/gZEu+giiSrTwychkYL7KVVNg0mhyyxuseFoe/cmsvQ5DM3RAHVg5gOUmlDmZLxXFXY L6qkjgfnONkfTdXG7+WfGiuFD44s64amv/RnihXT29xAktNOOa2CotDCgEomVMPP4Rry rvl10z/MEtI7mdQh43RocYniIb7vrqt0rr9LXO2fFqr5xKeBLsKy8OtAFPgyalKHf3xb PkBapWBccEw/S5NE6NR15eDqwEsGwg2L3W8GhLwQtnQK5Bdw4XNtO99lpQdRajfBTY9V lCcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=w358JUYD1YYEFKTZsZEd4IPPkKCTMP+zJwiZA1QmFkY=; b=biIeRHw3EkIzOgzKGotB7M4O6ogiwWp+H2rCmcZvILtt7KfoOIiEFl9QJFF6tPJ/rw 96tdqYZ7LQ2xWx581umFZLSSl9DJLX2F4j4P15OmUhWr8pH0M3M6rNReVieccP24hb+s DosAOqSV2RAjgqIGllyPr35u5WNzw2RbS1hdMMOYTcCL3tI5tRQSJp0m2Vh18LaHcTVt g7W9SVuDd5v80lMF+c+pZ4WGDQG+GaOdLpfSUG2uhd81FQkXLx6qby6iYPElzpKDkBv8 1tioBeiOTVa24RY8OxhDELn9A4O+Xrzsi+uHMZhFcAzgzb6dyp+rqwV8HKmekVplBvRs Eh6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NtVzmUKu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h68si27169384pfa.238.2018.05.09.07.29.17; Wed, 09 May 2018 07:29:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NtVzmUKu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935061AbeEIO16 (ORCPT + 99 others); Wed, 9 May 2018 10:27:58 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35374 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934617AbeEIO14 (ORCPT ); Wed, 9 May 2018 10:27:56 -0400 Received: by mail-wm0-f66.google.com with SMTP id o78-v6so28327760wmg.0 for ; Wed, 09 May 2018 07:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=w358JUYD1YYEFKTZsZEd4IPPkKCTMP+zJwiZA1QmFkY=; b=NtVzmUKuorZNYYkACkMIIYKlNKyq0mk7tLtEl1IXxg/F1HG7P/v+uolhkKN2RMZriZ o4u8thBaeg7EwYfUq8W4A8uwz5QPvTo2M43g1PJ2DlIdmqIyTePqkr1vYmNIMH/btZxR kQCkAUHf3uOpXLTvK8MxmPeh42WTfpUFMTQHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=w358JUYD1YYEFKTZsZEd4IPPkKCTMP+zJwiZA1QmFkY=; b=FYR931iRQEURsVZ8AhOmT8Z8/TT0rSjqaGyaDIUv/jJCHAyhLNAospE42MAmO7BK8R YUUj7NMOttaiZvyzRAiEtOzvcGdlQUflVTJe1h1I5sQSb58S9H/A1EVvvi3kMcjSj39w sIvkotECuFj1NdNOqYIxBmLjKl+2zgF+FZQ9txIo0L5pvRUfXm6qw66Y+FZZGq0EhtAB 7X13K54UsGpZJjtuS3qQu2P2waXPmgm7PX4X2vnxQsvtI8B0SkIQsP29pkouWTdMi5iy pdtx+GkrYLkI6A0BtRiMxiqVvjfURHCVdla5XYgFQbGCL1o6g0Ayl3H9pg2HDPkbr83N lDdA== X-Gm-Message-State: ALKqPwcUxvDk0rAg5vWpKzxwocANft9SGtwFMchWlDL2XaDABvE/nut/ 8bp3qJZozKDcSXC3pXwWLCHUDQ== X-Received: by 10.28.230.78 with SMTP id d75mr5813734wmh.101.1525876075295; Wed, 09 May 2018 07:27:55 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id m15-v6sm28772999wri.8.2018.05.09.07.27.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 May 2018 07:27:54 -0700 (PDT) Date: Wed, 9 May 2018 15:27:52 +0100 From: Daniel Thompson To: Julien Thierry Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, marc.zyngier@arm.com, james.morse@arm.com, Catalin Marinas , Will Deacon , Suzuki K Poulose Subject: Re: [PATCH v2 2/6] arm64: alternative: Apply alternatives early in boot process Message-ID: <20180509142752.redewrpymwvuzgbv@holly.lan> References: <1516190084-18978-1-git-send-email-julien.thierry@arm.com> <1516190084-18978-3-git-send-email-julien.thierry@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 04, 2018 at 11:06:56AM +0100, Julien Thierry wrote: > Hi, > > In order to prepare the v3 of this patchset, I'd like people's opinion on > what this patch does. More below. > > On 17/01/18 11:54, Julien Thierry wrote: > > From: Daniel Thompson > > > > 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. > > > > Signed-off-by: Daniel Thompson > > Signed-off-by: Julien Thierry > > Cc: Catalin Marinas > > Cc: Will Deacon > > --- > > arch/arm64/include/asm/alternative.h | 1 + > > arch/arm64/kernel/alternative.c | 39 +++++++++++++++++++++++++++++++++--- > > arch/arm64/kernel/smp.c | 6 ++++++ > > 3 files changed, 43 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h > > index 4a85c69..1fc1cdb 100644 > > --- a/arch/arm64/include/asm/alternative.h > > +++ b/arch/arm64/include/asm/alternative.h > > @@ -20,6 +20,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); > > > > diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c > > index 6dd0a3a3..78051d4 100644 > > --- a/arch/arm64/kernel/alternative.c > > +++ b/arch/arm64/kernel/alternative.c > > @@ -28,6 +28,18 @@ > > #include > > #include > > > > +/* > > + * early-apply features are detected using only the boot CPU and checked on > > + * secondary CPUs startup, even then, > > + * These early-apply features should only include features where we must > > + * patch the kernel very early in the boot process. > > + * > > + * Note that the cpufeature logic *must* be made aware of early-apply > > + * features to ensure they are reported as enabled without waiting > > + * for other CPUs to boot. > > + */ > > +#define EARLY_APPLY_FEATURE_MASK BIT(ARM64_HAS_SYSREG_GIC_CPUIF) > > + > > Following the change in the cpufeature infrastructure, > ARM64_HAS_SYSREG_GIC_CPUIF will have the scope ARM64_CPUCAP_SCOPE_BOOT_CPU > in order to be checked early in the boot process. > > Now, regarding the early application of alternative, I am wondering whether > we can apply all the alternatives associated with SCOPE_BOOT features that > *do not* have a cpu_enable callback. > > Otherwise we can keep the macro to list individually each feature that is > patchable at boot time as the current patch does (or put this info in a flag > within the arm64_cpu_capabilities structure). > > Any thoughts or preferences on this? If I understand ARM64_CPUCAP_SCOPE_BOOT_CPU correctly it certainly seems safe to apply the alternatives early (it means that a CPU that contradicts a CSCOPE_BOOT_CPU won't be allowed to join the system, right?). It also makes the system to apply errata fixes more powerful: maybe a future errata must be applied before we commence threading. This I have a preference for striping this out and relying on SCOPE_BOOT_CPU instead. It's a weak preference though since I haven't studied exactly what errate fixes this will bring into the scope of early boot. I don't think you'll regret changing it. This patch has always been a *total* PITA to rebase so aligning it better with upstream will make it easier to nurse the patch set until the if-and-when point it hits the upstream. Daniel. > Thanks, > > > #define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f) > > #define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset) > > #define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset) > > @@ -105,7 +117,8 @@ static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnp > > return insn; > > } > > > > -static void __apply_alternatives(void *alt_region, bool use_linear_alias) > > +static void __apply_alternatives(void *alt_region, bool use_linear_alias, > > + unsigned long feature_mask) > > { > > struct alt_instr *alt; > > struct alt_region *region = alt_region; > > @@ -115,6 +128,9 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias) > > u32 insn; > > int i, nr_inst; > > > > + if ((BIT(alt->cpufeature) & feature_mask) == 0) > > + continue; > > + > > if (!cpus_have_cap(alt->cpufeature)) > > continue; > > > > @@ -138,6 +154,21 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias) > > } > > > > /* > > + * 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 = (struct alt_instr *)__alt_instructions, > > + .end = (struct alt_instr *)__alt_instructions_end, > > + }; > > + > > + __apply_alternatives(®ion, true, EARLY_APPLY_FEATURE_MASK); > > +} > > + > > +/* > > * We might be patching the stop_machine state machine, so implement a > > * really simple polling protocol here. > > */ > > @@ -156,7 +187,9 @@ static int __apply_alternatives_multi_stop(void *unused) > > isb(); > > } else { > > BUG_ON(patched); > > - __apply_alternatives(®ion, true); > > + > > + __apply_alternatives(®ion, true, ~EARLY_APPLY_FEATURE_MASK); > > + > > /* Barriers provided by the cache flushing */ > > WRITE_ONCE(patched, 1); > > } > > @@ -177,5 +210,5 @@ void apply_alternatives(void *start, size_t length) > > .end = start + length, > > }; > > > > - __apply_alternatives(®ion, false); > > + __apply_alternatives(®ion, false, -1); > > } > > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c > > index 551eb07..37361b5 100644 > > --- a/arch/arm64/kernel/smp.c > > +++ b/arch/arm64/kernel/smp.c > > @@ -453,6 +453,12 @@ void __init smp_prepare_boot_cpu(void) > > * cpuinfo_store_boot_cpu() above. > > */ > > update_cpu_errata_workarounds(); > > + /* > > + * We now know enough about the boot CPU to apply the > > + * alternatives that cannot wait until interrupt handling > > + * and/or scheduling is enabled. > > + */ > > + apply_alternatives_early(); > > } > > > > static u64 __init of_get_cpu_mpidr(struct device_node *dn) > > -- > > 1.9.1 > > > > -- > Julien Thierry