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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:

> Nicolin Chen <nicolinc@nvidia.com> writes:
>
>> On Mon, Apr 27, 2026 at 02:23:31PM +0530, Aneesh Kumar K.V (Arm) wrote:

...

>> .. and we demand userspace (VMM) to use IOMMU_VIOMMU_ALLOC ioctl,
>> even if VMM does not actually expose a guest-level SMMU instance.
>> Thus, no user_data.
>>
>> I can get the reasoning behind the flow using this viommu/vdevice.
>>
>> But, on the other hand, I can imagine that a Realm VSMMU would add
>> a new flag with a user_data to this VIOMMU. Then, this flow would
>> give some troubles to VMM (QEMU for example):
>>
>>  - For VM with a guest-level SMMU, QEMU creates a realm instance
>>    where IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 (with vsmmu) can be
>>    allocated.
>>  - For VM w/o a guest-level SMMU, QEMU won't create such a realm
>>    instance, while still required to invoke the ioctl (w/o vsmmu). 
>>
>> Taking a step back, I wonder if we really need to use iommufd for
>> PSMMU activation and its stream table allocations?
>>
>> Here are some facts:
>>   - An iommufd has a ctx, that's one per VM. Similarly, a Realm
>>     has an RD.
>>   - For an RMI command that needs an RD, it makes sense to be per
>>     iommufd ctx, e.g. RMI_VSMMU_* or RMI_VDEV_* commands.
>>   - PSMMU commands are global; they don't need RD. So they don't
>>     seem necessary to tie to an iommufd ctx.
>>
>> Instead, could the PSMMU activation be done after RMI_PSMMU_INFO
>> check? Is there any reason not to do that? A safer timing might
>> be at the device assignment stage?
>>
>
> One of the reasons I added IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 was to
> avoid creating a psmmu object when we are not using a PCI passthrough
> VM. That is also the reason for all the refcounting around the psmmu
> objects.
>
> If we are okay with creating psmmu objects early, then I guess we can go
> with the above approach.
>

How about?

modified    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
@@ -437,9 +437,6 @@
 	if (viommu_type == IOMMU_VIOMMU_TYPE_ARM_SMMUV3)
 		return VIOMMU_STRUCT_SIZE(struct arm_vsmmu, core);
 
-	if (viommu_type == IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3)
-		return VIOMMU_STRUCT_SIZE(struct arm_vsmmu, core);
-
 	if (!smmu->impl_ops || !smmu->impl_ops->get_viommu_size)
 		return 0;
 	return smmu->impl_ops->get_viommu_size(viommu_type);
@@ -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);
+
 		viommu->ops = &arm_vsmmu_ops;
 		return 0;
 	}
 
-	if (viommu->type == IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3)
-		return arm_realm_smmu_v3_init(viommu, user_data);
-
-
 	return smmu->impl_ops->vsmmu_init(vsmmu, user_data);
 }
 

modified    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-realm.c
@@ -239,21 +239,27 @@
 	return 0;
 }
 
+bool arm_smmu_is_realm_viommu(struct iommufd_viommu *viommu)
+{
+	struct kvm *kvm;
+
+	if (!viommu->kvm_file)
+		return false;
+
+	kvm = viommu->kvm_file->private_data;
+	return kvm_is_realm(kvm);
+}
+
 int arm_realm_smmu_v3_init(struct iommufd_viommu *viommu,
 			   const struct iommu_user_data *user_data)
 {
 	int ret = 0;
-	struct kvm *kvm;
 	struct rmi_psmmu_params *params;
 	struct arm_smmu_device *smmu =
 		container_of(viommu->iommu_dev, struct arm_smmu_device, iommu);
 	unsigned long rmi_ret;
 
-	if (!viommu->kvm_file)
-		return -EINVAL;
-
-	kvm = viommu->kvm_file->private_data;
-	if (!kvm_is_realm(kvm))
+	if (!arm_smmu_is_realm_viommu(viommu))
 		return -EINVAL;
 
 	if (!(smmu->features & ARM_SMMU_FEAT_RME))

modified    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4515,8 +4515,6 @@
 	int ret;
 
 	mutex_init(&smmu->streams_mutex);
-	mutex_init(&smmu->realm.mutex);
-	refcount_set(&smmu->realm.users, 0);
 	smmu->streams = RB_ROOT;
 
 	ret = arm_smmu_init_queues(smmu);
@@ -5578,6 +5576,8 @@
 		return -ENODEV;
 	}
 
+	mutex_init(&smmu->realm.mutex);
+	refcount_set(&smmu->realm.users, 0);
 	smmu->features |= ARM_SMMU_FEAT_RME_IRQ;
 	return 0;
 

modified    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -1282,6 +1282,7 @@
 			      const struct iommu_user_data *user_data);
 int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
 			       struct iommu_user_data_array *array);
+bool arm_smmu_is_realm_viommu(struct iommufd_viommu *viommu);
 int arm_realm_smmu_v3_init(struct iommufd_viommu *viommu,
 			   const struct iommu_user_data *user_data);
 #else

modified    include/uapi/linux/iommufd.h
@@ -1068,7 +1068,6 @@
 	 *   VMM must wire the HYP_OWN bit to 0 in guest VINTF_CONFIG register
 	 */
 	IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV = 2,
-	IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 = 3,
 };
 
 /**