[PATCH v4 11/23] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl

[Jason Gunthorpe]

On Thu, May 15, 2025 at 11:16:45AM -0700, Nicolin Chen wrote:
> > As I understand AMD's system the iommu HW itself translates the
> > base_addr through the S2 page table automatically, so it doesn't need
> > pinned memory and physical addresses but just the IOVA.
> 
> Right. That's why we invented a flag, and it should be probably
> extended to cover the pin step as well.

Yes, no pin
 
> > Perhaps for this reason the pinning should be done with a function
> > call from the driver?
> 
> But the whole point of doing in the core was to avoid the entire
> iopt related structure/function from being exposed to the driver,
> which would otherwise hugely increase the size of the driver.o?

Ugh, yes, but also, maybe we need to figure something else out for
this. Pass down a function pointers struct to the driver or something
like that?

> > I don't think this actually works like this without an unmap
> > callback. unmap will break:
> > 
> > 			iommufd_access_notify_unmap(iopt, area_first, length);
> > 			/* Something is not responding to unmap requests. */
> > 			tries++;
> > 			if (WARN_ON(tries > 100))
> > 				return -EDEADLOCK;
> > 
> > If it can't shoot down the pinning.
> 
> Hmm, I thought we want the unmap to fail until VMM releases the HW
> QUEUE first? In what case, does VMM wants to unmap while holding
> the queue pages?

Well, if that is what we want to do then this needs to be revised
somehow..

> > This is more reason to put the pin/access in the driver so it can
> > provide an unmap callback that can fix it up.
> 
> As there are two types of "access" here.. you mean iommufd_access,
> i.e. vcmdq driver should hold an iommufd_access like an emulated
> vfio device driver?

Yes.

Jason