RE: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, September 21, 2023 3:40 PM
> 
> On Thu, Sep 21, 2023 at 09:17:53AM +0000, Parav Pandit wrote:
> > Vdpa stack make total sense when the underlying device is not virtio and
> hence emulation.
> 
> Which linux framework is used is kind of beside the point but since you bring
> this up - not necessarily.
> 
> E.g. I personally don't care much about "stack" but clearly we need a virtio
> driver on the host to be involved, teaching vfio about virtio is probably a much
> worse idea than creating a mode in the vdpa driver which mostly sets up the
> IOMMU and otherwise gets out of the way of using the VF and just drives the
> PF.
Well, vdpa has to drive large many things including cvq, config space, msix and more.
It can help to overcome some issues as you listed below.
So that way vdpa over virtio is useful.

In vfio world, there is nothing significant to teach about virtio.
Vfio is already has the model to extend the stack to do only specific work and reuse the rest.

> 
> But for example, to migrate cross-vendor you need the pci config space to look
> the same and for some devices this might mean that pci config space will have
> to be mediated.
> Or maybe not. vdpa is a good framework in that it gives us flexibility, it is not
> opinionated.

Sure, as you list, both has its pros and cons.
So both solutions has its space and trade off.

Hence, if both can converge to same set of commands, => good.
When there is different way two stacks operates for those items, we will have spec extensions for both model, right?