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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 9/27/2023 11:40 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2023 at 04:20:01PM +0800, Zhu, Lingshan wrote:
> > On 9/26/2023 6:48 PM, Michael S. Tsirkin wrote:
> > > On Tue, Sep 26, 2023 at 05:25:42PM +0800, Zhu, Lingshan wrote:
> > > > We don't want to repeat the discussions, it looks like endless circle with
> > > > no direction.
> > > OK let me try to direct this discussion.
> > > You guys were speaking past each other, no dialog is happening.
> > > And as long as it goes on no progress will be made and you
> > > will keep going in circles.
> > >
> > > Parav here made an effort and attempted to summarize
> > > use-cases addressed by your proposal but not his.
> > > He couldn't resist adding "a yes but" in there oh well.
> > > But now I hope you know he knows about your use-cases?
> > >
> > > So please do the same. Do you see any advantages to Parav's
> > > proposal as compared to yours? Try to list them and
> > > if possible try not to accompany the list with "yes but"
> > > (put it in a separate mail if you must ;) ).
> > > If you won't be able to see any, let me know and I'll try to help.
> > >
> > > Once each of you and Parav have finally heard the other and
> > > the other also knows he's been heard, that's when we can
> > > try to make progress by looking for something that addresses
> > > all use-cases as opposed to endlessly repeating same arguments.
> > Sure Michael, I will not say "yes but" here.
> >
> >  From Parav's proposal, he intends to migrate a member device by its owner
> > device through the admin vq,
> > thus necessary admin vq commands are introduced in his series.
> >
> >
> > I see his proposal can:
> > 1) meet some customers requirements without nested and bare-metal
> > 2) align with Nvidia production
> > 3) easier to emulate by onboard SOC
> Is that all you can see?
>
> Hint: there's more.
please help provide more.
> > The general purpose of his proposal and mine are aligned: migrate virtio
> > devices.
> >
> > Jason has ever proposed to collaborate, please allow me quote his proposal:
> >
> > "
> > Let me repeat once again here for the possible steps to collaboration:
> >
> > 1) define virtqueue state, inflight descriptors in the section of
> > basic facility but not under the admin commands
> > 2) define the dirty page tracking, device context/states in the
> > section of basic facility but not under the admin commands
> > 3) define transport specific interfaces or admin commands to access them
> > "
> >
> > I totally agree with his proposal.
> >
> > Does this work for you Michael?
> >
> > Thanks
> > Zhu Lingshan
> I just doubt very much this will work.  What will "define" mean then -
> not an interface, just a description in english? I think you
> underestimate the difficulty of creating such definitions that
> are robust and precise.
I think we can review the patch to correct the words.
> Instead I suggest you define a way to submit admin commands that works
> for nested and bare-metal (i.e. not admin vq, and not with sriov group
> type). And work with Parav to make live migration admin commands work
> reasonably will through this interface and with this type.
why admin commands are better than registers?
>