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

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

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.

Any new feature should ideally be a building block supporting as many
approaches as possible. Fundamentally that requires a level of
indirection, as usual :) Having two completely distict interfaces for
that straight off the bat?  Gimme a break.
-- 
MST