summaryrefslogtreecommitdiff
path: root/rust/helpers/xarray.c
diff options
context:
space:
mode:
authorNicolin Chen <nicolinc@nvidia.com>2025-07-09 22:59:03 -0700
committerJason Gunthorpe <jgg@nvidia.com>2025-07-11 11:09:22 -0300
commit27b77ea5feaa8fcf385ea99ce757982b0ac9d1f0 (patch)
treed5509c0f50ab8d67bc9208e80f21031a33e2a132 /rust/helpers/xarray.c
parent1c26c3bbdee11f3fad0c74b8f09aef488dcf4b62 (diff)
iommufd/access: Bypass access->ops->unmap for internal use
The access object has been used externally by VFIO mdev devices, allowing them to pin/unpin physical pages (via needs_pin_pages). Meanwhile, a racy unmap can occur in this case, so these devices usually implement an unmap handler, invoked by iommufd_access_notify_unmap(). The new HW queue object will need the same pin/unpin feature, although it (unlike the mdev case) wants to reject any unmap attempt, during its life cycle. Instead, it would not implement an unmap handler. Thus, bypass any access->ops->unmap access call when the access is marked as internal. Also, an area being pinned by an internal access should reject any unmap request. This cannot be done inside iommufd_access_notify_unmap() as it's a per-iopt action. Add a "num_locks" counter in the struct iopt_area, set that in iopt_area_add_access() when the caller is an internal access. Link: https://patch.msgid.link/r/6df9a43febf79c0379091ec59747276ce9d2493b.1752126748.git.nicolinc@nvidia.com Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Diffstat (limited to 'rust/helpers/xarray.c')
0 files changed, 0 insertions, 0 deletions