Re: [virtio-comment] [PATCH v1 1/8] admin: Add theory of operation for device migration

[Jason Wang <jasowang@redhat.com>]

On Thu, Oct 12, 2023 at 6:58âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > Sent: Thursday, October 12, 2023 3:51 PM
> >
> > On 10/11/2023 7:43 PM, Parav Pandit wrote:
> > >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > >> Sent: Wednesday, October 11, 2023 3:55 PM
> > >>>>>>> I donât have any strong opinion to keep it or remove it as most
> > >>>>>>> stakeholders
> > >>>>>> has the clear view of requirements now.
> > >>>>>>> Let me know.
> > >>>>>> So some people use VFs with VFIO. Hence the module name.  This
> > >>>>>> sentence by itself seems to have zero value for the spec. Just drop it.
> > >>>>> Ok. Will drop.
> > >>>> So why not build your admin vq live migration on our config space
> > >>>> solution, get out of the troubles, to make your life easier?
> > >>>>
> > >>> Your this question is completely unrelated to this reply or you
> > >>> misunderstood
> > >> what dropping commit log means.
> > >> if you can rebase admin vq LM on our basic facilities, I think you
> > >> dont need to talk about vfio in the first place, so I ask you to re-consider
> > Jason's proposal.
> > > I donât really know why you are upset with the vfio term.
> > > It is the use case of the cloud operator and it is listed to indicate how proposal
> > fits in a such use case.
> > > If for some reason, you donât like vfio, fine. Ignore it and move on.
> > >
> > > I already answered that I will remove from the commit log, because the
> > requirements are well understood now by the committee.
> > >
> > > Your comment is again unrelated (repeated) to your past two questions.
> > >
> > > I explained you the technical problem that admin command (not admin VQ)
> > of basic facilities cannot be done using config registers without any mediation
> > layer.
> > OK, I pop-ed Jason's proposal to make everything easier, and I see it is refused.
> Because it does not work for passthrough mode.

How and why? What's wrong with just passing through the newly
introduced 2 or 3 registers to guests?

This is the question you never answer even if I keep asking.

And again, passthrough is really confusing, PCI stuff can be
passthrough, and virtio can only be passthrough with a lot of
assumptions which are all missed in your series.

>
> > >
> > >>> Dropping link to vfio does not drop the requirement.
> > >>> I am ok to drop because requirements are clear of passthrough of
> > >>> member
> > >> device.
> > >>> Vfio is not a trouble at all.
> > >>> Admin command is not a trouble either.
> > >>>
> > >>> The pure technical reason is: all the functionalities proposed
> > >>> cannot be done
> > >> in any other existing way.
> > >>> Why? For below reasons.
> > >>> 1. device context, and write records (aka dirty page addresses) is
> > >>> huge which cannot be shared using config registers at scale of 4000
> > >>> member devices
> > >> dirty page tracking will be implmemented in V2, actually I have the
> > >> patch right now.
> > > That is yet again the invitation to non_colloboration mode.
> > > Without reviewing, v0 and v1, you want to show dirty page tracking in some
> > other way.
> > >
> > > But ok, that is your non_coperative mode of working. Cannot help further.
> > I believe both me and Jason have proposed a solution, I see it is rejected.
> > But don't take it personal and please keep professional.
> Sure, as I explained the config register method do not work for passthrough mode, and does not scale.

We need to make sure your migration proposal can work for 1 VF which
is still questionable then we can talk about others like scaling. No?

And most of your concern regarding scalability seems more like a
limitation of a transport. Let's not mix the scalability for a
specific transport with the one for core virtio devices.

>
> > >
> > >> inflight descriptor tracking will be implemented by Eugenio in V2.
> > > When we have near complete proposal from two device vendors, you want
> > > to push something to unknown future without reviewing the work; does not
> > make sense.
> > Didn't I ever provide feedback to you? Really?
> No. I didnât see why you need to post a new patch for dirty page tracking, when it is already present in this series.

You know there are various ways to do dirty paging? For example, the
well known bitmap and its variants. I think we've discussed several
times in many places in the past. I don't see where you explain why
you choose one of them but not the others but you want to forbid other
types of dirty page logging? Why?

> I would like to understand and review this aspects.
> Same for the device context.
>
> > >
> > > You are still in the mode of _take_ what we did with near zero explanation.
> > > You asked question of why passthrough proposal cannot advantage of in_band
> > config registers.
> > > I explained technical reason listed here.
> > I have answered the questions, and asked questions for many times.
> > What do you mean by "why passthrough proposal cannot advantage of in_band
> > config registers."?
> > Config space work for passthrough for sure.
> Config space registers are passthrough the guest VM.
> Hence hypervisor messing it with, programming some address would result in either security issue.
> Or functionally broken, to sustain the functionality, each nested layer needs one copy of these registers for each nest level.
> So they must be trapped somehow.
>
> Secondly I donât see how one can read 1M flows using config registers.

Why can't we trap them? vIOMMU even migrates internal translation tables.

Thanks