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

[Nicolin Chen]

On Tue, Sep 01, 2026 at 11:34:45AM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 01, 2026 at 03:36:37PM +0530, Aneesh Kumar K.V wrote:
> 
> > @@ -463,14 +460,13 @@
> >  	vsmmu->vmid = s2_parent->s2_cfg.vmid;
> >  
> >  	if (viommu->type == IOMMU_VIOMMU_TYPE_ARM_SMMUV3) {
> > +		if (arm_smmu_is_realm_viommu(viommu))
> > +			return arm_realm_smmu_v3_init(viommu, user_data);
> > +
> 
> I think the realm vsmmu is going to require a different info struct
> than the normal psmmu case, isn't it?
> 
> If so it needs its own enum value.
> 
> It would be nice to see a draft patch showing how the real vsmmu works
> on top of the RMM spec for it. If we are using a viommu object then
> non-vsmmu case should be identical just with an option in the info
> struct to not create the vsmmu object.

Actually, the PSMMU-only viommu object in this series only adds a
type with no viommu data structure.

I've drafted the vsmmu case on top of the series, so it would add
a structure reusing the same IOMMU_VIOMMU_TYPE_ARM_SMMUV3 with a
flag:

+/**
+ * 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];
+};

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. 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.

Nicolin