@@ -1504,6 +1504,18 @@
##
{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
+##
+# @start-migration-handler:
+#
+# Start the mirror vcpu which runs the in-guest migration handler.
+#
+# Returns: nothing on success
+#
+# Since: 6.2
+#
+##
+{ 'command': 'start-migration-handler' }
+
##
# @xen-save-devices-state:
#
@@ -60,6 +60,7 @@
#include "qemu/yank.h"
#include "sysemu/cpus.h"
#include "yank_functions.h"
+#include "confidential-ram.h"
#define MAX_THROTTLE (128 << 20) /* Migration transfer speed throttling */
@@ -2161,6 +2162,17 @@ void qmp_migrate_incoming(const char *uri, Error **errp)
once = false;
}
+void qmp_start_migration_handler(Error **errp)
+{
+ CPUState *cpu;
+ CPU_FOREACH(cpu) {
+ if (cpu->mirror_vcpu) {
+ cgs_mh_reset_mirror_vcpu(cpu);
+ cpu_resume(cpu);
+ }
+ }
+}
+
void qmp_migrate_recover(const char *uri, Error **errp)
{
MigrationIncomingState *mis = migration_incoming_get_current();
The start-migration-handler QMP command starts the mirror vcpu directly at the migration handler entry point. This is a temporary workaround to start-up (resume) the mirror vcpu which runs the in-guest migration handler (both on the source and the target). A proper solution would be to start it automatically when the 'migrate' and 'migrate-incoming' QMP commands are executed. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> --- qapi/migration.json | 12 ++++++++++++ migration/migration.c | 12 ++++++++++++ 2 files changed, 24 insertions(+)