On Fri, Feb 24, 2023 at 06:50:43AM +0000, Tian, Kevin wrote:
From: Jason Gunthorpe jgg@nvidia.com Sent: Thursday, February 23, 2023 5:03 AM
iommufd wants to use more infrastructure, like the iommu_group, that the mock device does not support. Create a more complete mock device that can go through the whole cycle of ownership, blocking domain, and has an iommu_group.
this is a nice move! Presumable with a real struct device we can further extend the mock device to test nested, pasid attach/alloc, etc. in the future.
Yes, it should all work better
- /*
* The iommu core has no way to associate a single device with aniommu
* driver (heck currently it can't even support two iommu_drivers* registering). Hack it together with an open coded dev_iommu_get().* Notice that the normal notifier triggered iommu release processalso
* does not work here because this bus is not in iommu_buses.*/- mdev->dev.iommu = kzalloc(sizeof(*dev_iommu), GFP_KERNEL);
- if (!mdev->dev.iommu) {
rc = -ENOMEM;goto err_group;- }
- mutex_init(&mdev->dev.iommu->lock);
- mdev->dev.iommu->iommu_dev = &mock_iommu_device;
I understand how this hack works but didn't get why in this case dev_iommu_get() cannot be reused...
I'd have to make it an exported symbol.. It could be done, maybe it should be done. I'm unclear how much intrustion we should create for the selftests.
The other thought I had is that perhaps we could fix the bus binding so that it wasn't a hard coded list in the iommu.c Eg a flag in the bus_type or provide the list when binding the driver or something. Then things would work perfectly. Needs Robin's series first though as it allows multiple iommu drivers.
So.. I kind of left it like this hoping that other parts would advance more and we can revisit it later, it is only 4 lines.
Jason