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

[Marc Zyngier <maz@kernel.org>]

On Thu, 13 Mar 2025 18:22:00 +0000,
Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
> On 13/03/2025 17:34, Marc Zyngier wrote:
> > On Thu, 13 Mar 2025 10:41:10 +0000,
> > Mikołaj Lenczewski <miko.lenczewski@arm.com> wrote:
> >>
> >> diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
> >> index c6b185b885f7..9728faa10390 100644
> >> --- a/arch/arm64/kernel/pi/idreg-override.c
> >> +++ b/arch/arm64/kernel/pi/idreg-override.c
> >> @@ -209,6 +209,7 @@ static const struct ftr_set_desc sw_features __prel64_initconst = {
> >>  		FIELD("nokaslr", ARM64_SW_FEATURE_OVERRIDE_NOKASLR, NULL),
> >>  		FIELD("hvhe", ARM64_SW_FEATURE_OVERRIDE_HVHE, hvhe_filter),
> >>  		FIELD("rodataoff", ARM64_SW_FEATURE_OVERRIDE_RODATA_OFF, NULL),
> >> +		FIELD("nobbml2", ARM64_SW_FEATURE_OVERRIDE_NOBBML2, NULL),
> >>  		{}
> >>  	},
> >>  };
> >> @@ -246,6 +247,7 @@ static const struct {
> >>  	{ "rodata=off",			"arm64_sw.rodataoff=1" },
> >>  	{ "arm64.nolva",		"id_aa64mmfr2.varange=0" },
> >>  	{ "arm64.no32bit_el0",		"id_aa64pfr0.el0=1" },
> >> +	{ "arm64.nobbml2",		"arm64_sw.nobbml2=1" },
> > 
> > Why is that a SW feature? This looks very much like a HW feature to
> > me, and you should instead mask out ID_AA64MMFR2_EL1.BBM, and be done
> > with it. Something like:
> 
> I think this implies that we would expect the BBM field to be advertising BBML2
> support normally and we would check for that as part of the cpufeature
> detection. That's how Miko was doing it in v2, but Yang pointed out that
> AmpereOne, which supports BBML2+NOABORT semantics, doesn't actually advertise
> BBML2 in its MMFR2. So we don't want to check that field, and instead rely
> solely on the MIDR allow-list + a command line override. It was me that
> suggested putting that in the SW feature register, and I think that still sounds
> like the right solution for this situation?

I think this is mixing two different things:

- preventing BBM-L2 from being visible to the kernel: this is what my
  suggestion is doing by nuking an architectural feature in the
  relevant register

- random HW not correctly advertising what they are doing: this is an
  erratum workaround

I'd rather we don't conflate the two things, and make them very
explicitly distinct.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.