On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > If you see this as an abuse of the framework, then let's identify those > specific issues and come up with a better approach. As we've discussed > before, things like basic PCI config space emulation are acceptable > overhead and low risk (imo) and some degree of register emulation is > well within the territory of an mdev driver. What troubles me is that idxd already has a direct userspace interface to its HW, and does userspace DMA. The purpose of this mdev is to provide a second direct userspace interface that is a little different and trivially plugs into the virtualization stack. I don't think VFIO should be the only entry point to virtualization. If we say the universe of devices doing user space DMA must also implement a VFIO mdev to plug into virtualization then it will be alot of mdevs. I would prefer to see that the existing userspace interface have the extra needed bits for virtualization (eg by having appropriate internal kernel APIs to make this easy) and all the emulation to build the synthetic PCI device be done in userspace. Not only is it better for security, it keeps things to one device driver per device.. Jason
