From: Robin Murphy <robin.murphy@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>, Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
will@kernel.org, mark.rutland@arm.com, anshuman.khandual@arm.com,
krisman@suse.de, broonie@kernel.org, james.morse@arm.com,
ionela.voinescu@arm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] arm64: cpufeature: Change 32-bit EL0 to display enabled cores
Date: Thu, 19 Oct 2023 11:14:29 +0100 [thread overview]
Message-ID: <0d8ccead-d4e0-47d6-91f0-69709086c3a7@arm.com> (raw)
In-Reply-To: <25ba377a-c590-1a1c-6be3-e268a6b300c9@arm.com>
On 2023-10-18 16:42, Jeremy Linton wrote:
> On 10/18/23 07:43, Marc Zyngier wrote:
>> On Tue, 17 Oct 2023 20:15:43 +0100,
>> Jeremy Linton <jeremy.linton@arm.com> wrote:
>>>
>>> Hi,
>>>
>>> On 10/17/23 13:01, Marc Zyngier wrote:
>>>> On Tue, 17 Oct 2023 06:23:22 +0100,
>>>> Jeremy Linton <jeremy.linton@arm.com> wrote:
>>>>>
>>>>> Now that we have the ability to display the list of cores
>>>>> with a feature when it is selectivly enabled, lets display the
>>>>> cores enabled for 32-bit use at EL0.
>>>>>
>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>> ---
>>>>> arch/arm64/kernel/cpufeature.c | 15 +++++++++++++--
>>>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/kernel/cpufeature.c
>>>>> b/arch/arm64/kernel/cpufeature.c
>>>>> index b7b67bac0e60..512cbe446b41 100644
>>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>>> @@ -1533,8 +1533,17 @@ static bool has_32bit_el0(const struct
>>>>> arm64_cpu_capabilities *entry, int scope)
>>>>> if (!has_cpuid_feature(entry, scope))
>>>>> return allow_mismatched_32bit_el0;
>>>>> - if (scope == SCOPE_SYSTEM)
>>>>> - pr_info("detected: 32-bit EL0 Support\n");
>>>>> + if (scope == SCOPE_SYSTEM) {
>>>>> + struct arm64_cpu_capabilities *has_32bit;
>>>>> +
>>>>> + has_32bit = (struct arm64_cpu_capabilities *)entry;
>>>>> +
>>>>> + has_32bit->cpus = system_32bit_el0_cpumask();
>>>>
>>>> This seems rather dodgy. 'entry' comes from a static const array which
>>>> will, in all likelihood be mapped R/O pretty soon after the initial
>>>> CPU bringup. Try offlining/onlining a CPU and you should see a
>>>> firework similar to what I have below (I hacked the CnP property, but
>>>> that's no different from what you are doing):
>>>
>>> Yes, dodgy is a good word. The other choices, maintain a mask just for
>>> the print or dump the static key and always use the cpu_32bit_el0_mask
>>> or some combination, weren't much better in the "ick" category. If
>>> anyone sees a better way I'm open to suggestion, although simply
>>> dropping this last patch is fine too.
>>
>> An obvious choice would be to replace the 'cpus' cpumask with a
>> function that evaluates a cpumask stored separately.
>
> Right, I was too busy trying to cleanup the 32-bit mask, that works too.
But if a cpumask does already exist, wouldn't the *most* logical thing
be to use it? If it is somehow harmful to the existing machinery to set
all of the CPUs in cpu_32bit_el0_mask if all of the CPUs support 32-bit
EL0, that seems like a mind-bogglingly dumb design which deserves fixing
in its own right.
To me the obvious thing would be to allocate and populate
cpu_32bit_el0_mask unconditionally so the initial feature detection can
work as normal, and then if anyone's really really bothered, free it
again later if we determine there's no mismatch.
Thanks,
Robin.
next prev parent reply other threads:[~2023-10-19 10:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 5:23 [PATCH v2 0/3] arm64: cpufeatures: Display " Jeremy Linton
2023-10-17 5:23 ` [PATCH v2 1/3] arm64: cpufeature: Display the set of cores with a feature Jeremy Linton
2023-10-20 13:06 ` Punit Agrawal
2023-10-17 5:23 ` [PATCH v2 2/3] arm64: cpufeature: Change DBM to display enabled cores Jeremy Linton
2023-10-17 5:23 ` [PATCH v2 3/3] arm64: cpufeature: Change 32-bit EL0 " Jeremy Linton
2023-10-17 18:01 ` Marc Zyngier
2023-10-17 19:15 ` Jeremy Linton
2023-10-18 12:43 ` Marc Zyngier
2023-10-18 15:42 ` Jeremy Linton
2023-10-19 10:14 ` Robin Murphy [this message]
2023-10-23 17:33 ` (subset) [PATCH v2 0/3] arm64: cpufeatures: Display " Catalin Marinas
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=0d8ccead-d4e0-47d6-91f0-69709086c3a7@arm.com \
--to=robin.murphy@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=james.morse@arm.com \
--cc=jeremy.linton@arm.com \
--cc=krisman@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.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
all inboxes | Powered by JetHome®