Re: [PATCH vfio 11/11] vfio/virtio: Introduce a vfio driver over virtio devices

[Jason Gunthorpe <jgg@nvidia.com>]

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