Messages in this thread |  | | Subject | Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs | From | Lu Baolu <> | Date | Mon, 10 May 2021 10:56:37 +0800 |
| |
On 5/8/21 3:31 PM, Tian, Kevin wrote: >> From: Alex Williamson<alex.williamson@redhat.com> >> Sent: Saturday, May 8, 2021 1:06 AM >> >>>> Those are the main ones I can think of. It is nice to have a simple >>>> map/unmap interface, I'd hope that a new /dev/ioasid interface wouldn't >>>> raise the barrier to entry too high, but the user needs to have the >>>> ability to have more control of their mappings and locked page >>>> accounting should probably be offloaded somewhere. Thanks, >>>> >>> Based on your feedbacks I feel it's probably reasonable to start with >>> a type1v2 semantics for the new interface. Locked accounting could >>> also start with the same VFIO restriction and then improve it >>> incrementally, if a cleaner way is intrusive (if not affecting uAPI). >>> But I didn't get the suggestion on "more control of their mappings". >>> Can you elaborate? >> Things like I note above, userspace cannot currently specify mapping >> granularity nor has any visibility to the granularity they get from the >> IOMMU. What actually happens in the IOMMU is pretty opaque to the user >> currently. Thanks, >> > It's much clearer. Based on all the discussions so far I'm thinking about > a staging approach when building the new interface, basically following > the model that Jason pointed out - generic stuff first, then platform > specific extension: > > Phase 1: /dev/ioasid with core ingredients and vfio type1v2 semantics > - ioasid is the software handle representing an I/O page table
A trivial proposal, is it possible to use /dev/ioas? Conceptually, it's an IO address space representation and has nothing to do with any ID.
Best regards, baolu
|  |