Re: [PATCH v3 5/5] intel_iommu: Optimize out some unnecessary UNMAP calls

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Jun 08, 2023 at 10:05:08AM -0400, Peter Xu wrote:

> IIUC what VFIO does here is it returns succeed if unmap over nothing rather
> than failing like iommufd.  Curious (like JasonW) on why that retval?  I'd
> assume for returning "how much unmapped" we can at least still return 0 for
> nothing.

In iommufd maps are objects, you can only map or unmap entire
objects. The ability to batch unmap objects by specifying an range
that spans many is something that was easy to do and that VFIO had,
but I'm not sure it is actually usefull..

So asking to unmap an object that is already known not to be mapped is
actually possibly racy, especially if you consider iommufd's support
for kernel-side IOVA allocation. It should not be done, or if it is
done, with user space locking to protect it.

For VFIO, long long ago, VFIO could unmap IOVA page at a time - ie it
wasn't objects. In this world it made some sense that the unmap would
'succeed' as the end result was unmapped.

> Are you probably suggesting that we can probably handle that in QEMU side
> on -ENOENT here for iommufd only (a question to Yi?).

Yes, this can be done, ENOENT is reliably returned and qemu doesn't
use the kernel-side IOVA allocator.

But if there is the proper locks to prevent a map/unmap race, then
there should also be the proper locks to check that there is no map in
the first place and avoid the kernel call..

Jason