Hi Alok,
Apologies for the delay.
On Mon, Apr 28, 2025 at 11:25:07PM +0530, ALOK TIWARI wrote:
>
>
> On 28-04-2025 21:05, Mikołaj Lenczewski wrote:
> > +config ARM64_BBML2_NOABORT
> > + bool "Enable support for Break-Before-Make Level 2 detection and usage"
> > + default y
> > + help
> > + FEAT_BBM provides detection of support levels for break-before-make
> > + sequences. If BBM level 2 is supported, some TLB maintenance requirements
> > + can be relaxed to improve performance. We additonally require the
>
> typo additonally -> additionally
Yes, had missed this. Will fix.
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 9c4d6d552b25..7a85a1bdc6e9 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2200,6 +2200,70 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
> > return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
> > }
> > +static bool cpu_has_bbml2_noabort(unsigned int cpu_midr)
> > +{
> > + /*
> > + * We want to allow usage of bbml2 in as wide a range of kernel contexts
> > + * as possible. This list is therefore an allow-list of known-good
> > + * implementations that both support bbml2 and additionally, fulfill the
> > + * extra constraint of never generating TLB conflict aborts when using
> > + * the relaxed bbml2 semantics (such aborts make use of bbml2 in certain
> > + * kernel contexts difficult to prove safe against recursive aborts).
> > + *
> > + * Note that implementations can only be considered "known-good" if their
> > + * implementors attest to the fact that the implementation never raises
> > + * TLBI conflict aborts for bbml2 mapping granularity changes.
> > + */
>
> use bbml2 -> BBML2 to maintain consistency
>
OK, will go through and use BBML2 throughout for consistency.
--
Kind regards,
Mikołaj Lenczewski
