From: Steven Sistare <steven.sistare@oracle.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Cedric Le Goater <clg@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Marc-Andre Lureau <marcandre.lureau@redhat.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH V2 11/11] vfio: allow cpr-reboot migration if suspended
Date: Tue, 16 Jan 2024 15:37:33 -0500 [thread overview]
Message-ID: <470484ea-ece5-4a73-b84a-eef98f84ed9b@oracle.com> (raw)
In-Reply-To: <ZaTfwOs2g_A4a1pO@x1n>
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.
>> + 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.
- Steve
>> /* caller have hold BQL or is in a bh, so there is
>> * no writing race against the migration bitmap
>> */
>> @@ -2804,8 +2804,9 @@ static void ram_init_bitmaps(RAMState *rs)
>>
>> WITH_RCU_READ_LOCK_GUARD() {
>> ram_list_init_bitmaps();
>> - /* 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) {
>> memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);
>> migration_bitmap_sync_precopy(rs, false);
>> }
>> --
>> 1.8.3.1
>>
>
next prev parent reply other threads:[~2024-01-16 20:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 15:04 [PATCH V2 00/11] allow cpr-reboot for vfio Steve Sistare
2024-01-12 15:05 ` [PATCH V2 01/11] notify: pass error to notifier with return Steve Sistare
2024-01-15 6:38 ` Peter Xu
2024-01-12 15:05 ` [PATCH V2 02/11] migration: remove error from notifier data Steve Sistare
2024-01-15 6:38 ` Peter Xu
2024-01-12 15:05 ` [PATCH V2 03/11] migration: convert to NotifierWithReturn Steve Sistare
2024-01-15 6:44 ` Peter Xu
2024-01-16 20:35 ` Steven Sistare
2024-01-17 2:29 ` Peter Xu
2024-01-12 15:05 ` [PATCH V2 04/11] migration: remove migration_in_postcopy parameter Steve Sistare
2024-01-15 6:48 ` Peter Xu
2024-01-16 20:36 ` Steven Sistare
2024-01-12 15:05 ` [PATCH V2 05/11] migration: MigrationEvent for notifiers Steve Sistare
2024-01-12 15:18 ` Steven Sistare
2024-01-12 15:05 ` [PATCH V2 06/11] migration: MigrationNotifyFunc Steve Sistare
2024-01-12 15:05 ` [PATCH V2 07/11] migration: per-mode notifiers Steve Sistare
2024-01-12 15:05 ` [PATCH V2 08/11] migration: refactor migrate_fd_connect failures Steve Sistare
2024-01-15 7:37 ` Peter Xu
2024-01-16 20:35 ` Steven Sistare
2024-01-12 15:05 ` [PATCH V2 09/11] migration: notifier error checking Steve Sistare
2024-01-12 15:05 ` [PATCH V2 10/11] vfio: register container for cpr Steve Sistare
2024-01-12 15:05 ` [PATCH V2 11/11] vfio: allow cpr-reboot migration if suspended Steve Sistare
2024-01-15 7:33 ` Peter Xu
2024-01-16 20:37 ` Steven Sistare [this message]
2024-01-16 20:44 ` Steven Sistare
2024-01-17 7:12 ` Peter Xu
2024-01-17 21:30 ` Steven Sistare
2024-01-18 3:20 ` Peter Xu
2024-01-12 21:38 ` [PATCH V2 00/11] allow cpr-reboot for vfio Alex Williamson
2024-01-16 20:36 ` Steven Sistare
2024-01-15 10:48 ` David Hildenbrand
2024-01-15 10:51 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=470484ea-ece5-4a73-b84a-eef98f84ed9b@oracle.com \
--to=steven.sistare@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=david@redhat.com \
--cc=farosas@suse.de \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.