On Fri, Feb 24, 2023 at 06:50:43AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > 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 an
> > iommu
> > + * 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 process
> > also
> > + * 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
