On Thu, May 15, 2025 at 02:19:02PM -0300, Jason Gunthorpe wrote:
On Thu, May 08, 2025 at 08:02:38PM -0700, Nicolin Chen wrote:
An impl driver might want to allocate its own type of vIOMMU object or the standard IOMMU_VIOMMU_TYPE_ARM_SMMUV3 by setting up its own SW/HW bits, as the tegra241-cmdqv driver will add IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV.
Add a vsmmu_alloc op and prioritize it in arm_vsmmu_alloc().
Reviewed-by: Pranjal Shrivastava praan@google.com Signed-off-by: Nicolin Chen nicolinc@nvidia.com
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++++++ .../iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 17 +++++++++++------ 2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 6b8f0d20dac3..a5835af72417 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -16,6 +16,7 @@ #include <linux/sizes.h> struct arm_smmu_device; +struct arm_smmu_domain; /* MMIO registers */ #define ARM_SMMU_IDR0 0x0 @@ -720,6 +721,11 @@ struct arm_smmu_impl_ops { int (*init_structures)(struct arm_smmu_device *smmu); struct arm_smmu_cmdq *(*get_secondary_cmdq)( struct arm_smmu_device *smmu, struct arm_smmu_cmdq_ent *ent);
- struct arm_vsmmu *(*vsmmu_alloc)(
struct arm_smmu_device *smmu,struct arm_smmu_domain *smmu_domain, struct iommufd_ctx *ictx,unsigned int viommu_type,const struct iommu_user_data *user_data);};
I think you should put the supported viommu type here in the ops struct and match it here:
OK. A single type per impl might be enough for now, so it can be a static one.
- /* Prioritize the impl that may support IOMMU_VIOMMU_TYPE_ARM_SMMUV3 */
- if (master->smmu->impl_ops && master->smmu->impl_ops->vsmmu_alloc)
vsmmu = master->smmu->impl_ops->vsmmu_alloc(master->smmu, s2_parent, ictx, viommu_type, user_data);instead of the EOPNOTSUPP dance. Either the impl_ops supports the requested viommu as an extension or we are running in the normal mode?
I think we can only do normal mode if requested viommu is the normal SMMUV3 type, i.e. still need to reject a type other than !CMDQV nor !SMMUV3, right?
Is there a reason to allocate a different viommu if the userspace does not enable the implementation specific features?
Hmm, what is this different viommu?
If VMM doesn't want VCMDQ, it should go with the normal SMMUV3 type.
Thanks Nicolin