From: Andrey Gruzdev via <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: Den Lunev <den@openvz.com>, Eric Blake <eblake@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Juan Quintela <quintela@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>
Subject: [PATCH v2 5/7] Implementation of vm_start() BH.
Date: Wed, 18 Nov 2020 16:20:46 +0300 [thread overview]
Message-ID: <20201118132048.429092-6-andrey.gruzdev@virtuozzo.com> (raw)
In-Reply-To: <20201118132048.429092-1-andrey.gruzdev@virtuozzo.com>
To avoid saving updated versions of memory pages we need
to start tracking RAM writes before we resume operation of
vCPUs. This sequence is especially critical for virtio device
backends whos VQs are mapped to main memory and accessed
directly not using MMIO callbacks.
One problem is that vm_start() routine makes calls state
change notifier callbacks directly from itself. Virtio drivers
do some stuff with syncing/flusing VQs in its notifier routines.
Since we poll UFFD and process faults on the same thread, that
leads to the situation when the thread locks in vm_start()
if we try to call it from the migration thread.
The solution is to call ram_write_tracking_start() directly
from migration thread and then schedule BH for vm_start.
Signed-off-by: Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>
---
migration/migration.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/migration/migration.c b/migration/migration.c
index 158e5441ec..dba388f8bd 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -3716,7 +3716,13 @@ static void *migration_thread(void *opaque)
static void wt_migration_vm_start_bh(void *opaque)
{
- /* TODO: implement */
+ MigrationState *s = opaque;
+
+ qemu_bh_delete(s->wt_vm_start_bh);
+ s->wt_vm_start_bh = NULL;
+
+ vm_start();
+ s->downtime = qemu_clock_get_ms(QEMU_CLOCK_REALTIME) - s->downtime_start;
}
/*
--
2.25.1
next prev parent reply other threads:[~2020-11-18 13:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 13:20 [PATCH v2 0/7] UFFD write-tracking migration/snapshots Andrey Gruzdev via
2020-11-18 13:20 ` [PATCH v2 1/7] Introduce 'track-writes-ram' migration capability Andrey Gruzdev via
2020-11-18 13:20 ` [PATCH v2 2/7] Introduced UFFD-WP low-level interface helpers. Implemented support for the whole RAM block memory protection/un-protection. Higher level ram_write_tracking_start() and ram_write_tracking_stop() to start/stop tracking memory writes on the whole VM memory Andrey Gruzdev via
2020-11-18 13:20 ` [PATCH v2 3/7] Support UFFD write fault processing in ram_save_iterate() Andrey Gruzdev via
2020-11-18 13:20 ` [PATCH v2 4/7] Implementation of write-tracking migration thread Andrey Gruzdev via
2020-11-18 13:20 ` Andrey Gruzdev via [this message]
2020-11-18 13:20 ` [PATCH v2 6/7] The rest of write tracking migration code Andrey Gruzdev via
2020-11-18 13:20 ` [PATCH v2 7/7] Introduced simple linear scan rate limiting mechanism for write tracking migration Andrey Gruzdev via
2020-11-18 14:54 ` [PATCH v2 0/7] UFFD write-tracking migration/snapshots Eric Blake
2020-11-19 7:26 ` Andrey Gruzdev
2020-11-19 8:49 ` Andrey Gruzdev
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=20201118132048.429092-6-andrey.gruzdev@virtuozzo.com \
--to=qemu-devel@nongnu.org \
--cc=andrey.gruzdev@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=den@openvz.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=pbonzini@redhat.com \
--cc=quintela@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).