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

["Michael S. Tsirkin" <mst@redhat.com>]

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.


> > 
> > 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.

> 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?


> > 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/