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

From: Jason Gunthorpe <jgg@ziepe.ca>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"maz@kernel.org" <maz@kernel.org>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"will@kernel.org" <will@kernel.org>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: Re: [RFC PATCH v2 0/7] iommu/arm-smmu-v3: Use pinned KVM VMID for stage 2
Date: Thu, 8 Feb 2024 12:07:27 -0400	[thread overview]
Message-ID: <20240208160727.GS31743@ziepe.ca> (raw)
In-Reply-To: <416d8150d3ce4a67901a3ff7a596e4e8@huawei.com>

On Thu, Feb 08, 2024 at 03:49:20PM +0000, Shameerali Kolothum Thodi wrote:
> > 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.
> > 
> > Ah so you are going all the way and looking to enable BTM within a
> > vSVA environment too?
> 
> Yes, eager to get the vSVA support 😊 Its been ages and tired of rebasing for our
> private git for the vSVA cases!.
> 
> Also for Host SVA, since we are using S1 now, I don’t think this matters that much.
> 
> (I do have some questions on the iommufd based vSVA , but I will come back to it,
> once I cleanup my Qemu branch for that.)

Oh, I think I left a comment someplace that you also need to signal to the
VMM that the kernel supports vBTM, probably via new flag in the
iommu_hw_info_arm_smmuv3

+ *
+ * Note that these values reflect the raw HW capability, without any insight if
+ * any required kernel driver support is present. Bits may be set indicating the
+ * HW has functionality that is lacking kernel software support, such as BTM. If
+ * a VMM is using this information to construct emulated copies of these
+ * registers it should only forward bits that it knows it can support.
+ *
+ * In future, presence of required kernel support will be indicated in flags.
+ */

> > If someone is using it I wonder if we need to get a more solid answer
> > on the races with invalidation an ASID reassign.. I added some notes
> > in comments in part 2 after I audited all of it.
> 
> I saw that one. The main point here is, if we guarantee that BTM is only used
> for a nested S2 case and there will be a pinned KVM VMID for that, I am 
> not sure we need to worry about any S2 related conflicts in TLBIs.

Sure for the S2, aside my other note, but my remark here was about the
S1 ASID reassign logic. I was sort of OK to leave it as it was under
the idea that BTM support wasn't turned on.

I'm concerned it is another iommufd triggerable security problem..

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel