Re: [virtio-comment] Re: [PATCH V2 6/6] virtio-pci: implement dirty page tracking

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

On 11/7/2023 6:25 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 07, 2023 at 06:01:27PM +0800, Zhu, Lingshan wrote:
> > On 11/6/2023 7:13 PM, Parav Pandit wrote:
> > > > From: Zhu, Lingshan <lingshan.zhu@intel.com>
> > > > Sent: Monday, November 6, 2023 3:04 PM
> > > > So, please no pass-through discussion anymore.
> > > If you comment like this, nothing can progress.
> > >
> > > What you are implying with above language is:
> > > "hey a virtio can do live migration ONLY by creating vdpa device on top of ALREADY virtio device, and you get another virtio device by running through 3 layers of stack you get virtio device on other side!".
> > I never say that right? I keep explaining how pass-through and "trap and
> > emulate work", I even explained how PASID work.
> Parav, Lingshan can we please stop the "what is pass through" arguments?
>
> I think thatthe term is vague, as
> (almost?) no hypervisor passes all accesses without exemption through.
> And the fact you are speaking past enough other on this subject
> for how long now? seems to demonstrate I'm right.
>
> Describing migration in the spec as opposed to leaving it up to
> hypervisors seems valuable at least to me since historically hypervisors
> did such a bad job of it. So I personally feel it's nice if it's there,
> and the SUSPEND bit only works after DRIVER_OK. So that's an example
> argument that makes sense to me.  But number of layers involved in control
> path seems completely irrelevant to most people. *That* is an nvidia
> thing, something very specific about vfio and vdpa and whatnot.
> Nothing to do with the spec, wrong list for this.
I agree and thanks Micheal for your help.
It's OK for me to let SUSPEND only work after DRIVER_OK.
> > > Then for sure, I disagree to it for 100% for such a single-minded design.
> > >
> > > At least I am trying to propose if a solution can work for generic passthrough where least amount of hypervisor mediation is done.
> > >
> > > And an extension where hypervisor has choice to more medication layers as it finds suitable.
> > > And if there are technical issues, may be two different interfaces or more admin commands needed for two modes.
> > > The idea is to attempt to converge and discuss those details, not the opposite.
> > >
> > > Your above comment shows a clear sign of non-collaboration to make both mode works.
> > Well, I see you are emotional, please take a deep breath and calm down, to
> > be professional,
> > give yourself a break, and really not necessary to be mad at me.
> >
> > As you know I am just a Junior Engineer in Intel, not like you a Senior
> > Principle Engineer who has spent many years and
> > have developed knowledge in this area. So I am quite technical focusing,
> > they are all technical discussions till now.
> It looks more like a passive-agressive flamewar from the side.
> So maybe try to see other's point of view. I asked what's the advantage of
> admin vq thing for migration and you said "it's an nvidia thing".
> And when people try to point them out to you, you go well tough.
> Maybe but we are wasting time here.
yeah, sorry for that, lets focus on technical opens, get things done,
release better quality of work as we try our best.
> > We always welcome collaboration, remember Jason has proposed a solution to
> > build admin vq based on these basic facilities,
> > and I am fully agree on his proposal.
> I didn't see anything specific frankly, I can easily see how Parav could
> get mad if he posts a reasonably fleshed out patchset (which admittedly,
> needs work with wording etc) and instead of review gets back
> "rework this on top of these basic facilities which we don't yet know
> how they will work but maybe will". We'll be stuck in this loop for
> how long?
OK, I did not copy-paste Jason's proposal there.
Then if needed, lets try work out another approach.
> > > At one point I may probably stop responding to your comments that repeatedly says:
> > >
> > > "Go read QEMU code, Do you know what is PASID?, Do you know num_queues, Go read PCI spec"...
> > With all respect, you should do these because they are text book knowledge.
> > > Taking deep breath now to do some productive work in TC...
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/