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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 21, 2023 at 10:39:23AM +0000, Parav Pandit wrote:
> 
> > 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.

Again the thread has been side-tracked, which linux module does what is
not what it was talking about.  By the way I wonder who decided to drop
virtio comment from this and copy virtio-dev. Guys please don't do this
and generally just send spec patches to virtio-comment, implementation
discussion on virtio-dev.


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

You can thinkably write a vfio based driver for PF and VF in userspace,
sure. But I think this is just making things unnecessarily complex
for users who will have to know which device to use with which
driver. I think that e.g. if we have two ways to submit admin
commands, vdpa can just support both of them and that is all.
When mediation is not needed then vdpa will just get out of the way.

> 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?

My intiution says a modest amount of duplication isn't too bad.
E.g. I can see two ways to submit admin commands as being acceptable.
Are the SUSPEND bit and vq state as defined by these patches acceptable
in addition to vq commands as defined by your patches? For sure
it seems inelegant to say the least.


-- 
MST