On Tue, Apr 29, 2025 at 12:40:07PM +0000, Pranjal Shrivastava wrote:
On Fri, Apr 25, 2025 at 10:58:06PM -0700, Nicolin Chen wrote:
/* Caller should xa_lock(&viommu->vdevs) to protect the return value */ struct device *iommufd_viommu_find_dev(struct iommufd_viommu *viommu, unsigned long vdev_id)
If I'm getting this right, I think we are setting up dependencies like: vcmdq[2] -> vcmdq[1] -> vcmdq[0] based on refcounts of each object, which ensures that the unmaps happen in descending order..
Yes.
If that's right, Is it fair to have iommufd_vcmdq_depend/undepend in the core code itself? Since it's a driver-level limitation, I think we should just have iommufd_object_depend/undepend in the core code and the iommufd_vcmdq_depend/undepend can move into the CMDQV driver?
The moment we added iommufd_object_depend/undepend, we already had a blur boundary here since we had no choice to handle in the driver but to ask core for help.
The iommufd_vcmdq_depend/undepend is just a pair of macros to help validating the structure inputs that are core defined. It is quite fair to put next to the raw functions. I also had the notes on top of the raw functions suggesting callers to use the macros instead.
Thanks Nicolin