On Thu, May 15, 2025 at 03:59:38PM -0300, Jason Gunthorpe wrote:
On Thu, May 15, 2025 at 11:16:45AM -0700, Nicolin Chen wrote:
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..
Yea, unless we have a strong reason to allow unmap while holding the HW queue.
I think we could set a new flag:
enum { IOMMUFD_ACCESS_RW_READ = 0, IOMMUFD_ACCESS_RW_WRITE = 1 << 0, /* Set if the caller is in a kthread then rw will use kthread_use_mm() */ IOMMUFD_ACCESS_RW_KTHREAD = 1 << 1, + IOMMUFD_ACCESS_NO_UNMAP = 1 << 3,
/* Only for use by selftest */ __IOMMUFD_ACCESS_RW_SLOW_PATH = 1 << 2, };
and reject iopt_unmap_iova_range().
Thanks Nicolin