From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 13/16] arm64: Add support for checking errata based on a list of MIDRS
Date: Tue, 30 Jan 2018 15:38:44 +0000	[thread overview]
Message-ID: <951cb77f-c5f3-56f1-abc7-3cc51248e15d@arm.com> (raw)
In-Reply-To: <20180130151644.GG5862@e103592.cambridge.arm.com>
On 30/01/18 15:16, Dave Martin wrote:
> On Fri, Jan 26, 2018 at 03:57:44PM +0000, Suzuki K Poulose wrote:
>> On 26/01/18 14:16, Dave Martin wrote:
>>> On Tue, Jan 23, 2018 at 12:28:06PM +0000, Suzuki K Poulose wrote:
>>>> Add helpers for detecting an errata on list of midr ranges
>>>> of affected CPUs.
>>>
>>> This doesn't describe what the patch does: instead, helpers are being
>>> added for checking whether an MIDR falls in one of multiple affected
>>> model(s) and or revision(s).
>>>
>>> Doing this makes sense, but is it really worth it?
>>
>> Well, we need th MIDR list helpers anyway for other things:
>>    - White list of CPUs where we know KPTI is not needed
>>    - Black list of CPUs where DBM shouldn't be enabled.
>>
>> So all we do is add a new type which could reduce the number of entries.
>>
>>>
>>> We might save 100-200 bytes in the kernel image for now, but a common
>>> workaround for errata on multiple unrelated cpus is surely a rare case.
>>>
>>> Only if there are many such lists, or if the lists become large does
>>> this start to seem a clear win.
>>>
>>>>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>>   arch/arm64/include/asm/cpufeature.h |  1 +
>>>>   arch/arm64/kernel/cpu_errata.c      | 40 ++++++++++++++++++++++---------------
>>>>   2 files changed, 25 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>>> index a3d54c2c411f..70712de687c7 100644
>>>> --- a/arch/arm64/include/asm/cpufeature.h
>>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>>
>>> [...]
>>>
>>>> @@ -330,22 +353,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>>>   #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
>>>>   	{
>>>>   		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>>>> -		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
>>>> -		.enable = enable_psci_bp_hardening,
>>>> -	},
>>>> -	{
>>>> -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>>>> -		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
>>>> -		.enable = enable_psci_bp_hardening,
>>>> -	},
>>>> -	{
>>>> -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>>>> -		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
>>>> -		.enable = enable_psci_bp_hardening,
>>>> -	},
>>>> -	{
>>>> -		.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>>>> -		ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
>>>> +		ERRATA_MIDR_RANGE_LIST(cortex_bp_harden_cpus),
>>>
>>> Could we just use a macro to generate multiple structs, instead of
>>> inventing a new type of struct?
>>
>> We could. Somehow, I don't think we are over engineering much here.
> 
> There is a flipside to this: I commented elsewhere that not allowing
> mutiple match criteria per capability struct complicates verification
> for late CPUs and/or makes it more costly.
> 
> Your changes here do implement support for multiple match criteria,
> albeit only for the specific case of MIDR matching.
> 
> It could be worth generalising this in the future, but that's
> probably not for this series.
It is not that complex, right now. See below.
> 
> OTOH, if MIDR matching is the only scenario where we have duplicate
> cap structs with different match criteria and this patch allows all
> those duplicates to be removed, then is there still a need to walk
> the whole list in verify_local_cpu_features(), as introduced in
> 67948af41f2e ("arm64: capabilities: Handle duplicate entries for a
> capability")?  Or can that now be simplified?
I have added support for this in my v2. So here is what I have done :
1) Continue to use midr_list for capability entries that just matches
MIDRS and share the same enable() call back.
  and
2) Add support for wrapper entries where a capability is determined
by two or more entries with different matches()/enable() call backs.
And that can get rid of the changes introduced in commit 67948af41f2e
("arm64: capabilities: Handle duplicate entries for a capability").
Cheers
Suzuki
next prev parent reply	other threads:[~2018-01-30 15:38 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 12:27 [PATCH 00/16] arm64: Rework cpu capabilities handling Suzuki K Poulose
2018-01-23 12:27 ` [PATCH 01/16] arm64: capabilities: Update prototype for enable call back Suzuki K Poulose
2018-01-23 14:52   ` Dave Martin
2018-01-23 15:38     ` Suzuki K Poulose
2018-01-25 15:36       ` Dave Martin
2018-01-25 16:57         ` Suzuki K Poulose
2018-01-29 16:35           ` Dave Martin
2018-01-23 12:27 ` [PATCH 02/16] arm64: Move errata work around check on boot CPU Suzuki K Poulose
2018-01-23 14:59   ` Dave Martin
2018-01-23 15:07     ` Suzuki K Poulose
2018-01-23 15:11       ` Dave Martin
2018-01-23 12:27 ` [PATCH 03/16] arm64: Move errata capability processing code Suzuki K Poulose
2018-01-23 12:27 ` [PATCH 04/16] arm64: capabilities: Prepare for fine grained capabilities Suzuki K Poulose
2018-01-23 17:33   ` Dave Martin
2018-01-24 18:45     ` Suzuki K Poulose
2018-01-25 13:43       ` Dave Martin
2018-01-25 17:08         ` Suzuki K Poulose
2018-01-25 17:38           ` Dave Martin
2018-01-25 17:33   ` Dave Martin
2018-01-25 17:56     ` Suzuki K Poulose
2018-01-26 10:00       ` Dave Martin
2018-01-26 12:13         ` Suzuki K Poulose
2018-01-23 12:27 ` [PATCH 05/16] arm64: Add flags to check the safety of a capability for late CPU Suzuki K Poulose
2018-01-26 10:10   ` Dave Martin
2018-01-30 11:17     ` Suzuki K Poulose
2018-01-30 14:56       ` Dave Martin
2018-01-30 15:06         ` Suzuki K Poulose
2018-01-23 12:27 ` [PATCH 06/16] arm64: capabilities: Unify the verification Suzuki K Poulose
2018-01-26 11:08   ` Dave Martin
2018-01-26 12:10     ` Suzuki K Poulose
2018-01-29 16:57       ` Dave Martin
2018-01-23 12:28 ` [PATCH 07/16] arm64: capabilities: Filter the entries based on a given type Suzuki K Poulose
2018-01-26 11:22   ` Dave Martin
2018-01-26 12:21     ` Suzuki K Poulose
2018-01-29 17:06       ` Dave Martin
2018-01-23 12:28 ` [PATCH 08/16] arm64: capabilities: Group handling of features and errata Suzuki K Poulose
2018-01-26 11:47   ` Dave Martin
2018-01-26 12:31     ` Suzuki K Poulose
2018-01-29 17:14       ` Dave Martin
2018-01-29 17:22         ` Suzuki K Poulose
2018-01-30 15:06           ` Dave Martin
2018-01-23 12:28 ` [PATCH 09/16] arm64: capabilities: Introduce strict features based on local CPU Suzuki K Poulose
2018-01-26 12:12   ` Dave Martin
2018-01-30 11:25     ` Suzuki K Poulose
2018-01-23 12:28 ` [PATCH 10/16] arm64: Make KPTI strict CPU local feature Suzuki K Poulose
2018-01-26 12:25   ` Dave Martin
2018-01-26 15:46     ` Suzuki K Poulose
2018-01-29 17:24       ` Dave Martin
2018-01-23 12:28 ` [PATCH 11/16] arm64: errata: Clean up midr range helpers Suzuki K Poulose
2018-01-26 13:50   ` Dave Martin
2018-01-23 12:28 ` [PATCH 12/16] arm64: Add helpers for checking CPU MIDR against a range Suzuki K Poulose
2018-01-26 14:08   ` Dave Martin
2018-01-23 12:28 ` [PATCH 13/16] arm64: Add support for checking errata based on a list of MIDRS Suzuki K Poulose
2018-01-26 14:16   ` Dave Martin
2018-01-26 15:57     ` Suzuki K Poulose
2018-01-30 15:16       ` Dave Martin
2018-01-30 15:38         ` Suzuki K Poulose [this message]
2018-01-30 15:58           ` Dave Martin
2018-01-23 12:28 ` [PATCH 14/16] arm64: Add MIDR encoding for Arm Cortex-A55 and Cortex-A35 Suzuki K Poulose
2018-01-23 12:28 ` [PATCH 15/16] arm64: Delay enabling hardware DBM feature Suzuki K Poulose
2018-01-26 14:41   ` Dave Martin
2018-01-26 16:05     ` Suzuki K Poulose
2018-01-30 15:22       ` Dave Martin
2018-01-23 12:28 ` [PATCH 16/16] arm64: Add work around for Arm Cortex-A55 Erratum 1024718 Suzuki K Poulose
2018-01-26 15:33   ` Dave Martin
2018-01-26 16:29     ` Suzuki K Poulose
2018-01-30 15:27       ` Dave Martin
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=951cb77f-c5f3-56f1-abc7-3cc51248e15d@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
  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;
as well as URLs for NNTP newsgroup(s).