Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

[Lu Baolu]

On 5/8/21 3:31 PM, Tian, Kevin wrote:
> > From: Alex Williamson<alex.williamson@xxxxxxxxxx>
> > 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