On Fri, Sep 22, 2023 at 11:01:23AM +0800, Jason Wang wrote: > > Even when it does, there is no real use case to live migrate a > > virtio-net function from, say, AWS to GCP. > > It can happen inside a single cloud vendor. For some reasons, DPU must > be purchased from different vendors. And vDPA has been used in that > case. Nope, you misunderstand the DPU scenario. Look at something like vmware DPU enablement. vmware runs the software side of the DPU and all their supported DPU HW, from every vendor, generates the same PCI functions on the x86. They are the same because the same software on the DPU side is creating them. There is no reason to put a mediation layer in the x86 if you also control the DPU. Cloud vendors will similarly use DPUs to create a PCI functions that meet the cloud vendor's internal specification. Regardless of DPU vendor. Fundamentally if you control the DPU SW and the hypervisor software you do not need hypervisor meditation because everything you could do in hypervisor mediation can just be done in the DPU. Putting it in the DPU is better in every regard. So, as I keep saying, in this scenario the goal is no mediation in the hypervisor. It is pointless, everything you think you need to do there is actually already being done in the DPU. Once you commit to this configuration you are committed to VFIO in the hypervisor. eg your DPU is likely also making NVMe and other PCI functions too. > The problem is the mediation (or what you called relaying) layer > you've invented. It is not mediation, it is implementing the OASIS spec for VFIO support of IO BAR. Jason
