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. 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) > 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
