[RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing

[Nicolin Chen]

On Tue, Sep 01, 2026 at 02:42:30PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 01, 2026 at 10:13:04AM -0700, Nicolin Chen wrote:
> 
> > +/**
> > + * enum iommu_viommu_arm_realm_vsmmuv3_flags - Flags for ARM SMMUv3 Realm
> > + * @IOMMU_VIOMMU_ARM_REALM_SMMUV3_FLAGS_VSMMU: Indicates whether the Realm has
> > + *                                             a guest-visible VSMMU instance
> > + */
> > +enum iommu_viommu_arm_realm_vsmmuv3_flags {
> > +	IOMMU_VIOMMU_ARM_REALM_SMMUV3_FLAGS_VSMMU = 1 << 0,
> > +};
> > +
> > +/**
> > + * struct iommu_viommu_arm_realm_vsmmuv3 - ARM Realm VSMMUv3 parameters
> > + *                                         (IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3)
> > + * @flags: Combination of enum iommu_viommu_arm_realm_vsmmuv3_flags
> > + * @reg_base: MMIO base address of the VSMMU in the guest VM
> > + * @reg_top: MMIO top address of the VSMMU in the guest VM
> > + * @aidr: AIDR register value of the VSMMU in the guest VM
> > + * @idr: IDR register values of the VSMMU in the guest VM
> > + */
> > +struct iommu_viommu_arm_realm_vsmmuv3 {
> > +	__aligned_u64 flags;
> > +	__aligned_le64 reg_base;
> > +	__aligned_le64 reg_top;
> > +	__aligned_le64 aidr;
> > +	__aligned_le64 idr[7];
> > +};
> 
> Yeah, broadly what I would expect. Pass everything needed to execute
> RMI_VSMMU_CREATE through this struct.
> 
> Is there anything more than RMI_VSMMU_CREATE needed from a RMM
> perspective? What about that dpt/ats stuff?

DPT is a bit hacky currently..

Prior to RMM v2.0 ABI, DPT was allocated statically in RMM; there
was no RMI command for DPT allocations.

Now, with RMM v2.0 ABI, DPT can be managed via RMIs. I am making
it follow GPT at this point, similar to the static idea. But, in
the long run, I will think of decoupling, but I haven't looked at
that closely.
 
> > I think this should work. But I still feel awkward that a non-vsmmu
> > case has to allocate a viommu object for a set of RMI commands that
> > don't need an Realm Descriptor.
> 
> It is for the RMI_VDEV_CREATE which needs the RD:
> 
> 	case IOMMU_VDEVICE_TSM_BIND:
> 		rc = tsm_bind(vdev->idev->dev, kvm, vdev->virt_id);
> 		break;
> 
> It has to be tied to a vdevice on a viommu to pick up the kvm and
> vSID.
> 
> If we don't do that we need a new way to get the virt_id and kvm into
> the flow, which doesn't really seem worthwhile to me.

Okay. I see the gap now...

For tsm_bind: idev has dev, idev has kvm, but idev has no vBDF.

Maybe we could allow vdevice to have no viommu? In which way, VMM
can forward vBDF independently. If VMM has a vsmmu instance, then
it can allocate vdevice in the traditional way.

The viommu object here is an empty vehicle that almost has no use
but to allow another vehicle (vdevice) on top to forward vBDF. It
makes VMM code a bit awkward: there is no iommu instance, so VMM
doesn't enable iommu driver, then there is no good place to alloc
the viomu object for VIOMMU_TYPE_ARM_REALM_SMMUV3.

> > Things could be cleaner if we allow RMI_PSMMU_ACTIVATE and
> > RMI_PSMMU_ST_L2_CREATE to be independent on a viommu; then leave
> > IOMMU_VIOMMU_TYPE_ARM_SMMUV3 to vsmmu-visiable case.
> 
> This is why I asked in the other message if RMM spec is clear that
> PSMMU and STE are not required for anything but VDEV_CREATE. If so,
> the PDEV create and SPDM stuff is fuly independent.

I think the spec is clear. And you are right PDEV is independent,
only linked to PSMMU when VDEV is created.

> Which is why I'm saying the split doesn't make sense. PSMMU,
> interrupts, STE, VDEV are all related objects that should be managed
> together by the SMMUv3 driver. You need a PDEV to create a STE, and
> you need a STE to create a VDEV.
> 
> PDEV is the SPDM channel and should be managed by the TSM driver.
>
> So, I think the IOMMU_VDEVICE_TSM_BIND is not justified. "BIND" should
> happen when the SMMUv3 realm viommu ops create the vdevice. The same
> way the vcmdq sets up the VSID tables when the vdevice is created. Is
> there a reason to have it in its own command?
> 
> Further the implementation of IOMMU_VDEVICE_TSM_BIND in this series
> *requires* a viommu to work. So OK, let's lean into that. (to be clear
> I am saying delete tsm_bind)

Yea, IOMMU_VDEVICE_TSM_BIND feels redundant..

Thanks
Nicolin