On Mon, Sep 25, 2023 at 03:53:18PM -0300, Jason Gunthorpe wrote: > On Mon, Sep 25, 2023 at 02:16:30PM -0400, Michael S. Tsirkin wrote: > > > I do want to understand if there's a use-case that vdpa does not address > > simply because it might be worth while to extend it to do so, and a > > bunch of people working on it are at Red Hat and I might have some input > > into how that labor is allocated. But if the use-case is simply "has to > > be vfio and not vdpa" then I guess not. > > If you strip away all the philisophical arguing VDPA has no way to > isolate the control and data virtqs to different IOMMU configurations > with this single PCI function. Aha, so address space/PASID support then? > The existing HW VDPA drivers provided device specific ways to handle > this. > > Without DMA isolation you can't assign the high speed data virtq's to > the VM without mediating them as well. > > > It could be that we are using mediation differently - in my world it's > > when there's some host software on the path between guest and hardware, > > and this qualifies. > > That is pretty general. As I said to Jason, if you want to use it that > way then you need to make up a new word to describe what VDPA does as > there is a clear difference in scope between this VFIO patch (relay IO > commands to the device) and VDPA (intercept all the control plane, > control virtq and bring it to a RedHat/qemu standard common behavior) IIUC VDPA itself does not really bring it to either RedHat or qemu standard, it just allows userspace to control behaviour - if userspace is qemu then it's qemu deciding how it behaves. Which I guess this doesn't. Right? RedHat's not in the picture at all I think. > > There is also a question of capability. Specifically iommufd support > > is lacking in vdpa (though there are finally some RFC patches to > > address that). All this is fine, could be enough to motivate > > a work like this one. > > I've answered many times, you just don't semm to like the answers or > dismiss them as not relevant to you. > > Jason Not really I think I lack some of the picture so I don't fully understand. Or maybe I missed something else. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
