Thread (48 messages) 48 messages, 5 authors, 2021-06-10

Re: [PATCH v8 02/19] arm64: Allow mismatched 32-bit EL0 support

From: Will Deacon <will@kernel.org>
Date: 2021-06-04 13:50:43
Also in: linux-arm-kernel, lkml

On Fri, Jun 04, 2021 at 01:04:27PM +0100, Mark Rutland wrote:
On Fri, Jun 04, 2021 at 12:05:27PM +0100, Will Deacon wrote:
quoted
On Fri, Jun 04, 2021 at 10:38:08AM +0100, Mark Rutland wrote:
quoted
On Thu, Jun 03, 2021 at 06:44:14PM +0100, Will Deacon wrote:
quoted
On Thu, Jun 03, 2021 at 01:37:15PM +0100, Mark Rutland wrote:
quoted
On Wed, Jun 02, 2021 at 05:47:02PM +0100, Will Deacon wrote:
quoted
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
quoted
quoted
quoted
quoted
That said. I reckon this could be much cleaner if we maintained separate
caps:

ARM64_ALL_CPUS_HAVE_32BIT_EL0
ARM64_SOME_CPUS_HAVE_32BIT_EL0

... and allow arm64_mismatched_32bit_el0 to be set dependent on
ARM64_SOME_CPUS_HAVE_32BIT_EL0. With that, this can be simplified to:

static inline bool system_supports_32bit_el0(void)
{
	return (cpus_have_const_cap(ARM64_ALL_CPUS_HAVE_32BIT_EL0)) ||
		static_branch_unlikely(&arm64_mismatched_32bit_el0))
Something similar was discussed in November last year but this falls
apart with late onlining because its not generally possible to tell whether
you've seen all the CPUs or not.
Ah; is that for when your boot CPU set is all AArch32-capable, but a
late-onlined CPU is not?

I assume that we require at least one of the set of boot CPUs to be
AArch32 cpable, and don't settle the compat hwcaps after userspace has
started.
Heh, you assume wrong :)

When we allow the mismatch, then we do actually defer initialisation of
the compat hwcaps until we see a 32-bit CPU. That's fine, as they won't
be visible to userspace until then anyway (PER_LINUX32 is unavailable).
That sounds quite scary, to me, though I don't have a concrete problem
to hand. :/

Do we really need to support initializing that so late? For all other
caps we've settled things when the boot CPUs come up, and it's
unfortunate to have to treat this differently.
I think it's the nature of the beast, unfortunately. Since we're talking
about multiple generations of SoCs rather than just one oddball design,
then placing artificial restrictions on the boot CPUs doesn't feel like
it will last very long.
I'll go see if there's anything that's liable to break today.
Please let me know if you find anything.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help