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 5:53 PM

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

I have no idea who dropped the virtio-comment.
For sure it is not me, as I am fully aware that virtio-dev is not the one to discuss.

> 
> 
> > >
> > > 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.
> 
Well there is enough documentation already exists to indicate users to know when to use what.

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

Right, my patches are not bifurcating the device during the device migration.
It has generic device migration concept, so be it config space, or shared memory or admin queue or config interrupts or some other dma interface or some other things.
All are covered under device migration that software does not need to bisect.

So may be instead of suspending the VQ, it can be reseting the VQ by using existing functionality, and when enabling the VQ, it can start from newly supplied avail index.
This way, it can be elegant too.

These patches do not explain the motivation of why to suspend individual queues. Do you know?
There is suspend device bit as well, so it is unclear why to have both.