[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250228193221.GM5011@ziepe.ca>
Date: Fri, 28 Feb 2025 15:32:21 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Mikołaj Lenczewski <miko.lenczewski@....com>,
Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>
Cc: ryan.roberts@....com, suzuki.poulose@....com,
yang@...amperecomputing.com, catalin.marinas@....com,
will@...nel.org, joro@...tes.org, jean-philippe@...aro.org,
mark.rutland@....com, joey.gouly@....com, oliver.upton@...ux.dev,
james.morse@....com, broonie@...nel.org, maz@...nel.org,
david@...hat.com, akpm@...ux-foundation.org, nicolinc@...dia.com,
mshavit@...gle.com, jsnitsel@...hat.com, smostafa@...gle.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
iommu@...ts.linux.dev
Subject: Re: [PATCH v2 4/4] iommu/arm: Add BBM Level 2 smmu feature
On Fri, Feb 28, 2025 at 06:24:04PM +0000, Mikołaj Lenczewski wrote:
> For supporting BBM Level 2 for userspace mappings, we want to ensure
> that the smmu also supports its own version of BBM Level 2. Luckily, the
> smmu spec (IHI 0070G 3.21.1.3) is stricter than the aarch64 spec (DDI
> 0487K.a D8.16.2), so already guarantees that no aborts are raised when
> BBM level 2 is claimed.
>
> Add the feature and testing for it under arm_smmu_sva_supported().
>
> Signed-off-by: Mikołaj Lenczewski <miko.lenczewski@....com>
> ---
> arch/arm64/kernel/cpufeature.c | 7 +++----
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 4 ++++
> 4 files changed, 13 insertions(+), 4 deletions(-)
This patch looks good, for what it does. However for bisection safety
it should be earlier, before the patches that change the page table
algorithms to be unsafe for the SMMU.
However, I've heard people talking about shipping chips that have CPUs
with BBML2 but SMMUs without.
On such a system it seems like your series would break previously
working SVA support because this patch will end up disabling it?
Though I see your MIDR_REV list is limited, so perhaps that worry
doesn't effect any real chips made with those families? I am trying to
check some NVIDIA products against this list..
Jason
Powered by blists - more mailing lists