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
