[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH v1 1/8] admin: Add theory of operation for device migration
On Fri, Oct 13, 2023 at 7:26âPM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, Oct 13, 2023 at 09:16:43AM +0800, Jason Wang wrote: > > 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. > > It is, fundamentally, a question of supporting as many architectures > as we can as opposed to being opinionated. > > On the one end of the spectrum, device is completely under guest control > and anything external has to trap to hypervisor. > None of existing implementations are there, at least pci config space > is typically under hypervisor control. > What Parav calls "passthrough" is built I think along these lines: > memory and interrupts go straight to guest, config space > is trapped and emulated. > On the other side of the spectrum is trapping everything in hypervisor. > Your "2 to 3 registers" is also not there, but is I think closer to that end > of the arc. Those simple registers could be used by both trapping or "passthrough". Depending on the viewpoint, it could be treated as a simple extension of existing common cfg, it can be used beyond just migration. Nothing prevents those registers from coexisting with things like admin virtqueue or commands. > > Any new feature should ideally be a building block supporting as many > approaches as possible. Fundamentally that requires a level of > indirection, as usual :) Exactly. So an transport/interface independent section in the basic facility makes a lot of sense. Thanks > Having two completely distict interfaces for > that straight off the bat? Gimme a break. > -- > MST > > > 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/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]