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