From: Daniel Thompson <daniel.thompson@linaro.org>
To: Will Deacon <will.deacon@arm.com>
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: Thu, 17 Sep 2015 16:28:11 +0100 [thread overview]
Message-ID: <55FADC0B.9080200@linaro.org> (raw)
In-Reply-To: <20150917140126.GE25634@arm.com>
On 17/09/15 15:01, Will Deacon wrote:
> 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.
Thanks. I'll take a close look at this patch set and work out how to
cooperate with it.
However I would like, if I can, to persuade you that we are making an
exception ARM64_HAS_SYSREG_GIC_CPUIF rather than specifically for things
that are NMI related. AFAIK all ARMv8 cores have a GIC_CPUIF and the
system either has a GICv3+ or it doesn't so it shouldn't matter what
core you check the feature on; it is in the nature of the feature we are
detecting that it is safe to patch early.
To some extent this is quibbling about semantics but:
1. Treating this as a general case will put us in a good position if we
ever have to deal with an errata that cannot wait until the system
has nearly finished booting.
2. It makes the resulting code very simple because we can just have a
bitmask indicating which cpufeatures we need should apply early and
which we apply late. That in turn means we don't have to
differentiate NMI alternatives from other alternatives (thus avoiding
a bunch of new alternative macros).
I'm not seeking any kind binding agreement from you before you see the
patch but if you *know* right now that you would nack something that
follows the above thinking then please let me know so I don't waste time
writing it ;-) . If you're on the fence I'll happily write the patch and
you can see what I think then.
>>> 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.
Oops. That I really should have thought about already (but I didn't).
Daniel.
WARNING: multiple messages have this Message-ID (diff)
From: daniel.thompson@linaro.org (Daniel Thompson)
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 16:28:11 +0100 [thread overview]
Message-ID: <55FADC0B.9080200@linaro.org> (raw)
In-Reply-To: <20150917140126.GE25634@arm.com>
On 17/09/15 15:01, Will Deacon wrote:
> 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.
Thanks. I'll take a close look at this patch set and work out how to
cooperate with it.
However I would like, if I can, to persuade you that we are making an
exception ARM64_HAS_SYSREG_GIC_CPUIF rather than specifically for things
that are NMI related. AFAIK all ARMv8 cores have a GIC_CPUIF and the
system either has a GICv3+ or it doesn't so it shouldn't matter what
core you check the feature on; it is in the nature of the feature we are
detecting that it is safe to patch early.
To some extent this is quibbling about semantics but:
1. Treating this as a general case will put us in a good position if we
ever have to deal with an errata that cannot wait until the system
has nearly finished booting.
2. It makes the resulting code very simple because we can just have a
bitmask indicating which cpufeatures we need should apply early and
which we apply late. That in turn means we don't have to
differentiate NMI alternatives from other alternatives (thus avoiding
a bunch of new alternative macros).
I'm not seeking any kind binding agreement from you before you see the
patch but if you *know* right now that you would nack something that
follows the above thinking then please let me know so I don't waste time
writing it ;-) . If you're on the fence I'll happily write the patch and
you can see what I think then.
>>> 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.
Oops. That I really should have thought about already (but I didn't).
Daniel.
next prev parent reply other threads:[~2015-09-17 15:28 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
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 [this message]
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=55FADC0B.9080200@linaro.org \
--to=daniel.thompson@linaro.org \
--cc=Andrew.Thoelke@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Marc.Zyngier@arm.com \
--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 \
--cc=will.deacon@arm.com \
/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: link
Be 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.