Messages in this thread | | | From | "Liu, Yi L" <> | Subject | RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs | Date | Wed, 21 Apr 2021 13:18:07 +0000 |
| |
Hi Alex,
> From: Alex Williamson <alex.williamson@redhat.com> > Sent: Friday, April 16, 2021 11:46 PM [...] > > This is not a tactic or excuse for not working on the new /dev/ioasid > > interface. In fact, I believe we can benefit from the lessons learned > > while completing the existing. This will give confidence to the new > > interface. Thoughts? > > I understand a big part of Jason's argument is that we shouldn't be in > the habit of creating duplicate interfaces, we should create one, well > designed interfaces to share among multiple subsystems. As new users > have emerged, our solution needs to change to a common one rather than > a VFIO specific one. The IOMMU uAPI provides an abstraction, but at > the wrong level, requiring userspace interfaces for each subsystem. > > Luckily the IOMMU uAPI is not really exposed as an actual uAPI, but > that changes if we proceed to enable the interfaces to tunnel it > through VFIO. > > The logical answer would therefore be that we don't make that > commitment to the IOMMU uAPI if we believe now that it's fundamentally > flawed. > > Ideally this new /dev/ioasid interface, and making use of it as a VFIO > IOMMU backend, should replace type1.
yeah, just a double check, I think this also requires a new set of uAPIs (e.g. new MAP/UNMAP), which means the current VFIO IOMMU type1 related ioctls would be deprecated in future. right?
> Type1 will live on until that > interface gets to parity, at which point we may deprecate type1, but it > wouldn't make sense to continue to expand type1 in the same direction > as we intend /dev/ioasid to take over in the meantime, especially if it > means maintaining an otherwise dead uAPI. Thanks,
understood.
Regards, Yi Liu
| |