From: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>,
Juan Quintela <quintela@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: [Qemu-devel] [PATCH v3 1/2] migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END
Date: Thu, 16 Nov 2017 20:35:26 -0200 [thread overview]
Message-ID: <20171116223527.4499-2-danielhb@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171116223527.4499-1-danielhb@linux.vnet.ibm.com>
When migrating a VM with 'migrate_set_capability postcopy-ram on'
a postcopy_state is set during the process, ending up with the
state POSTCOPY_INCOMING_END when the migration is over. This
postcopy_state is taken into account inside ram_load to check
how it will load the memory pages. This same ram_load is called when
in a loadvm command.
Inside ram_load, the logic to see if we're at postcopy_running state
is:
postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING
postcopy_state_get() returns this enum type:
typedef enum {
POSTCOPY_INCOMING_NONE = 0,
POSTCOPY_INCOMING_ADVISE,
POSTCOPY_INCOMING_DISCARD,
POSTCOPY_INCOMING_LISTENING,
POSTCOPY_INCOMING_RUNNING,
POSTCOPY_INCOMING_END
} PostcopyState;
In the case where ram_load is executed and postcopy_state is
POSTCOPY_INCOMING_END, postcopy_running will be set to 'true' and
ram_load will behave like a postcopy is in progress. This scenario isn't
achievable in a migration but it is reproducible when executing
savevm/loadvm after migrating with 'postcopy-ram on', causing loadvm
to fail with Error -22:
Source:
(qemu) migrate_set_capability postcopy-ram on
(qemu) migrate tcp:127.0.0.1:4444
Dest:
(qemu) migrate_set_capability postcopy-ram on
(qemu)
ubuntu1704-intel login:
Ubuntu 17.04 ubuntu1704-intel ttyS0
ubuntu1704-intel login: (qemu)
(qemu) savevm test1
(qemu) loadvm test1
Unknown combination of migration flags: 0x4 (postcopy mode)
error while loading state for instance 0x0 of device 'ram'
Error -22 while loading VM state
(qemu)
This patch fixes this problem by changing the existing logic for
postcopy_advised and postcopy_running in ram_load, making them
'false' if we're at POSTCOPY_INCOMING_END state.
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
CC: Juan Quintela <quintela@redhat.com>
CC: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
---
migration/ram.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 8620aa400a..021d583b9b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2798,6 +2798,18 @@ static int ram_load_postcopy(QEMUFile *f)
return ret;
}
+static bool postcopy_is_advised(void)
+{
+ PostcopyState ps = postcopy_state_get();
+ return ps >= POSTCOPY_INCOMING_ADVISE && ps < POSTCOPY_INCOMING_END;
+}
+
+static bool postcopy_is_running(void)
+{
+ PostcopyState ps = postcopy_state_get();
+ return ps >= POSTCOPY_INCOMING_LISTENING && ps < POSTCOPY_INCOMING_END;
+}
+
static int ram_load(QEMUFile *f, void *opaque, int version_id)
{
int flags = 0, ret = 0, invalid_flags = 0;
@@ -2807,9 +2819,9 @@ static int ram_load(QEMUFile *f, void *opaque, int version_id)
* If system is running in postcopy mode, page inserts to host memory must
* be atomic
*/
- bool postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING;
+ bool postcopy_running = postcopy_is_running();
/* ADVISE is earlier, it shows the source has the postcopy capability on */
- bool postcopy_advised = postcopy_state_get() >= POSTCOPY_INCOMING_ADVISE;
+ bool postcopy_advised = postcopy_is_advised();
seq_iter++;
--
2.13.6
next prev parent reply other threads:[~2017-11-16 22:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 22:35 [Qemu-devel] [PATCH v3 0/2] Fix savevm/loadvm after postcopy migration Daniel Henrique Barboza
2017-11-16 22:35 ` Daniel Henrique Barboza [this message]
2017-11-16 22:35 ` [Qemu-devel] [PATCH v3 2/2] tests/qemu-iotests: adding savevm/loadvm with postcopy flag test Daniel Henrique Barboza
2017-11-17 13:24 ` Cleber Rosa
2017-11-17 13:41 ` Daniel Henrique Barboza
2017-12-01 20:13 ` Max Reitz
2017-12-03 20:13 ` Daniel Henrique Barboza
2017-12-04 14:50 ` Max Reitz
2017-12-04 15:01 ` Daniel Henrique Barboza
2017-12-04 15:06 ` Max Reitz
2017-12-04 15:15 ` Daniel Henrique Barboza
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=20171116223527.4499-2-danielhb@linux.vnet.ibm.com \
--to=danielhb@linux.vnet.ibm.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--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).