Messages in this thread | | | Date | Tue, 27 Apr 2021 13:39:54 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs |
| |
On Tue, Apr 27, 2021 at 03:11:25PM +1000, David Gibson wrote:
> > So your proposal sort of moves the entire container/group/domain > > managment into /dev/ioasid and then leaves vfio only provide device > > specific uAPI. An ioasid represents a page table (address space), thus > > is equivalent to the scope of VFIO container. > > Right. I don't really know how /dev/iosasid is supposed to work, and > so far I don't see how it conceptually differs from a container. What > is it adding?
There are three motivating topics: 1) /dev/vfio/vfio is only usable by VFIO and we have many interesting use cases now where we need the same thing usable outside VFIO 2) /dev/vfio/vfio does not support modern stuff like PASID and updating to support that is going to be a big change, like adding multiple IOASIDs so they can be modeled as as a tree inside a single FD 3) I understand there is some desire to revise the uAPI here a bit, ie Alex mentioned the poor mapping performance.
I would say it is not conceptually different from what VFIO calls a container, it is just a different uAPI with the goal to be cross subsystem.
Jason
| |