> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Friday, March 25, 2022 7:12 AM > > On Thu, Mar 24, 2022 at 04:04:03PM -0600, Alex Williamson wrote: > > That's essentially what I'm trying to reconcile, we're racing both > > to round out the compatibility interface to fully support QEMU, while > > also updating QEMU to use iommufd directly so it won't need that full > > support. It's a confusing message. Thanks, > > The long term purpose of compatibility is to provide a config option > to allow type 1 to be turned off and continue to support old user > space (eg in containers) that is running old qemu/dpdk/spdk/etc. > > This shows that we have a plan/path to allow a distro to support only > one iommu interface in their kernel should they choose without having > to sacrifice uABI compatibility. > > As for racing, my intention is to leave the compat interface alone for > awhile - the more urgent things in on my personal list are the RFC > for dirty tracking, mlx5 support for dirty tracking, and VFIO preparation > for iommufd support. > > Eric and Yi are focusing on userspace page tables and qemu updates. > > Joao is working on implementing iommu driver dirty tracking > > Lu and Jacob are working on getting PASID support infrastructure > together. > > There is alot going on! > > A question to consider is what would you consider the minimum bar for > merging? > My two cents. 😊 IMHO making the compat work as a task in parallel with other works listed above is the most efficient approach to move forward. In concept they are not mutual-dependent by using different set of uAPIs (vfio compat vs. iommufd native). Otherwise considering the list of TODOs the compat work will become a single big task gating all other works. If agreed this suggests we may want to prioritize Yi's vfio device uAPI [1] to integrate vfio with iommufd to get this series merged. iirc there are less opens remaining from v1 discussion compared to the list in the compat interface. Of course it needs the Qemu change ready to use iommufd directly, but this is necessary to unblock other tasks anyway. [1] https://github.com/luxis1999/iommufd/commit/2d9278d4ecad7953b3787c98cdb650764af8a1a1 Thanks Kevin
