Hi Alex, > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > 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
