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: Thu, 17 Sep 2015 15:01:26 +0100 [thread overview]
Message-ID: <20150917140126.GE25634@arm.com> (raw)
In-Reply-To: <55FABF64.3080404@linaro.org>
On Thu, Sep 17, 2015 at 02:25:56PM +0100, Daniel Thompson wrote:
> On 16/09/15 17:24, Will Deacon wrote:
> > 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:
> >>>> /*
> >>>> + * 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?
>
> Hmmnn... I don't think this patch will impact that.
>
> Once something in the boot sequence calls cpus_set_cap() then if there
> is a corresponding alternative then it is *going* to be applied isn't
> it? The patch only means that some of the alternatives will be applied
> early. Once the boot is complete the patched .text should be the same
> with and without the patch.
>
> Have I overlooked some code in the current kernel that prevents a system
> with mis-matched LSE support from applying the alternatives?
Sorry, I'm thinking slightly ahead of myself, but the series from Suzuki
creates a shadow "safe" view of the ID registers in the system,
corresponding to the intersection of CPU features:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/370386.html
In this case, it is necessary to inspect all of the possible CPUs before
we can apply the patching, but as I say above, I'm prepared to make an
exception for NMI because I don't think we can assume a safe value anyway
for a system with mismatched GIC CPU interfaces. I just don't want to
drag all of the alternatives patching earlier as well.
> > 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.
>
> Good point. I'll fix this in the next respin.
Great, thanks. It probably also means that the NMI code needs
__kprobes/__notrace annotations for similar reasons.
Will
next prev parent reply other threads:[~2015-09-17 14:01 UTC|newest]
Thread overview: 18+ 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 ` [RFC PATCH v2 1/7] irqchip: gic-v3: Reset BPR during initialization 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 ` [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Daniel Thompson
2015-09-16 13:05 ` Will Deacon
2015-09-16 15:51 ` Daniel Thompson
2015-09-16 16:24 ` Will Deacon
2015-09-17 13:25 ` Daniel Thompson
2015-09-17 14:01 ` Will Deacon [this message]
2015-09-17 15:28 ` Daniel Thompson
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 ` [RFC PATCH v2 5/7] arm64: irqflags: Use ICC sysregs to implement IRQ masking 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 ` [RFC PATCH v2 7/7] arm64: irqflags: Automatically identify I bit mis-management 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 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=20150917140126.GE25634@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox