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

Lu Baolu
2021-05-10T02:56:37Z

On 5/8/21 3:31 PM, Tian, Kevin wrote:
>> From: Alex Williamson<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> 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