From: Will Deacon <will.deacon@arm.com> To: Daniel Thompson <daniel.thompson@linaro.org> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <Catalin.Marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "patches@linaro.org" <patches@linaro.org>, "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>, John Stultz <john.stultz@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Marc Zyngier <Marc.Zyngier@arm.com>, Andrew Thoelke <Andrew.Thoelke@arm.com>, Dave P Martin <Dave.Martin@arm.com> Subject: Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Date: Wed, 16 Sep 2015 17:24:52 +0100 [thread overview] Message-ID: <20150916162452.GN28771@arm.com> (raw) In-Reply-To: <55F98FF0.7030605@linaro.org> On Wed, Sep 16, 2015 at 04:51:12PM +0100, Daniel Thompson wrote: > On 16/09/15 14:05, Will Deacon wrote: > > 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 <daniel.thompson@linaro.org> > >> --- > > [snip] > >> /* > >> + * 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. > > They are applied twice. This relies for correctness on the fact that > cpufeatures can be set but not unset. > > In other words the boot CPU does a feature detect and, as a result, a > subset of the required alternatives will be applied. However after this > the other CPUs will boot and the the remaining alternatives applied as > before. > > The current implementation is inefficient (because it will redundantly > patch the same code twice) but I don't think it is broken. What about a big/little system where we boot on the big cores and only they support LSE atomics? > > Also, why do we need this for the NMI? > > I was/am concerned that a context saved before the alternatives are > applied might be restored afterwards. If that happens the bit that > indicates what value to put into the PMR would read during the restore > without having been saved first. Applying early ensures that the context > save/restore code is updated before it is ever used. Damn, and stop_machine makes use of local_irq_restore immediately after the patching has completed, so it's a non-starter. Still, special-casing this feature via an explicit apply_alternatives call would be better than moving everything earlier, I think. We also need to think about how an incoming NMI interacts with concurrent patching of later features. I suspect we want to set the I bit, like you do for WFI, unless you can guarantee that no patched sequences run in NMI context. Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Date: Wed, 16 Sep 2015 17:24:52 +0100 [thread overview] Message-ID: <20150916162452.GN28771@arm.com> (raw) In-Reply-To: <55F98FF0.7030605@linaro.org> On Wed, Sep 16, 2015 at 04:51:12PM +0100, Daniel Thompson wrote: > On 16/09/15 14:05, Will Deacon wrote: > > 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 <daniel.thompson@linaro.org> > >> --- > > [snip] > >> /* > >> + * 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. > > They are applied twice. This relies for correctness on the fact that > cpufeatures can be set but not unset. > > In other words the boot CPU does a feature detect and, as a result, a > subset of the required alternatives will be applied. However after this > the other CPUs will boot and the the remaining alternatives applied as > before. > > The current implementation is inefficient (because it will redundantly > patch the same code twice) but I don't think it is broken. What about a big/little system where we boot on the big cores and only they support LSE atomics? > > Also, why do we need this for the NMI? > > I was/am concerned that a context saved before the alternatives are > applied might be restored afterwards. If that happens the bit that > indicates what value to put into the PMR would read during the restore > without having been saved first. Applying early ensures that the context > save/restore code is updated before it is ever used. Damn, and stop_machine makes use of local_irq_restore immediately after the patching has completed, so it's a non-starter. Still, special-casing this feature via an explicit apply_alternatives call would be better than moving everything earlier, I think. We also need to think about how an incoming NMI interacts with concurrent patching of later features. I suspect we want to set the I bit, like you do for WFI, unless you can guarantee that no patched sequences run in NMI context. Will
next prev parent reply other threads:[~2015-09-16 16:24 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-14 13:26 [RFC PATCH v2 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 1/7] irqchip: gic-v3: Reset BPR during initialization Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 2/7] arm64: Add support for on-demand backtrace of other CPUs Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-16 13:05 ` Will Deacon 2015-09-16 13:05 ` Will Deacon 2015-09-16 15:51 ` Daniel Thompson 2015-09-16 15:51 ` Daniel Thompson 2015-09-16 16:24 ` Will Deacon [this message] 2015-09-16 16:24 ` Will Deacon 2015-09-17 13:25 ` Daniel Thompson 2015-09-17 13:25 ` Daniel Thompson 2015-09-17 14:01 ` Will Deacon 2015-09-17 14:01 ` Will Deacon 2015-09-17 15:28 ` Daniel Thompson 2015-09-17 15:28 ` Daniel Thompson 2015-09-17 15:43 ` Will Deacon 2015-09-17 15:43 ` Will Deacon 2015-09-14 13:26 ` [RFC PATCH v2 4/7] arm64: irqflags: Reorder the fiq & async macros Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 5/7] arm64: irqflags: Use ICC sysregs to implement IRQ masking Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 6/7] arm64: Implement IPI_CPU_BACKTRACE using pseudo-NMIs Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 7/7] arm64: irqflags: Automatically identify I bit mis-management Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-18 5:11 ` [RFC PATCH v2 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Jon Masters 2015-09-18 5:11 ` Jon Masters 2015-09-18 11:23 ` Daniel Thompson 2015-09-18 11:23 ` Daniel Thompson 2015-09-22 18:08 ` 答复: " Dingtianhong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150916162452.GN28771@arm.com \ --to=will.deacon@arm.com \ --cc=Andrew.Thoelke@arm.com \ --cc=Catalin.Marinas@arm.com \ --cc=Dave.Martin@arm.com \ --cc=Marc.Zyngier@arm.com \ --cc=daniel.thompson@linaro.org \ --cc=john.stultz@linaro.org \ --cc=linaro-kernel@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=patches@linaro.org \ --cc=sumit.semwal@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.