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

[Jason Wang <jasowang@redhat.com>]

On Thu, Oct 19, 2023 at 1:32âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Jason Wang
> > Sent: Thursday, October 19, 2023 10:15 AM
> >
> > > > Again, if you don't want to talk about transport virtqueue, that's
> > > > fine. But let's leave the scalability issue aside as well.
> > > >
> > > Registers are related for functionality and scale.
> > >
> > > Lets first agree on use case before the design, that I asked above.
> > >
> > > I will wait to respond to any other emails until we agree on use case
> > requirements.
> >
> > There are more than just me who want you to define "passthrough" first where
> > you refuse to respond.
> >
> Totally disagree.
> In the previous email itself, I wrote what passthrough is.
> So let's try yet one more time.
> Either you can re-read last email or for better read below and see if it is understood or not.
>
> > How could we make any agreement without an accurate the definition of
> > "passthrough" who is a key to understand each other?
>
> I replied few times in past emails but since those email threads are so long, it is easy to miss out.
>
> Passthrough definition:
> a. virtio member device mapped to the guest vm

I really think we need to be accurate here. For example, what does
"map" mean here?

> b. only pci config space and msix of a member device is intercepted by hypervisor.

What's the criteria for choosing a cap/bar to be trapped or not? For
example, there're a lot of other things that need to be virtualized
besides MSI-X for sure.

> c. virtio config space, virtio cvqs, data vqs of a member device is directly accessed by the guest vm without intercepted by the hypervisor.
>
> (Why b?, no grand reason, it is how the hypervisors are working where to integrate the virtio member device to).

What you state here is more about the method to support a use case not
the use case itself. My understanding is "live migration" is a valid
use case for sure. And "passthough" is probably one way for achieving
live migration but this is what you need to define and justify in this
series.

What's more, I'm not convinced of a large series that is only designed
for a specific method of building a hypervisor. I'm more convinced
that if it can serve multiple different methods of building
hypervisors, I believe it would be more beneficial for virtio.

Thanks

>