Re: [Qemu-devel] [PATCH 1/5] VFIO KABI for migration interface

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 4 Dec 2018 11:53:33 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Tue, 27 Nov 2018 12:52:48 -0700
> Alex Williamson <alex.williamson@redhat.com> wrote:
> 
> > Actually I'm wondering if we can distill everything down to two bits,
> > STOPPED and LOGGING.
> > 
> > We start at RUNNING, the user can optionally enable LOGGING when
> > supported by the device to cover the SETUP and PRECOPY states
> > proposed.  The device stays running, but activates any sort of
> > dirtly page tracking that's necessary to activate those interfaces.
> > LOGGING can also be cleared to handle the CANCELLED state.  The user
> > would set STOPPED which should quiesce the device and make the full
> > device state available through the device data section.  Clearing
> > STOPPED and LOGGING would handle the FAILED state below.  Likewise on
> > the migration target, QEMU would set the device top STOPPED in order to
> > write the incoming data via the data section and clear STOPPED to
> > indicate the device returns to RUNNING (aka RESUME/RESUME_COMPLETED).  
> 
> This idea sounds like something that can be more easily adapted to
> other device types as well. The LOGGING bit is probably more flexible
> if you reframe it as a PREPARATION bit: That would also cover devices
> or device types that don't do dirty logging, but need some other kind
> of preparation prior to moving over.

Can you elaborate on what PREPARATION might do w/o dirty logging?
LOGGING is just a state, it's on or off, whereas PREPARATION implies
some sequential step in a process and then I'm afraid we slide back into
states that a really steps in a QEMU specific migration process.  So
I'm curious why PREPARATION wouldn't just be a vendor implementation
specific first step when RUNNING is turned off.  A device that doesn't
implement dirty logging could always just claim everything is dirty if
it wants that advanced warning that RUNNING might be turned off soon,
but there are probably more efficient ways to support that, ex. a flag
indicating the dirty logging granularity.  Thanks,

Alex