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 05:54:37AM +0000, Parav Pandit wrote:
> Hi Michael,
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, September 21, 2023 11:12 AM
> 
> > I was attempting to have each of you see other's point of view.
> > It seems clear I was right, at least one way communication was not getting
> > through. Let me try to help.
> > 
> > 
> > First, clearly Zhu Lingshan cares about the mediation use-case, not the un-
> > mediated one.  Mediation is clearly heavier but also more powerful in many
> > use-cases - is that obvious or do I need to list the reasons?
> 
> I agree to it.
> 
> > To mention one example, it supports cross-vendor migration. Which the
> > unmediated variant maybe can in theory support too, and when it does maybe
> > in a better and more structured way - but that will require standartization effort
> > that didn't happen yet. With mediation it was already demonstrated more than
> > once.
> >
> We should be enhancing the device context so that more and more items can be annotated.
> I started with small to get the design and idea through and will expand the device context so that cross vendors can migrate.

As I said, doable without mediation but already done with.


> > 1. For mediation something that works within existing mediation framework -
> > e.g. reusing as he does feature bits - will require less support than a completely
> > separate facility.
> > I think Zhu Lingshan also believes that since there will be less code -> less
> > security issues.
> >
> With approach of [1], there is less code in the core device migration flow because none of those fields etc are parsed/read/written by the driver software.

What is or is not executed in a specific flow is a separate question.
But the point is vdpa and any mediation have to talk virtio things
such as feature bits. So reusing e.g. feature bits needs less code
than operating the admin command machinery to check what is
supported. Yes, you can operate this machinery during setup
and not during migration itself. It's still less code to maintain.


> > 2. With or without mediation, the mapping of commands to VFs is simpler,
> > allowing more control - for example, let's say you want to reset a VF - you do not
> > need to flush the queue of existing commands, which might potentially take a
> > long time because some other VFs are very busy - you just reset the VF which
> > any unmap flow will already do.
> > 
> If I understand you right, to reset a VF, no need to flush the queues without mediation too.
> Just do VF FLR or do device reset, both will be fine.

Not to reset the VF - that's a narrow definition. To put it back in its
original state unrelated to any VMs.  Nope, FLR is not enough - there
could be commands in queue addressing the VF. If they take effect after
FLR VF state changed and it can't be cleanly assigned to a new VM.


> > 
> > 
> > But Zhu Lingshan, all this will be pointless if you also do not try to do this and list
> > what are reasonable points that Parav made. Please do not mistake what I'm
> > doing here for taking sides I just want the communication to start working. And
> > that means everyone tries to take all use-cases into account even if working for
> > a vendor that does not care about this use-case. Otherwise we will just keep
> > getting into these flamewars.
> 
> Right. I like to take this opportunity to ask again, lets sit together and see if we can utilize common framework between two methods.
> For example,
> 1. device context for mediation and without mediation can provide common structures that both solutions can use
> 2. device provisioning (not in any of our series, that can find common ways)
> 
> May be more can be merged once we are open to collaborate.
> If we face technical issues in unifying the methods, it will be self-explained why both methods to exist or create something different for two different use cases.


-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org