Re: [PATCH v9 11/25] iommu/arm-smmu-v3-kvm: Add the kernel driver

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Nov 10, 2026 at 10:41:27AM +0000, Mostafa Saleh wrote:
> On Mon, Nov 09, 2026 at 04:16:53PM -0800, Nicolin Chen wrote:
> > On Mon, Nov 09, 2026 at 10:47:46AM +0000, Mostafa Saleh wrote:
> > > On Thu, Nov 05, 2026 at 01:06:18PM -0800, Nicolin Chen wrote:
> > > > On Thu, Oct 15, 2026 at 08:08:42PM +0000, Mostafa Saleh wrote:
> > > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > > > > +#ifdef CONFIG_ARM_SMMU_V3_PKVM
> > > > > +/*
> > > > > + * Two devices are involved: the aux device bound to this driver, and the
> > > > > + * physical platform device bound to the pKVM init driver, which only uses it
> > > > > + * for discovery. This driver keeps using the platform device, as it carries
> > > > > + * the fwnode the IOMMU core and consumers link to, the DMA configuration and
> > > > > + * the IRQs.
> > > > 
> > > > It would be nicer to have a diagram or so to show the co-relationship
> > > > among different devices and drivers.
> > > > 
> > > > I assume the regular arm-smmu-v3 driver is a part of the picture too,
> > > > when the pkvm driver binding fails?
> > > > 
> > > 
> > > I can add some ASCII diagram.
> > > If pKVM driver fails, no aux devices are created and the main driver
> > > probes the platform SMMUv3 devices as usual.
> > 
> > I didn't check closely, but would it be safe to do so?
> > 
> > Is pkvm aware of the missing SMMU device and handling it properly?
> > 
> > When pkvm is enabled and the SMMU device is supposed to be a pkvm
> > device, should it not fall back to the main driver?
> 
> If pKVM fails to init for any reason (unsupported layout or non-coherent
> HW) the SMMU will be bound to the main driver so the system remains
> functional.
> 
> However, pKVM will not be safe in that case regarding DMA isolation
> as the status quo.
> In Android, in that case, pKVM clears the FW (called pvmfw) that loads
> the protected VM and authenticate it so any protected VM knows the
> system is not trusted. This part is not upstream yet. [1]

You might want to double check a dual-SMMU case, where one gets
accepted by pkvm driver and the other fails and so bound to the
main driver.

It seems the pkvm driver would still pkvm_iommu_register_driver
and carry on with an untrusted SMMU. Would it also clear the FW
and mark the system as not trusted?

Nicolin