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

[Jason Wang <jasowang@redhat.com>]

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