[RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2

Shameerali Kolothum Thodi shameerali.kolothum.thodi at huawei.com
Fri Feb 9 05:54:08 PST 2024



> -----Original Message-----
> From: Jean-Philippe Brucker <jean-philippe at linaro.org>
> Sent: Friday, February 9, 2024 11:58 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
> Cc: kvmarm at lists.linux.dev; iommu at lists.linux.dev; linux-arm-
> kernel at lists.infradead.org; Linuxarm <linuxarm at huawei.com>;
> kevin.tian at intel.com; jgg at ziepe.ca; alex.williamson at redhat.com;
> maz at kernel.org; oliver.upton at linux.dev; will at kernel.org;
> robin.murphy at arm.com; Jonathan Cameron
> <jonathan.cameron at huawei.com>
> Subject: Re: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM
> VMID for stage 2
> 
> Hi Shameer,
> 
> On Thu, Feb 08, 2024 at 03:18:30PM +0000, Shameer Kolothum wrote:
> > Hi,
> >
> > On an ARM64 system with a SMMUv3 implementation that fully supports
> > Broadcast TLB Maintenance(BTM) feature as part of the Distributed
> > Virtual Memory(DVM) protocol, the CPU TLB invalidate instructions are
> > received by SMMUv3. This is very useful when the SMMUv3 shares the
> > page tables with the CPU(eg: Guest SVA use case). For this to work,
> > the SMMUv3 must use the same VMID that is allocated by KVM to
> configure
> > the nested stage 2(S2) translations.
> 
> The series makes sense to me. Maybe a little more detail to help the KVM
> maintainers understand why we need something like this even though the s2
> page tables aren't shared between CPU and SMMU:

Thanks Jean for the nice write up. I will use this for next revisions of this series.

Shameer



More information about the linux-arm-kernel mailing list