OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Thu, Nov 16, 2023 at 06:43:05AM +0000, Parav Pandit wrote:
> 
> 
> > 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?

Yes, so one set of commands for migration another for passing config
space accesses. We do in fact have admin commands as transport for
legacy, do we not? And in this model we can have new group types,
e.g. SIOV's subfunction or even a "self" group.

-- 
MST



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]