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. > > Even then you need a controlling and a controlled entity. The > > controlling entity even in SIOV remains a PCIe function. The > > controlled entity might just be a bunch of hardware resoures and > > a PASID. Making it important again that all migration is driven > > by the controlling entity. > > If they are the same driver implementing vfio_device you may be able > to claim they conceptually exist, but it is pretty artificial to draw > this kind of distinction inside a single driver. How are they in this reply? I can't parse how this even relates to what I wrote. > > Also the whole concept that only VFIO can do live migration is > > a little bogus. With checkpoint and restart it absolutely > > does make sense to live migrate a container, and with that > > the hardware interface (e.g. nvme controller) assigned to it. > > I agree people may want to do this, but it is very unclear how SRIOV > live migration can help do this. SRIOV live migration doesn't, because honestly there is no such thing as "SRIOV" live migration to start with. > Let alone how to solve the security problems of allow userspace to > load arbitary FW blobs into a device with potentially insecure DMA > access.. Any time you assign a PCI device to userspace you might get into that.
