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

[Jason Wang <jasowang@redhat.com>]

On Thu, Nov 16, 2023 at 2:34âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, November 16, 2023 11:53 AM
> >
> > On Thu, Nov 16, 2023 at 05:28:19AM +0000, Parav Pandit wrote:
> > > You continue to want to overload admin commands for dual purpose, does
> > not make sense to me.
> >
> > dual -> as a transport and for migration? why can't they be used for this? I was
> > really hoping to cover these two cases when I proposed them.
> For following reasons.
>
> 1. migration needs incremental reads of only changed context between two reads

This is wrong. We need to invent general facilities. I've pointed out
sufficient issues, and what's more delta doesn't work for the
following cases:

1) migration but fail the another try for migration
2) save vm state twice

It request a lot of tricks in hypervisor to do that (e.g cache the last state?).

>
> 2. migration writes covers large part of the configurations not just virtio common config and device config.

You invent a duplication of common_cfg structure no?

What's wrong if we just allow them to be R/W over adminq/cmmands?

> Such as configuration occurred through the CVQ. All of these is not needed when done from guest directly via member's own CVQ.

That's the device type specific state which requires new commands
forsure. I don't see any connection. The SIOV device needs to be
migrated as well.

>
> For backward compatible SIOV transport, one may need them to transport without above two properties.

Why, just mediate between virtual PCI and adminq.

>
> 3. None of this transport is needed for PFs, VFs and non-backward compatible SIOVs.
> Each device to have its own transport that is not intercepted by the hypervisor and follow the equivalency principle uniformly for all 3 device types.

You can have per VF transport q, what's wrong with that?

Thanks

>
>