Re: [PATCH v7 2/3] iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround infrastructure

[Nicolin Chen <nicolinc@nvidia.com>]

On Fri, Jul 17, 2026 at 05:18:41PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 14, 2026 at 10:42:01AM +0000, Ashish Mhetre wrote:
> Because the VM has access to VCMDQ/etc it can issue commands directly
> (maybe not on this chip, but as a general comment), thus invalidation
> errata need to be made visible to the VM and we need to expect the VM
> will generate invalidations to properly deal with any errata.
> 
> Ie I'd expect the VM to see a "nvidia,tegra264-smmu" compatible string
> to activate the errata fix.
> 
> If so then we will already get duplicated invalidations here and then
> we will duplicate them again. That's not great.

Oh, that's a good point.

> On the other hand if you want to emulate a generic and actually
> functional SMMU device that has nothing like VCMDQ/etc then you must
> do something like this in this patch.

Tegra264 has virtualization use case. And It's built with VCMDQ,
which should be the default case than the generic vSMMU case.

> I was imagining a general direction that we would expose the errata
> information to the guest and the guest would have to deal with it.
> 
> Given this is the opposite I wonder if we want to do it. It does make
> sense for a chip that probably doesn't have vCMDQ and I don't think
> qemu can even create a DT description to trigger the errata anyhow.

I don't have the source code of the VMM used on Tegra264, but I
believe the guest kernel can be the same copy of kernel as the
host. So, its VMM is likely to use the "nvidia,tegra264-smmu" DT
compatible string, to trigger the errata at the guest level.

> But it starts to become confusing down the road if we decide other
> invalidation errata (like the CONT must be RIL thing) must be delt
> with by the guest.
>
> So.. Maybe add a comment why this one is different, or maybe just
> disable FEAT_NESTING if there isn't a use case?

Given the use cases on Tegra264, instead of patching the iommufd
path as this patch does, perhaps we should simply spit a WARN in
arm_vsmmu_init():

	if (static_branch_unlikely(&arm_smmu_erratum_repeat_tlbi_cfgi_key))
		dev_warn(smmu->dev,
			 "guest must WAR the repeat_tlbi_cfgi erratum\n");

?

Thanks
Nicolin