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

[Jason Wang <jasowang@redhat.com>]

On Tue, Nov 7, 2023 at 3:22âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Nov 07, 2023 at 12:05:12PM +0800, Jason Wang wrote:
> > > > > > One thing that you ignore is that, hypervisor can use what you
> > > > > > invented as a transport for VF, no?
> > > > > >
> > > > > No. by design,
> > > >
> > > > It works like hypervisor traps the virito config and forwards it to admin
> > > > virtqueue and starts the device via device context.
> > > It needs more granular support than the management framework of device context.
> >
> > It doesn't otherwise it is a design defect as you can't recover the
> > device context in the destination.
> >
> > Let me give you an example:
> >
> > 1) in the case of live migration, dst receive migration byte flows and
> > convert them into device context
> > 2) in the case of transporting, hypervisor traps virtio config and
> > convert them into the device context
> >
> > I don't see anything different in this case. Or can you give me an example?
>
> "trap virtio config" means "trap writes into virtio config" presumably?

It means trap as current Qemu did.

> config can change itself without driver doing anything. Hypervisor
> can't trap it then.

I don't understand here, the hypervisor can see the config interrupt.
This is how Qemu works now?

> This is one of the problems with Lingshan's
> SUSPEND bit - what happens with these config changes in underspecified.

I don't see a direct relationship with SUSPEND bit here. I meant this
proposal can be used for the hypervisor to trap and emulate config.

Thanks


>
> --
> MST
>