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

[Cornelia Huck <cohuck@redhat.com>]

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.

This model would also be simple enough to allow e.g. a vendor driver
for mdev to implement its own, specialized backend while still fitting
into the general framework. Non-pci mdevs are probably different enough
from pci devices so that many of the states proposed don't really match
their needs.