On Tue, 27 Nov 2018 12:52:48 -0700 Alex Williamson <alex.william...@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.
