> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, September 21, 2022 3:57 AM > > On Tue, Sep 13, 2022 at 09:28:18AM +0200, Eric Auger wrote: > > Hi, > > > > On 9/13/22 03:55, Tian, Kevin wrote: > > > We didn't close the open of how to get this merged in LPC due to the > > > audio issue. Then let's use mails. > > > > > > Overall there are three options on the table: > > > > > > 1) Require vfio-compat to be 100% compatible with vfio-type1 > > > > > > Probably not a good choice given the amount of work to fix the > remaining > > > gaps. And this will block support of new IOMMU features for a longer > time. > > > > > > 2) Leave vfio-compat as what it is in this series > > > > > > Treat it as a vehicle to validate the iommufd logic instead of > immediately > > > replacing vfio-type1. Functionally most vfio applications can work w/o > > > change if putting aside the difference on locked mm accounting, p2p, > etc. > > > > > > Then work on new features and 100% vfio-type1 compat. in parallel. > > > > > > 3) Focus on iommufd native uAPI first > > > > > > Require vfio_device cdev and adoption in Qemu. Only for new vfio app. > > > > > > Then work on new features and vfio-compat in parallel. > > > > > > I'm fine with either 2) or 3). Per a quick chat with Alex he prefers to 3). > > > > I am also inclined to pursue 3) as this was the initial Jason's guidance > > and pre-requisite to integrate new features. In the past we concluded > > vfio-compat would mostly be used for testing purpose. Our QEMU > > integration fully is based on device based API. > > There are some poor chicken and egg problems here. > > I had some assumptions: > a - the vfio cdev model is going to be iommufd only > b - any uAPI we add as we go along should be generally useful going > forward > c - we should try to minimize the 'minimally viable iommufd' series > > The compat as it stands now (eg #2) is threading this needle. Since it > can exist without cdev it means (c) is made smaller, to two series. > > Since we add something useful to some use cases, eg DPDK is deployable > that way, (b) is OK. > > If we focus on a strict path with 3, and avoid adding non-useful code, > then we have to have two more (unwritten!) series beyond where we are > now - vfio group compartmentalization, and cdev integration, and the > initial (c) will increase. We are working on splitting vfio group now. cdev integration was there but needs update based on the former part. Once ready we'll send out in case people want to see the actual material impact for #3. > > 3 also has us merging something that currently has no usable > userspace, which I also do dislike alot. > > I still think the compat gaps are small. I've realized that > VFIO_DMA_UNMAP_FLAG_VADDR has no implementation in qemu, and > since it > can deadlock the kernel I propose we purge it completely. > > P2P is ongoing. > > That really just leaves the accounting, and I'm still not convinced at > this must be a critical thing. Linus's latest remarks reported in lwn > at the maintainer summit on tracepoints/BPF as ABI seem to support > this. Let's see an actual deployed production configuration that would > be impacted, and we won't find that unless we move forward. > > So, I still like 2 because it yields the smallest next step before we > can bring all the parallel work onto the list, and it makes testing > and converting non-qemu stuff easier even going forward. > > Jason
