On Wed, Dec 07, 2022 at 05:38:57PM +0100, Christoph Hellwig wrote: > On Wed, Dec 07, 2022 at 11:07:11AM -0400, Jason Gunthorpe wrote: > > > And while that is a fine concept per see, the current incarnation of > > > that is fundamentally broken is it centered around the controlled > > > VM. Which really can't work. > > > > I don't see why you keep saying this. It is centered around the struct > > vfio_device object in the kernel, which is definately NOT the VM. > > Sorry, I meant VF. Your continued using of SR-IOV teminology now keeps > confusing my mind so much that I start mistyping things. Well, what words do you want to use? Regardless of VF/VM, it doesn't matter - my point is that the vfio_device is the hypervisor control for *whatever* is under the vfio_device and it is not desirable to break it up along arbitrary HW boundaries. I've given lots of reasons why not to do this now. I strongly suspect it can work technically - as ugly as it is Pensando shows an approach. So I don't think I've learned anything more about your objection. "fundamentally broken" doesn't help It is a major point, because if we are going to have to rip apart all the uAPI we built here and are completing the qemu work for, we need to come to an understanding very soon. And given how difficult it has been to get to this point, I want a *really* good reason why we have to start again, and rewrite all the drivers that exist and are coming. Jason
