Re: [PATCH V2 11/11] vfio: allow cpr-reboot migration if suspended

[Peter Xu <peterx@redhat.com>]

On Tue, Jan 16, 2024 at 03:37:33PM -0500, Steven Sistare wrote:
> On 1/15/2024 2:33 AM, Peter Xu wrote:
> > On Fri, Jan 12, 2024 at 07:05:10AM -0800, Steve Sistare wrote:
> >> Allow cpr-reboot for vfio if the guest is in the suspended runstate.  The
> >> guest drivers' suspend methods flush outstanding requests and re-initialize
> >> the devices, and thus there is no device state to save and restore.  The
> >> user is responsible for suspending the guest before initiating cpr, such as
> >> by issuing guest-suspend-ram to the qemu guest agent.
> >>
> >> Relax the vfio blocker so it does not apply to cpr, and add a notifier that
> >> verifies the guest is suspended.  Skip dirty page tracking, which is N/A for
> >> cpr, to avoid ioctl errors.
> >>
> >> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
> >> ---
> >>  hw/vfio/common.c              |  2 +-
> >>  hw/vfio/cpr.c                 | 20 ++++++++++++++++++++
> >>  hw/vfio/migration.c           |  2 +-
> >>  include/hw/vfio/vfio-common.h |  1 +
> >>  migration/ram.c               |  9 +++++----
> >>  5 files changed, 28 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> >> index 0b3352f..09af934 100644
> >> --- a/hw/vfio/common.c
> >> +++ b/hw/vfio/common.c
> >> @@ -128,7 +128,7 @@ int vfio_block_multiple_devices_migration(VFIODevice *vbasedev, Error **errp)
> >>      error_setg(&multiple_devices_migration_blocker,
> >>                 "Multiple VFIO devices migration is supported only if all of "
> >>                 "them support P2P migration");
> >> -    ret = migrate_add_blocker(&multiple_devices_migration_blocker, errp);
> >> +    ret = migrate_add_blocker_normal(&multiple_devices_migration_blocker, errp);
> >>  
> >>      return ret;
> >>  }
> >> diff --git a/hw/vfio/cpr.c b/hw/vfio/cpr.c
> >> index bbd1c7a..9f4b1fe 100644
> >> --- a/hw/vfio/cpr.c
> >> +++ b/hw/vfio/cpr.c
> >> @@ -7,13 +7,33 @@
> >>  
> >>  #include "qemu/osdep.h"
> >>  #include "hw/vfio/vfio-common.h"
> >> +#include "migration/misc.h"
> >>  #include "qapi/error.h"
> >> +#include "sysemu/runstate.h"
> >> +
> >> +static int vfio_cpr_reboot_notifier(NotifierWithReturn *notifier,
> >> +                                    MigrationEvent *e, Error **errp)
> >> +{
> >> +    if (e->state == MIGRATION_STATUS_SETUP &&
> >> +        !runstate_check(RUN_STATE_SUSPENDED)) {
> >> +
> >> +        error_setg(errp,
> >> +            "VFIO device only supports cpr-reboot for runstate suspended");
> >> +
> >> +        return -1;
> >> +    }
> > 
> > What happens if the guest is suspended during SETUP, but then quickly waked
> > up before CPR migration completes?
> 
> That is a management layer bug -- we told them the VM must be suspended.
> However, I will reject a wakeup request if migration is active and mode is cpr.

Yes it needs to be enforced if it is required by cpr-reboot.  QEMU
hopefully should never rely on mgmt app behavior.

> 
> >> +    return 0;
> >> +}
> >>  
> >>  int vfio_cpr_register_container(VFIOContainer *container, Error **errp)
> >>  {
> >> +    migration_add_notifier_mode(&container->cpr_reboot_notifier,
> >> +                                vfio_cpr_reboot_notifier,
> >> +                                MIG_MODE_CPR_REBOOT);
> >>      return 0;
> >>  }
> >>  
> >>  void vfio_cpr_unregister_container(VFIOContainer *container)
> >>  {
> >> +    migration_remove_notifier(&container->cpr_reboot_notifier);
> >>  }
> >> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> >> index 534fddf..488905d 100644
> >> --- a/hw/vfio/migration.c
> >> +++ b/hw/vfio/migration.c
> >> @@ -895,7 +895,7 @@ static int vfio_block_migration(VFIODevice *vbasedev, Error *err, Error **errp)
> >>      vbasedev->migration_blocker = error_copy(err);
> >>      error_free(err);
> >>  
> >> -    return migrate_add_blocker(&vbasedev->migration_blocker, errp);
> >> +    return migrate_add_blocker_normal(&vbasedev->migration_blocker, errp);
> >>  }
> >>  
> >>  /* ---------------------------------------------------------------------- */
> >> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> >> index 1add5b7..7a46e24 100644
> >> --- a/include/hw/vfio/vfio-common.h
> >> +++ b/include/hw/vfio/vfio-common.h
> >> @@ -78,6 +78,7 @@ struct VFIOGroup;
> >>  typedef struct VFIOContainer {
> >>      VFIOContainerBase bcontainer;
> >>      int fd; /* /dev/vfio/vfio, empowered by the attached groups */
> >> +    NotifierWithReturn cpr_reboot_notifier;
> >>      unsigned iommu_type;
> >>      QLIST_HEAD(, VFIOGroup) group_list;
> >>  } VFIOContainer;
> >> diff --git a/migration/ram.c b/migration/ram.c
> >> index 1923366..44ad324 100644
> >> --- a/migration/ram.c
> >> +++ b/migration/ram.c
> >> @@ -2392,8 +2392,8 @@ static void ram_save_cleanup(void *opaque)
> >>      RAMState **rsp = opaque;
> >>      RAMBlock *block;
> >>  
> >> -    /* We don't use dirty log with background snapshots */
> >> -    if (!migrate_background_snapshot()) {
> >> +    /* We don't use dirty log with background snapshots or cpr */
> >> +    if (!migrate_background_snapshot() && migrate_mode() == MIG_MODE_NORMAL) {
> > 
> > Same question here, on what happens if the user resumes the VM before
> > migration completes?  IIUC shared-ram is not required, then it means if
> > that happens the cpr migration image can contain corrupted data, and that
> > may be a problem.
> > 
> > Background snapshot is special in that it relies on totally different
> > tracking facilities (userfault, rather than KVM_GET_DIRTY_LOG), so it
> > disabled dirty tracking completely.  I assume not the case for cpr.
> > 
> > If cpr is not going to support that use case, IIUC it should fail that
> > system wakeup properly.  Or perhaps when CPR mode QEMU should instead
> > reject a wakeup?
> 
> Good catch, this hunk would break the non-vfio case where the guest can be
> running when migration is initiated.  I should narrow the logic to check for
> that:
> 
>     if (!migrate_background_snapshot() &&
>         (migrate_mode() == MIG_MODE_NORMAL || runstate_is_running()) {
>         ... use dirty logging ...
> 
> That plus rejecting a wakeup request should be sufficient.

Sounds good.

Please also consider adding "VM suspended for the whole cpr-reboot
migration process" into the cpr-reboot mode qapi/ documentation as a
hard requirement.  I don't see that mentioned at all, then people will be
surprised to see a wakeup failure otherwise.

Frankly, every time I re-read the cpr-reboot description I get confused on
what is implied and enforced in this mode.  Can we provide an update?

# @cpr-reboot: The migrate command saves state to a file, allowing one to
#              quit qemu, reboot to an updated kernel, and restart an updated
#              version of qemu.  The caller must specify a migration URI
#              that writes to and reads from a file.  Unlike normal mode,
#              the use of certain local storage options does not block the
#              migration, but the caller must not modify guest block devices
#              between the quit and restart.  To avoid saving guest RAM to the
#              file, the memory backend must be shared, and the @x-ignore-shared
#              migration capability must be set.  Guest RAM must be non-volatile
#              across reboot, such as by backing it with a dax device, but this
#              is not enforced.  The restarted qemu arguments must match those
#              used to initially start qemu, plus the -incoming option.
#              (since 8.2)

For example, is shared-mem enfornced?  AFAIU it's not required for now, at
least I don't remember any code to stop cpr-reboot migration if there's
private memories.

What about the image location restriction on non-volatile?  Is it required?
IIUC "guest ram must be non-volatile across reboot" asks more than what we
need to document for cpr-reboot.  For example, can someone use cpr-reboot
to upgrade the userspace virt stack, but doesn't want to upgrade the
kernel?  Then I assume dax is not required, since anyone can use a
memory-based file (like shmem, hugetlbfs, or even guest_memfd in the future
of security contexts)?

I think it's okay to keep such descriptions, but the document (so far only
exists in qapi/migration.json) should clearly describe what must be done,
separated from what is suggested.  The current version is still unclear,
IMHO, and it'll be good to amend it when adding the hard requirement on
suspended mode.  AFAIU the suspended mode helps:

  (1) vfio devices all stateless (vfio use case specific)

  (2) no dirty tracking required (vfio + non-vfio use case, e.g., merely no
      restriction on what block type the VM uses)

Also, since we already have cpr-reboot mode merged, we need a solid
document file describing this feature.  Maybe "what is suggested" should be
put into that document instead, keeping the qapi document the essential
documents.  Above explanations can also be good material to be mentioned
there (if my understanding of why suspended is a hard requirement is
correct..).

For that, feel free to pull the lastest qemu master branch, then you can
create a file under docs/devel/migration/, possibly, cpr-reboot.rst, and
link that into the features.rst file.  Currently we lack of docs for
migration features, but we do have plan to enrich it to some degree soon:

  https://www.qemu.org/docs/master/devel/migration/features.html

So it would be good to have cpr-reboot since the 1st day the whole feature
is there.  The doc can be posted separately if you prefer, so I can merge
the doc series even sooner (one patch to update qapi/, one to add that file
to docs/, perhaps).  You can also maintain missing items as TODO in the
same .rst file, depending on how much work is still leftover, then remove
entries alongside of your patches merged, which I mostly suggested the same
to fixed-ram.

Thanks,

-- 
Peter Xu