Re: [RESEND PATCH v6 1/3] arm64: Add BBM Level 2 cpu feature

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, May 09, 2025 at 02:49:05PM +0100, Will Deacon wrote:
> On Tue, May 06, 2025 at 03:52:59PM +0100, Ryan Roberts wrote:
> > On 06/05/2025 15:25, Will Deacon wrote:
> > > This penalises large homogeneous systems and it feels unnecessary given
> > > that we have the ability to check this per-CPU. Can you use
> > > ARM64_CPUCAP_BOOT_CPU_FEATURE instead of ARM64_CPUCAP_SYSTEM_FEATURE
> > > to solve this?
> > 
> > We are trying to solve for the case where the boot CPU has BBML2 but a secondary
> > CPU doesn't. (e.g. hetrogeneous system where boot CPU is big and secondary is
> > little and does not advertise the feature. I can't remember if we proved there
> > are real systems with this config - I have vague recollection that we did but my
> > memory is poor...).
> > 
> > My understanding is that for ARM64_CPUCAP_BOOT_CPU_FEATURE, "If the boot CPU
> > has enabled this feature already, then every late CPU must have it". So that
> > would exclude any secondary CPUs without BBML2 from coming online?
> 
> Damn, yes, you're right. However, it still feels horribly hacky to iterate
> over the online CPUs in has_bbml2_noabort() -- the cpufeature framework
> has the ability to query features locally and we should be able to use
> that. We're going to want that should the architecture eventually decide
> on something like BBML3 for this.
> 
> What we have with BBML2_NOABORT seems similar to an hwcap in that we only
> support the capability if all CPUs have it (rejecting late CPUs without it
> in that case) but we can live without it if not all of the early CPUs
> have it. Unlikely hwcaps, though, we shouldn't be advertising this to
> userspace and we can't derive the capability solely from the sanitised
> system registers.
> 
> I wonder if we could treat it like an erratum in some way instead? That
> is, invert things so that CPUs which _don't_ have BBML2_NOABORT are
> considered to have a "BBM_CONFLICT_ABORT" erratum (which we obviously
> wouldn't shout about). Then we should be able to say:
> 
>   - If any of the early CPUs don't have BBML2_NOABORT, then the erratum
>     would be enabled and we wouln't elide BBM.
> 
>   - If a late CPU doesn't have BBML2_NOABORT then it can't come online
>     if the erratum isn't already enabled.
> 
> Does that work? If not, then perhaps the cpufeature/cpuerrata code needs
> some surgery for this.

Ah, I should have read this thread in order. I think we can treat this
as BBML2_NOABORT available as default based on ID regs and use the
allow/deny-list as an erratum.

-- 
Catalin