Thread (233 messages) 233 messages, 15 authors, 2021-10-28

RE: [RFC] /dev/ioasid uAPI proposal

From: Parav Pandit <hidden>
Date: 2021-06-01 12:04:05
Also in: linux-iommu, lkml

From: Jason Gunthorpe <jgg@nvidia.com>
Sent: Monday, May 31, 2021 11:43 PM

On Mon, May 31, 2021 at 05:37:35PM +0000, Parav Pandit wrote:
quoted
In that case, can it be a new system call? Why does it have to be under
/dev/ioasid?
quoted
For example few years back such system call mpin() thought was proposed
in [1].

Reference counting of the overall pins are required

So when a pinned pages is incorporated into an IOASID page table in a later
IOCTL it means it cannot be unpinned while the IOASID page table is using it.
Ok. but cant it use the same refcount of that mmu uses?
This is some trick to organize the pinning into groups and then refcount each
group, thus avoiding needing per-page refcounts.
Pinned page refcount is already maintained by the mmu without ioasid, isn't it?
The data structure would be an interval tree of pins in general

The ioasid itself would have an interval tree of its own mappings, each entry
in this tree would reference count against an element in the above tree

Then the ioasid's interval tree would be mapped into a page table tree in HW
format.
Does it mean in simple use case [1], second level page table copy is maintained in the IOMMU side via map interface?
I hope not. It should use the same as what mmu uses, right?

[1] one SIOV/ADI device assigned with one PASID and mapped in guest VM
The redundant storages are needed to keep track of the refencing and the
CPU page table values for later unpinning.

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help