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

From: Robin Murphy
Date: Wed Feb 19 2025 - 11:29:28 EST


On 2025-02-19 3:43 pm, Ryan Roberts wrote:
On 19/02/2025 15:39, Robin Murphy wrote:
Hi Miko,

On 2025-02-19 2:38 pm, Mikołaj Lenczewski wrote:
The Break-Before-Make cpu feature supports multiple levels (levels 0-2),
and this commit adds a dedicated BBML2 cpufeature to test against
support for.

This is a system feature as we might have a big.LITTLE architecture
where some cores support BBML2 and some don't, but we want all cores to
be available and BBM to default to level 0 (as opposed to having cores
without BBML2 not coming online).

To support BBML2 in as wide a range of contexts as we can, we want not
only the architectural guarantees that BBML2 makes, but additionally
want BBML2 to not create TLB conflict aborts. Not causing aborts avoids
us having to prove that no recursive faults can be induced in any path
that uses BBML2, allowing its use for arbitrary kernel mappings.
Support detection of such CPUs.

If this may be used for splitting/compacting userspace mappings, then similarly
to 6e192214c6c8 ("iommu/arm-smmu-v3: Document SVA interaction with new pagetable
features"), strictly we'll also want a check in arm_smmu_sva_supported() to make
sure that the SMMU is OK with BBML2 behaviour too, and disallow SVA if not. Note
that the corresponding SMMUv3.2-BBML2 feature is already strict about TLB
conflict aborts, so is comparatively nice and straightforward.

Thanks for catching this, Robin, as I completely forgot to pass this onto Miko
yesterday after our conversation. I suggest we tack a commit on to the end of
this series to cover that?

I think that strictly this is not needed for Yang's series since that only uses
BBML2 for kernel mappings, and those pgtables would never be directly shared
with the SMMU.

Yup, it's really more just a theoretical correctness concern - certainly Arm's implementations from MMU-700 onwards do support BBML2, while MMU-600 is now sufficiently old that nobody is likely to pair it with new BBML-capable CPUs anyway - so it's just to cover the gap that in principle there may be 3rd-party implementations which might get confused.

Cheers,
Robin.