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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, November 16, 2023 12:09 PM
> 
> On Thu, Nov 16, 2023 at 06:34:23AM +0000, Parav Pandit 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
> >
> > 2. migration writes covers large part of the configurations not just virtio
> common config and device config.
> > Such as configuration occurred through the CVQ. All of these is not needed
> when done from guest directly via member's own CVQ.
> >
> > For backward compatible SIOV transport, one may need them to transport
> without above two properties.
> >
> > 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.
> >
> 
> To clarify. Above seems to justify why the admin commands for migration must
> be distinct from admin commands for transport. But I don't see why (e.g. two
> sets of) admin commands can not be used for both. Do you?

I didn't follow, "used for both".
Can you please explain?
Both meaning, 
a. for device migration and 
b. for transporting configuration by owner device on behalf of member device?