[PATCH v4 08/12] iommu/arm-smmu-v3: Support IOMMU_VIOMMU_ALLOC
Shameerali Kolothum Thodi
shameerali.kolothum.thodi at huawei.com
Fri Nov 29 06:38:10 PST 2024
Hi Jason,
> -----Original Message-----
> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Thursday, October 31, 2024 12:21 AM
> To: acpica-devel at lists.linux.dev; iommu at lists.linux.dev; Joerg Roedel
> <joro at 8bytes.org>; Kevin Tian <kevin.tian at intel.com>;
> kvm at vger.kernel.org; Len Brown <lenb at kernel.org>; linux-
> acpi at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Lorenzo
> Pieralisi <lpieralisi at kernel.org>; Rafael J. Wysocki <rafael at kernel.org>;
> Robert Moore <robert.moore at intel.com>; Robin Murphy
> <robin.murphy at arm.com>; Sudeep Holla <sudeep.holla at arm.com>; Will
> Deacon <will at kernel.org>
> Cc: Alex Williamson <alex.williamson at redhat.com>; Donald Dutile
> <ddutile at redhat.com>; Eric Auger <eric.auger at redhat.com>; Guohanjun
> (Hanjun Guo) <guohanjun at huawei.com>; Jean-Philippe Brucker <jean-
> philippe at linaro.org>; Jerry Snitselaar <jsnitsel at redhat.com>; Moritz
> Fischer <mdf at kernel.org>; Michael Shavit <mshavit at google.com>; Nicolin
> Chen <nicolinc at nvidia.com>; patches at lists.linux.dev; Rafael J. Wysocki
> <rafael.j.wysocki at intel.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi at huawei.com>; Mostafa Saleh
> <smostafa at google.com>
> Subject: [PATCH v4 08/12] iommu/arm-smmu-v3: Support
> IOMMU_VIOMMU_ALLOC
[...]
> +struct iommufd_viommu *arm_vsmmu_alloc(struct device *dev,
> + struct iommu_domain *parent,
> + struct iommufd_ctx *ictx,
> + unsigned int viommu_type)
> +{
> + struct arm_smmu_device *smmu =
> + iommu_get_iommu_dev(dev, struct arm_smmu_device,
> iommu);
> + struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> + struct arm_smmu_domain *s2_parent = to_smmu_domain(parent);
> + struct arm_vsmmu *vsmmu;
> +
> + if (viommu_type != IOMMU_VIOMMU_TYPE_ARM_SMMUV3)
> + return ERR_PTR(-EOPNOTSUPP);
> +
> + if (!(smmu->features & ARM_SMMU_FEAT_NESTING))
> + return ERR_PTR(-EOPNOTSUPP);
> +
> + if (s2_parent->smmu != master->smmu)
> + return ERR_PTR(-EINVAL);
> +
> + /*
> + * Must support some way to prevent the VM from bypassing the
> cache
> + * because VFIO currently does not do any cache maintenance.
> canwbs
> + * indicates the device is fully coherent and no cache maintenance
> is
> + * ever required, even for PCI No-Snoop."
> + */
> + if (!arm_smmu_master_canwbs(master))
> + return ERR_PTR(-EOPNOTSUPP);
> +
> + vsmmu = iommufd_viommu_alloc(ictx, struct arm_vsmmu, core,
> + &arm_vsmmu_ops);
> + if (IS_ERR(vsmmu))
> + return ERR_CAST(vsmmu);
> +
> + vsmmu->smmu = smmu;
> + vsmmu->s2_parent = s2_parent;
> + /* FIXME Move VMID allocation from the S2 domain allocation to
> here */
I am planning to respin the " iommu/arm-smmu-v3: Use pinned KVM VMID for
stage 2" [0] based on the latest IOMMUF code. One of the comment on that
RFC was, we should associate the KVM pointer to the sub objects like viommu
instead of iommufd itself[1]. But at present the s2 domain is already finalized
with a VMID before a viommu object is allocated.
So does the above comment indicates that we plan to do another
S2 VMID allocation here and replace the old one?
Please let me know your thoughts on this.
Thanks,
Shameer
[0] https://lore.kernel.org/linux-iommu/20240208151837.35068-1-shameerali.kolothum.thodi@huawei.com/
[1] https://lore.kernel.org/linux-iommu/BN9PR11MB527662A2AB0A9BABD5E20E6D8CD52@BN9PR11MB5276.namprd11.prod.outlook.com/
More information about the linux-arm-kernel
mailing list