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

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

On Fri, Nov 24, 2023 at 11:56:16AM +0800, Jason Wang wrote:
> On Wed, Nov 22, 2023 at 3:48âPM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Nov 22, 2023 at 12:13:34PM +0800, Jason Wang wrote:
> > > > > What's wrong if we just allow them to be R/W over adminq/cmmands?
> > > > >
> > > > As explained before,
> > > > Each guest has its own dedicated non mediated interface as defined in virtio spec to not involve hypervisor.
> > >
> > > So what's wrong with inventing per VF queue to do that? For example
> > > transport virtqueue.
> >
> > Nothing is wrong with this.
> >
> > But what is problematic is just re-using config space for migration because
> 
> It's not a reusing, it works exactly like this proposal:
> 
> 1) VF config space is assigned to guest
> 2) using PF queue to migrate
> 
> The only difference is the command:
> 
> In this proposal, it is
> 
> 1) virtio_dev_ctx_pci_vq_cfg structure
> 2) in transport virtqueue, it introduce a set of commands to access
> one or several fields on the common cfg
> 
> Thanks

The problem with 2) is no one seems to bother building it right now,
so I'm not sure we can with a straight face require people to
use this infrastructure which does not exist.
And the need this patchset is trying to address is real. So I think
we should address this proposal on its own merits not on how well
it compares with a theoretical transport virtqueue.

> > it means we can not just say "don't access device after it is stopped"
> > because yes you need to access it to save/restore state.
> > And a new interface over admin cmds just for this side-steps the
> > issue nicely.
> >
> > --
> > MST
> >