On Thu, Sep 21, 2023 at 12:39:31PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin <m...@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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
