On Thu, May 15, 2025 at 01:32:48PM -0700, Nicolin Chen wrote:
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().
Okay, it would need a patch for this too. I think we wanted to limit this no_unmap behavior though. Linking it to deliberate action that the user took to create a vqueue with a user provided address seems reasonable
I would probably put the flag out of the public header though, just to prevent abuse from mdev drivers.
Jason