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 12:39:31PM +0000, Parav Pandit wrote:
> 
> > 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.

Modularity is good generally but it's all guessing.

-- 
MST