pv event interface between host and guest

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

Quoted 3 lines · Hu Tao

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

What happens if a management app wants to override the runstate when restoring the domain? I can think of several useful scenarios:

1. management app pauses the guest, then saves domain state and other things (management state, or disk clones), then resumes the guest. Later, the management wants to revert to the saved state, but have the guest running right away. I guess here, knowing that the guest was saved in a paused state doesn't hurt, since the management app can resume it right away.

2. management app saves domain state of a live guest, then copies that state elsewhere. In its new location, the management app wants to investigate the state for forensic analysis - so even though the guest remembers that it was running, management wants to start it paused. Here, it is important that there must not be a window of time where the guest can run, otherwise, the results are not reproducible.

Quoted 15 lines · Eric Blake

Quoted 3 lines · Hu Tao

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

What happens if a management app wants to override the runstate when restoring the domain? I can think of several useful scenarios:

1. management app pauses the guest, then saves domain state and other things (management state, or disk clones), then resumes the guest. Later, the management wants to revert to the saved state, but have the guest running right away. I guess here, knowing that the guest was saved in a paused state doesn't hurt, since the management app can resume it right away.

Quoted 6 lines

2. management app saves domain state of a live guest, then copies that state elsewhere. In its new location, the management app wants to investigate the state for forensic analysis - so even though the guest remembers that it was running, management wants to start it paused. Here, it is important that there must not be a window of time where the guest can run, otherwise, the results are not reproducible.

-S takes precedence in the case. But for in-migration, runstate is loaded from src.

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

See following example:

# save two vms: one is running, the other is paused
(qemu) info status
VM status: running
(qemu) savevm running
(qemu) stop
(qemu) info status
VM status: paused
(qemu) savevm paused

# restore the one running
(qemu) info status
VM status: paused
(qemu) loadvm running
(qemu) info status
VM status: running

# restore the one paused
(qemu) loadvm paused
(qemu) info status
VM status: paused
(qemu) cont
(qemu)info status
VM status: running

Signed-off-by Hu Tao <[email protected]>

---
 include/sysemu/sysemu.h |  2 ++
 migration.c             |  6 +-----
 monitor.c               |  5 ++---
 savevm.c                |  1 +
 vl.c                    | 34 ++++++++++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 8 deletions(-)

include/sysemu/sysemu.h +2 -0

index b19ec95..f121213 100644
@@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
 int qemu_uuid_parse(const char *str, uint8_t *uuid);
 #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
 
+void save_run_state(void);
+void load_run_state(void);
 bool runstate_check(RunState state);
 void runstate_set(RunState new_state);
 int runstate_is_running(void);

migration.c +1 -5

index 11725ae..c29830e 100644
@@ -107,11 +107,7 @@ static void process_incoming_migration_co(void *opaque)
     /* Make sure all file formats flush their mutable metadata */
     bdrv_invalidate_cache_all();
 
-    if (autostart) {
-        vm_start();
-    } else {
-        runstate_set(RUN_STATE_PAUSED);
-    }
+    load_run_state();
 }
 
 void process_incoming_migration(QEMUFile *f)

monitor.c +2 -3

index 32a6e74..bf974b4 100644
@@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
 
 static void do_loadvm(Monitor *mon, const QDict *qdict)
 {
-    int saved_vm_running  = runstate_is_running();
     const char *name = qdict_get_str(qdict, "name");
 
     vm_stop(RUN_STATE_RESTORE_VM);
 
-    if (load_vmstate(name) == 0 && saved_vm_running) {
-        vm_start();
+    if (load_vmstate(name) == 0) {
+        load_run_state();
     }
 }
 

savevm.c +1 -0

index a8a53ef..aa631eb 100644
@@ -2143,6 +2143,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
     }
 
     saved_vm_running = runstate_is_running();
+    save_run_state();
     vm_stop(RUN_STATE_SAVE_VM);
 
     memset(sn, 0, sizeof(*sn));

vl.c +34 -0

index febd2ea..7991f2e 100644
@@ -523,6 +523,7 @@ static int default_driver_check(QemuOpts *opts, void *opaque)
 /* QEMU state */
 
 static RunState current_run_state = RUN_STATE_PRELAUNCH;
+static RunState saved_run_state = RUN_STATE_RUNNING;
 
 typedef struct {
     RunState from;

@@ -546,6 +547,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
 
     { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
+    { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
     { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },

@@ -556,6 +558,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
     { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
+    { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
 
     { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
     { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },

@@ -585,11 +588,39 @@ static const RunStateTransition runstate_transitions_def[] = {
 
 static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
 
+void save_run_state(void)
+{
+    saved_run_state = current_run_state;
+}
+
+void load_run_state(void)
+{
+    if (saved_run_state == RUN_STATE_RUNNING) {
+        vm_start();
+    } else if (!runstate_check(saved_run_state)) {
+        runstate_set(saved_run_state);
+    } else {
+        ; /* leave unchanged */
+    }
+}
+
 bool runstate_check(RunState state)
 {
     return current_run_state == state;
 }
 
+static void runstate_save(QEMUFile *f, void *opaque)
+{
+    qemu_put_byte(f, saved_run_state);
+}
+
+static int runstate_load(QEMUFile *f, void *opaque, int version_id)
+{
+    saved_run_state = qemu_get_byte(f);
+
+    return 0;
+}
+
 static void runstate_init(void)
 {
     const RunStateTransition *p;

@@ -599,6 +630,9 @@ static void runstate_init(void)
     for (p = &runstate_transitions_def[0]; p->from != RUN_STATE_MAX; p++) {
         runstate_valid_transitions[p->from][p->to] = true;
     }
+
+    register_savevm(NULL, "runstate", 0, 1,
+                    runstate_save, runstate_load, NULL);
 }
 
 /* This function will abort() on invalid state transitions */

Il 28/02/2013 13:13, Hu Tao ha scritto:

Quoted 3 lines

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

I don't think this feature is worth breaking backwards migration compatibility. It is usually handled at a higher-level (management, like libvirt).

Please make this a separate patch.

Paolo

Quoted 176 lines

See following example:

# save two vms: one is running, the other is paused
(qemu) info status
VM status: running
(qemu) savevm running
(qemu) stop
(qemu) info status
VM status: paused
(qemu) savevm paused

# restore the one running
(qemu) info status
VM status: paused
(qemu) loadvm running
(qemu) info status
VM status: running

# restore the one paused
(qemu) loadvm paused
(qemu) info status
VM status: paused
(qemu) cont
(qemu)info status
VM status: running

Signed-off-by Hu Tao <[email protected]>

---
 include/sysemu/sysemu.h |  2 ++
 migration.c             |  6 +-----
 monitor.c               |  5 ++---
 savevm.c                |  1 +
 vl.c                    | 34 ++++++++++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 8 deletions(-)

include/sysemu/sysemu.h +2 -0

index b19ec95..f121213 100644
@@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
 int qemu_uuid_parse(const char *str, uint8_t *uuid);
 #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
 
+void save_run_state(void);
+void load_run_state(void);
 bool runstate_check(RunState state);
 void runstate_set(RunState new_state);
 int runstate_is_running(void);

migration.c +1 -5

index 11725ae..c29830e 100644
@@ -107,11 +107,7 @@ static void process_incoming_migration_co(void *opaque)
     /* Make sure all file formats flush their mutable metadata */
     bdrv_invalidate_cache_all();
 
-    if (autostart) {
-        vm_start();
-    } else {
-        runstate_set(RUN_STATE_PAUSED);
-    }
+    load_run_state();
 }
 
 void process_incoming_migration(QEMUFile *f)

monitor.c +2 -3

index 32a6e74..bf974b4 100644
@@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
 
 static void do_loadvm(Monitor *mon, const QDict *qdict)
 {
-    int saved_vm_running  = runstate_is_running();
     const char *name = qdict_get_str(qdict, "name");
 
     vm_stop(RUN_STATE_RESTORE_VM);
 
-    if (load_vmstate(name) == 0 && saved_vm_running) {
-        vm_start();
+    if (load_vmstate(name) == 0) {
+        load_run_state();
     }
 }
 

savevm.c +1 -0

index a8a53ef..aa631eb 100644
@@ -2143,6 +2143,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
     }
 
     saved_vm_running = runstate_is_running();
+    save_run_state();
     vm_stop(RUN_STATE_SAVE_VM);
 
     memset(sn, 0, sizeof(*sn));

vl.c +34 -0

index febd2ea..7991f2e 100644
@@ -523,6 +523,7 @@ static int default_driver_check(QemuOpts *opts, void *opaque)
 /* QEMU state */
 
 static RunState current_run_state = RUN_STATE_PRELAUNCH;
+static RunState saved_run_state = RUN_STATE_RUNNING;
 
 typedef struct {
     RunState from;

@@ -546,6 +547,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
 
     { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
+    { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
     { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },

@@ -556,6 +558,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
     { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
+    { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
 
     { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
     { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },

@@ -585,11 +588,39 @@ static const RunStateTransition runstate_transitions_def[] = {
 
 static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
 
+void save_run_state(void)
+{
+    saved_run_state = current_run_state;
+}
+
+void load_run_state(void)
+{
+    if (saved_run_state == RUN_STATE_RUNNING) {
+        vm_start();
+    } else if (!runstate_check(saved_run_state)) {
+        runstate_set(saved_run_state);
+    } else {
+        ; /* leave unchanged */
+    }
+}
+
 bool runstate_check(RunState state)
 {
     return current_run_state == state;
 }
 
+static void runstate_save(QEMUFile *f, void *opaque)
+{
+    qemu_put_byte(f, saved_run_state);
+}
+
+static int runstate_load(QEMUFile *f, void *opaque, int version_id)
+{
+    saved_run_state = qemu_get_byte(f);
+
+    return 0;
+}
+
 static void runstate_init(void)
 {
     const RunStateTransition *p;

@@ -599,6 +630,9 @@ static void runstate_init(void)
     for (p = &runstate_transitions_def[0]; p->from != RUN_STATE_MAX; p++) {
         runstate_valid_transitions[p->from][p->to] = true;
     }
+
+    register_savevm(NULL, "runstate", 0, 1,
+                    runstate_save, runstate_load, NULL);
 }
 
 /* This function will abort() on invalid state transitions */

Quoted 5 lines

Il 28/02/2013 13:13, Hu Tao ha scritto:

Quoted 3 lines

This patch enables preservation of cpu runstate during save/load vm. So when a vm is restored from snapshot, the cpu runstate is restored, too.

Quoted 3 lines

I don't think this feature is worth breaking backwards migration compatibility. It is usually handled at a higher-level (management, like libvirt).

If guest panic happens during migration, runstate will still be running on destination host without this patch. But, it does be a problem to break backwards migration compatibility.

From: Wen Congyang <[email protected]>

The guest should run after resetting it, but it does not run if its old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.

We don't set runstate to RUN_STATE_PAUSED when resetting the guest, so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).

Quoted 8 lines · Hu Tao

From: Wen Congyang <[email protected]>

The guest should run after resetting it, but it does not run if its old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.

We don't set runstate to RUN_STATE_PAUSED when resetting the guest, so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).

I just wonder what will happen if I interrupted the guest via gdb and then issue "monitor system_reset", also via gdb - common pattern if you set a breakpoint on some BUG() or fault handler and then want to restart the guest. Will the guest continue then while gdb thinks it is still stopped? Likely, we do not differentiate between gdb-initiated stops and the rest. Could you clarify?

From: Wen Congyang <[email protected]>

The guest should run after resetting it, but it does not run if its old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.

We don't set runstate to RUN_STATE_PAUSED when resetting the guest, so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).

Il 28/02/2013 13:13, Hu Tao ha scritto:

Quoted 5 lines

From: Wen Congyang <[email protected]>

The guest should run after resetting it, but it does not run if its old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.

Quoted 3 lines

We don't set runstate to RUN_STATE_PAUSED when resetting the guest, so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).

This is also debatable. In particular, restarting an INTERNAL_ERROR guest makes it harder to inspect the state at the time of the failure.

INTERNAL_ERROR should never happen, let's separate this patch too.

Paolo

The guest will be in this state when it is panicked.

Signed-off-by Wen Congyang <[email protected]>

Signed-off-by Hu Tao <[email protected]>

---
 migration.c      |  1 +
 qapi-schema.json |  6 +++++-
 qmp.c            |  3 ++-
 vl.c             | 11 ++++++++++-
 4 files changed, 18 insertions(+), 3 deletions(-)

migration.c +1 -0

index c29830e..fa17b82 100644
@@ -698,6 +698,7 @@ static void *buffered_file_thread(void *opaque)
                 int64_t start_time, end_time;
 
                 DPRINTF("done iterating\n");
+                save_run_state();
                 start_time = qemu_get_clock_ms(rt_clock);
                 qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
                 if (old_vm_running) {

qapi-schema.json +5 -1

index 28b070f..8f1d138 100644
@@ -174,11 +174,15 @@
 # @suspended: guest is suspended (ACPI S3)
 #
 # @watchdog: the watchdog action is configured to pause and has been triggered
+#
+# @guest-panicked: the panicked action is configured to pause and has been
+# triggered.
 ##
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
+            'guest-panicked' ] }
 
 ##
 # @SnapshotInfo

qmp.c +2 -1

index 5f1bed1..f5027f6 100644
@@ -150,7 +150,8 @@ void qmp_cont(Error **errp)
     Error *local_err = NULL;
 
     if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-               runstate_check(RUN_STATE_SHUTDOWN)) {
+            runstate_check(RUN_STATE_SHUTDOWN) ||
+            runstate_check(RUN_STATE_GUEST_PANICKED)) {
         error_set(errp, QERR_RESET_REQUIRED);
         return;
     } else if (runstate_check(RUN_STATE_SUSPENDED)) {

vl.c +0 -0

index 3d08e1a..51d4922 100644

vl.c +2 -1

     { RUN_STATE_MAX, RUN_STATE_MAX },
 };
 

@@ -2001,7 +2009,8 @@ static bool main_loop_should_exit(void)
         qemu_system_reset(VMRESET_REPORT);
         resume_all_vcpus();
         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-            runstate_check(RUN_STATE_SHUTDOWN)) {
+            runstate_check(RUN_STATE_SHUTDOWN) ||
+            runstate_check(RUN_STATE_GUEST_PANICKED)) {
             bdrv_iterate(iostatus_bdrv_it, NULL);
             vm_start();
         }

Il 28/02/2013 13:13, Hu Tao ha scritto:

Quoted 64 lines

The guest will be in this state when it is panicked.

Signed-off-by Wen Congyang <[email protected]>

Signed-off-by Hu Tao <[email protected]>

---
 migration.c      |  1 +
 qapi-schema.json |  6 +++++-
 qmp.c            |  3 ++-
 vl.c             | 11 ++++++++++-
 4 files changed, 18 insertions(+), 3 deletions(-)

migration.c +1 -0

index c29830e..fa17b82 100644
@@ -698,6 +698,7 @@ static void *buffered_file_thread(void *opaque)
                 int64_t start_time, end_time;
 
                 DPRINTF("done iterating\n");
+                save_run_state();
                 start_time = qemu_get_clock_ms(rt_clock);
                 qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
                 if (old_vm_running) {

qapi-schema.json +5 -1

index 28b070f..8f1d138 100644
@@ -174,11 +174,15 @@
 # @suspended: guest is suspended (ACPI S3)
 #
 # @watchdog: the watchdog action is configured to pause and has been triggered
+#
+# @guest-panicked: the panicked action is configured to pause and has been
+# triggered.
 ##
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
+            'guest-panicked' ] }
 
 ##
 # @SnapshotInfo

qmp.c +2 -1

index 5f1bed1..f5027f6 100644
@@ -150,7 +150,8 @@ void qmp_cont(Error **errp)
     Error *local_err = NULL;
 
     if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-               runstate_check(RUN_STATE_SHUTDOWN)) {
+            runstate_check(RUN_STATE_SHUTDOWN) ||
+            runstate_check(RUN_STATE_GUEST_PANICKED)) {
         error_set(errp, QERR_RESET_REQUIRED);
         return;
     } else if (runstate_check(RUN_STATE_SUSPENDED)) {

vl.c +0 -0

index 3d08e1a..51d4922 100644
@@ -536,6 +536,7 @@ static const RunStateTransition runstate_transitions_def[] = {
 

vl.c static const RunStateTransition runstate_transitions_def[] = { · line 539

Quoted 3 lines

vl.c +1 -0

     { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
+    { RUN_STATE_INMIGRATE, RUN_STATE_GUEST_PANICKED },

Is this a consequence of the first patch?

vl.c static const RunStateTransition runstate_transitions_def[] = { · line 553

Quoted 8 lines

vl.c +1 -0

     { RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
     { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },

@@ -549,6 +550,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
     { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
+    { RUN_STATE_POSTMIGRATE, RUN_STATE_GUEST_PANICKED },

Impossible. GUEST_PANICKED requires an instruction to be executed in the guest, so it should first go to RUNNING.

Quoted 4 lines

vl.c +0 -0

     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
     { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },

@@ -559,6 +561,7 @@ static const RunStateTransition runstate_transitions_def[] = {
 

vl.c static const RunStateTransition runstate_transitions_def[] = { · line 564

Quoted 3 lines

vl.c +1 -0

     { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
     { RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
+    { RUN_STATE_RESTORE_VM, RUN_STATE_GUEST_PANICKED },

Is it also for the first patch?

vl.c static const RunStateTransition runstate_transitions_def[] = { · line 575

Quoted 8 lines

vl.c +1 -0

     { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
     { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },

@@ -569,6 +572,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
     { RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
     { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
+    { RUN_STATE_RUNNING, RUN_STATE_GUEST_PANICKED },

This one is obviously ok.

vl.c static const RunStateTransition runstate_transitions_def[] = { · line 592

Quoted 9 lines

vl.c +3 -0

     { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
 

@@ -583,6 +587,10 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
     { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
 
+    { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING },
+    { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED },
+    { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE },

Like SHUTDOWN, it should go first to PAUSED and then to RUNNING. A GUEST_PANICKED -> RUNNING transition is not possible. You're seeing it because you lack the addition of GUEST_PANICKED here:

        if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
            runstate_check(RUN_STATE_SHUTDOWN)) {
            runstate_set(RUN_STATE_PAUSED);
        }

I think you should first move the INTERNAL_ERROR || SHUTDOWN checks to a separate function, so that you can then add GUEST_PANICKED.

Paolo

Quoted 14 lines

vl.c +2 -1

     { RUN_STATE_MAX, RUN_STATE_MAX },
 };
 

@@ -2001,7 +2009,8 @@ static bool main_loop_should_exit(void)
         qemu_system_reset(VMRESET_REPORT);
         resume_all_vcpus();
         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-            runstate_check(RUN_STATE_SHUTDOWN)) {
+            runstate_check(RUN_STATE_SHUTDOWN) ||
+            runstate_check(RUN_STATE_GUEST_PANICKED)) {
             bdrv_iterate(iostatus_bdrv_it, NULL);
             vm_start();
         }

Will

         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
             runstate_check(RUN_STATE_SHUTDOWN) ||
             runstate_check(RUN_STATE_GUEST_PANICKED)) {
             runstate_set(RUN_STATE_PAUSED);
         }

be OK? Or I must be misunderstanding you.

Il 05/03/2013 04:17, Hu Tao ha scritto:

Quoted 10 lines

Will

         if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
             runstate_check(RUN_STATE_SHUTDOWN) ||
             runstate_check(RUN_STATE_GUEST_PANICKED)) {
             runstate_set(RUN_STATE_PAUSED);
         }

be OK? Or I must be misunderstanding you.

Please move

       return (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
               runstate_check(RUN_STATE_SHUTDOWN) ||
               runstate_check(RUN_STATE_GUEST_PANICKED));

to a separate function (runstate_needs_reset for example), so that you can reuse it in the two or three places that need it.

This event will be emited when the guest is panicked.

Signed-off-by Wen Congyang <[email protected]>

---
 include/monitor/monitor.h | 1 +
 monitor.c                 | 1 +
 2 files changed, 2 insertions(+)

Quoted 7 lines · Hu Tao

This event will be emited when the guest is panicked.

Signed-off-by Wen Congyang <[email protected]>

---
 include/monitor/monitor.h | 1 +
 monitor.c                 | 1 +
 2 files changed, 2 insertions(+)

Missing documentation in QMP/qmp-events.txt

This event will be emited when the guest is panicked.

Signed-off-by Wen Congyang <[email protected]>

---
 include/monitor/monitor.h | 1 +
 monitor.c                 | 1 +
 2 files changed, 2 insertions(+)

include/monitor/monitor.h +1 -0

index 87fb49c..4006905 100644
@@ -45,6 +45,7 @@ typedef enum MonitorEvent {
     QEVENT_WAKEUP,
     QEVENT_BALLOON_CHANGE,
     QEVENT_SPICE_MIGRATE_COMPLETED,
+    QEVENT_GUEST_PANICKED,
 
     /* Add to 'monitor_event_names' array in monitor.c when
      * defining new events here */

monitor.c +0 -0

index bf974b4..d65218d 100644

If the target is x86/x86_64, the guest's kernel will write 0x01 to the port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new qom device kvm_pv_ioport to listen this I/O port, and deal with panicked event according to panicked_action's value. The possible actions are:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause the guest
3. emit QEVENT_GUEST_PANICKED and poweroff the guest
4. emit QEVENT_GUEST_PANICKED and reset the guest

I/O ports does not work for some targets(for example: s390). And you can implement another qom device, and include it's code into pv_event.c for such target.

Note: if we emit QEVENT_GUEST_PANICKED only, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.

Signed-off-by Wen Congyang <[email protected]>

Signed-off-by Hu Tao <[email protected]>

---
 hw/kvm/Makefile.objs |   2 +-
 hw/kvm/pv_event.c    | 198 +++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/pc_piix.c         |   5 ++
 include/sysemu/kvm.h |   2 +
 kvm-stub.c           |   4 ++
 5 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 hw/kvm/pv_event.c

hw/kvm/Makefile.objs +1 -1

index f620d7f..cf93199 100644
@@ -1 +1 @@
-obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o
+obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o pv_event.o

hw/kvm/pv_event.c new file +198 -0

new file mode 100644
index 0000000..5e68190
@@ -0,0 +1,198 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <linux/kvm_para.h>
+#include <asm/kvm_para.h>
+#include <qapi/qmp/qobject.h>
+#include <qapi/qmp/qjson.h>
+#include <monitor/monitor.h>
+#include <sysemu/sysemu.h>
+#include <sysemu/kvm.h>
+
+/* Possible values for action parameter. */
+#define PANICKED_REPORT     1   /* emit QEVENT_GUEST_PANICKED only */
+#define PANICKED_PAUSE      2   /* emit QEVENT_GUEST_PANICKED and pause VM */
+#define PANICKED_POWEROFF   3   /* emit QEVENT_GUEST_PANICKED and quit VM */
+#define PANICKED_RESET      4   /* emit QEVENT_GUEST_PANICKED and reset VM */
+
+#define PV_EVENT_DRIVER     "kvm_pv_event"
+#define PV_IOPORT(obj)      OBJECT_CHECK(PVIOPortState, (obj), PV_EVENT_DRIVER)
+
+struct PVEventAction {
+    char *panicked_action;
+    int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
+    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+static void panicked_mon_event(const char *action)
+{
+    QObject *data;
+
+    data = qobject_from_jsonf("{ 'action': %s }", action);
+    monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
+    qobject_decref(data);
+}
+
+static void panicked_perform_action(uint32_t panicked_action)
+{
+    switch (panicked_action) {
+    case PANICKED_REPORT:
+        panicked_mon_event("report");
+        break;
+
+    case PANICKED_PAUSE:
+        panicked_mon_event("pause");
+        vm_stop(RUN_STATE_GUEST_PANICKED);
+        break;
+
+    case PANICKED_POWEROFF:
+        panicked_mon_event("poweroff");
+        qemu_system_shutdown_request();
+        break;
+
+    case PANICKED_RESET:
+        panicked_mon_event("reset");
+        qemu_system_reset_request();
+        break;
+    }
+}
+
+static uint64_t supported_event(void)
+{
+    return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct PVEventAction *conf)
+{
+    if (event == KVM_PV_EVENT_PANICKED) {
+        panicked_perform_action(conf->panicked_action_value);
+    }
+}
+
+static int pv_event_init(struct PVEventAction *conf)
+{
+    if (!conf->panicked_action) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+        conf->panicked_action_value = PANICKED_PAUSE;
+    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+        conf->panicked_action_value = PANICKED_POWEROFF;
+    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+        conf->panicked_action_value = PANICKED_RESET;
+    } else {
+        return -1;
+    }
+
+    return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "hw/isa.h"
+
+typedef struct {
+    ISADevice dev;
+    struct PVEventAction conf;
+    MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, hwaddr addr, unsigned size)
+{
+    return supported_event();
+}
+
+static void pv_io_write(void *opaque, hwaddr addr, uint64_t val,
+                        unsigned size)
+{
+    PVIOPortState *s = opaque;
+
+    handle_event(val, &s->conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+    .read = pv_io_read,
+    .write = pv_io_write,
+    .impl = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+};
+
+static int pv_ioport_initfn(ISADevice *dev)
+{
+    PVIOPortState *s = PV_IOPORT(dev);
+
+    if (pv_event_init(&s->conf) < 0) {
+        return -1;
+    }
+
+    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 4);
+    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
+
+    return 0;
+}
+
+static Property pv_ioport_properties[] = {
+    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pv_ioport_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+
+    ic->init = pv_ioport_initfn;
+    dc->no_user = 1;
+    dc->props = pv_ioport_properties;
+}
+
+static TypeInfo pv_ioport_info = {
+    .name          = PV_EVENT_DRIVER,
+    .parent        = TYPE_ISA_DEVICE,
+    .instance_size = sizeof(PVIOPortState),
+    .class_init    = pv_ioport_class_init,
+};
+
+static void pv_ioport_register_types(void)
+{
+    type_register_static(&pv_ioport_info);
+}
+
+type_init(pv_ioport_register_types)
+
+void kvm_pv_event_init(void *opaque)
+{
+    ISABus *bus = opaque;
+    ISADevice *dev;
+
+    dev = isa_create(bus, PV_EVENT_DRIVER);
+    qdev_init_nofail(&dev->qdev);
+}
+
+#else
+
+/*
+ * If you need a qom device to handle pv event, this device should
+ * be created and initialized in kvm_pv_event_init().
+ *
+ * The parameter opaque is the device's parent bus.
+ */
+void kvm_pv_event_init(void *opaque)
+{
+}
+#endif

hw/pc_piix.c +5 -0

index aa9cc81..24a9bf3 100644
@@ -47,6 +47,7 @@
 #ifdef CONFIG_XEN
 #  include <xen/hvm/hvm_info_table.h>
 #endif
+#include <linux/kvm_para.h>
 
 #define MAX_IDE_BUS 2
 

@@ -216,6 +217,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pc_pci_device_init(pci_bus);
     }
+
+    if (kvm_enabled()) {
+        kvm_pv_event_init(isa_bus);
+    }
 }
 
 static void pc_init_pci(QEMUMachineInitArgs *args)

include/sysemu/kvm.h +2 -0

index f2d97b5..97d3daf 100644
@@ -296,4 +296,6 @@ int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
 int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
 void kvm_pc_gsi_handler(void *opaque, int n, int level);
 void kvm_pc_setup_irq_routing(bool pci_enabled);
+
+void kvm_pv_event_init(void *opaque);
 #endif

kvm-stub.c +4 -0

index 760aadc..f543fa2 100644
@@ -145,3 +145,7 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq)
 {
     return -ENOSYS;
 }
+
+void kvm_pv_event_init(void *opaque)
+{
+}

If the target is x86/x86_64, the guest's kernel will write 0x01 to the port KVM_PV_EVENT_PORT when it is panciked. This patch introduces a new qom device kvm_pv_ioport to listen this I/O port, and deal with panicked event according to panicked_action's value. The possible actions are:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause the guest
3. emit QEVENT_GUEST_PANICKED and poweroff the guest
4. emit QEVENT_GUEST_PANICKED and reset the guest

I/O ports does not work for some targets(for example: s390). And you can implement another qom device, and include it's code into pv_event.c for such target.

Note: if we emit QEVENT_GUEST_PANICKED only, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.

Signed-off-by Wen Congyang <[email protected]>

Signed-off-by Hu Tao <[email protected]>

---
 hw/kvm/Makefile.objs |   2 +-
 hw/kvm/pv_event.c    | 198 +++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/pc_piix.c         |   5 ++
 include/sysemu/kvm.h |   2 +
 kvm-stub.c           |   4 ++
 5 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 hw/kvm/pv_event.c

hw/kvm/Makefile.objs +1 -1

index f620d7f..cf93199 100644
@@ -1 +1 @@
-obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o
+obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pci-assign.o pv_event.o

hw/kvm/pv_event.c new file +198 -0

new file mode 100644
index 0000000..5e68190
@@ -0,0 +1,198 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include <linux/kvm_para.h>
+#include <asm/kvm_para.h>
+#include <qapi/qmp/qobject.h>
+#include <qapi/qmp/qjson.h>
+#include <monitor/monitor.h>
+#include <sysemu/sysemu.h>
+#include <sysemu/kvm.h>
+
+/* Possible values for action parameter. */
+#define PANICKED_REPORT     1   /* emit QEVENT_GUEST_PANICKED only */
+#define PANICKED_PAUSE      2   /* emit QEVENT_GUEST_PANICKED and pause VM */
+#define PANICKED_POWEROFF   3   /* emit QEVENT_GUEST_PANICKED and quit VM */
+#define PANICKED_RESET      4   /* emit QEVENT_GUEST_PANICKED and reset VM */
+
+#define PV_EVENT_DRIVER     "kvm_pv_event"
+#define PV_IOPORT(obj)      OBJECT_CHECK(PVIOPortState, (obj), PV_EVENT_DRIVER)
+
+struct PVEventAction {
+    char *panicked_action;
+    int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
+    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+static void panicked_mon_event(const char *action)
+{
+    QObject *data;
+
+    data = qobject_from_jsonf("{ 'action': %s }", action);
+    monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
+    qobject_decref(data);
+}
+
+static void panicked_perform_action(uint32_t panicked_action)
+{
+    switch (panicked_action) {
+    case PANICKED_REPORT:
+        panicked_mon_event("report");
+        break;
+
+    case PANICKED_PAUSE:
+        panicked_mon_event("pause");
+        vm_stop(RUN_STATE_GUEST_PANICKED);
+        break;
+
+    case PANICKED_POWEROFF:
+        panicked_mon_event("poweroff");
+        qemu_system_shutdown_request();
+        break;
+
+    case PANICKED_RESET:
+        panicked_mon_event("reset");
+        qemu_system_reset_request();
+        break;
+    }
+}
+
+static uint64_t supported_event(void)
+{
+    return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct PVEventAction *conf)
+{
+    if (event == KVM_PV_EVENT_PANICKED) {
+        panicked_perform_action(conf->panicked_action_value);
+    }
+}
+
+static int pv_event_init(struct PVEventAction *conf)
+{
+    if (!conf->panicked_action) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+        conf->panicked_action_value = PANICKED_PAUSE;
+    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+        conf->panicked_action_value = PANICKED_POWEROFF;
+    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+        conf->panicked_action_value = PANICKED_RESET;
+    } else {
+        return -1;
+    }
+
+    return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "hw/isa.h"
+
+typedef struct {
+    ISADevice dev;
+    struct PVEventAction conf;
+    MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, hwaddr addr, unsigned size)
+{
+    return supported_event();
+}
+
+static void pv_io_write(void *opaque, hwaddr addr, uint64_t val,
+                        unsigned size)
+{
+    PVIOPortState *s = opaque;
+
+    handle_event(val, &s->conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+    .read = pv_io_read,
+    .write = pv_io_write,
+    .impl = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+};
+
+static int pv_ioport_initfn(ISADevice *dev)
+{
+    PVIOPortState *s = PV_IOPORT(dev);
+
+    if (pv_event_init(&s->conf) < 0) {
+        return -1;
+    }
+
+    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 4);
+    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
+
+    return 0;
+}
+
+static Property pv_ioport_properties[] = {
+    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pv_ioport_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+
+    ic->init = pv_ioport_initfn;
+    dc->no_user = 1;
+    dc->props = pv_ioport_properties;
+}
+
+static TypeInfo pv_ioport_info = {
+    .name          = PV_EVENT_DRIVER,
+    .parent        = TYPE_ISA_DEVICE,
+    .instance_size = sizeof(PVIOPortState),
+    .class_init    = pv_ioport_class_init,
+};
+
+static void pv_ioport_register_types(void)
+{
+    type_register_static(&pv_ioport_info);
+}
+
+type_init(pv_ioport_register_types)
+
+void kvm_pv_event_init(void *opaque)
+{
+    ISABus *bus = opaque;
+    ISADevice *dev;
+
+    dev = isa_create(bus, PV_EVENT_DRIVER);
+    qdev_init_nofail(&dev->qdev);
+}
+
+#else
+
+/*
+ * If you need a qom device to handle pv event, this device should
+ * be created and initialized in kvm_pv_event_init().
+ *
+ * The parameter opaque is the device's parent bus.
+ */
+void kvm_pv_event_init(void *opaque)
+{
+}
+#endif

hw/pc_piix.c +5 -0

index aa9cc81..24a9bf3 100644
@@ -47,6 +47,7 @@
 #ifdef CONFIG_XEN
 #  include <xen/hvm/hvm_info_table.h>
 #endif
+#include <linux/kvm_para.h>
 
 #define MAX_IDE_BUS 2
 

@@ -216,6 +217,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pc_pci_device_init(pci_bus);
     }
+
+    if (kvm_enabled()) {
+        kvm_pv_event_init(isa_bus);
+    }
 }
 
 static void pc_init_pci(QEMUMachineInitArgs *args)

include/sysemu/kvm.h +2 -0

index f2d97b5..97d3daf 100644
@@ -296,4 +296,6 @@ int kvm_irqchip_add_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
 int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq);
 void kvm_pc_gsi_handler(void *opaque, int n, int level);
 void kvm_pc_setup_irq_routing(bool pci_enabled);
+
+void kvm_pv_event_init(void *opaque);
 #endif

kvm-stub.c +4 -0

index 760aadc..f543fa2 100644
@@ -145,3 +145,7 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s, EventNotifier *n, int virq)
 {
     return -ENOSYS;
 }
+
+void kvm_pv_event_init(void *opaque)
+{
+}

target-s390x/kvm.c +5 -0

+            //disabled wait: we either
+            //do a
+            //monitor_protocol_event(QEVENT_GUEST_PANICKED, whatever);
+            //or
+            //or call into pvevent
             r = EXCP_HALTED;
             break;
         case ICPT_CPU_STOP:

I would prefer to just use the monitor_protocol_event, on the other hand a call into pvent could make it configurable.

Signed-off-by Wen Congyang <[email protected]>

Signed-off-by Hu Tao <[email protected]>

---
 hw/pc_piix.c    | 9 ++++++++-
 qemu-options.hx | 3 ++-
 vl.c            | 4 ++++
 3 files changed, 14 insertions(+), 2 deletions(-)

hw/pc_piix.c +8 -1

index 24a9bf3..82a421a 100644
@@ -44,6 +44,7 @@
 #include "exec/memory.h"
 #include "exec/address-spaces.h"
 #include "cpu.h"
+#include "qemu/config-file.h"
 #ifdef CONFIG_XEN
 #  include <xen/hvm/hvm_info_table.h>
 #endif

@@ -86,6 +87,8 @@ static void pc_init1(MemoryRegion *system_memory,
     MemoryRegion *pci_memory;
     MemoryRegion *rom_memory;
     void *fw_cfg = NULL;
+    QemuOptsList *list = qemu_find_opts("machine");
+    bool enable_pv_event = false;
 
     pc_cpus_init(cpu_model);
     pc_acpi_init("acpi-dsdt.aml");

@@ -218,7 +221,11 @@ static void pc_init1(MemoryRegion *system_memory,
         pc_pci_device_init(pci_bus);
     }
 
-    if (kvm_enabled()) {
+    if (list && !QTAILQ_EMPTY(&list->head)) {
+        enable_pv_event = qemu_opt_get_bool(QTAILQ_FIRST(&list->head),
+                                            "enable_pv_event", false);
+    }
+    if (kvm_enabled() && enable_pv_event) {
         kvm_pv_event_init(isa_bus);
     }
 }

qemu-options.hx +2 -1

index 797d992..1ad4041 100644
@@ -35,7 +35,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
     "                kernel_irqchip=on|off controls accelerated irqchip support\n"
     "                kvm_shadow_mem=size of KVM shadow MMU\n"
     "                dump-guest-core=on|off include guest memory in a core dump (default=on)\n"
-    "                mem-merge=on|off controls memory merge support (default: on)\n",
+    "                mem-merge=on|off controls memory merge support (default: on)\n"
+    "                enable_pv_event=on|off controls pv event support (default: off)\n",
     QEMU_ARCH_ALL)
 STEXI
 @item -machine [type=]@var{name}[,prop=@var{value}[,...]]

vl.c +4 -0

index 51d4922..5b3a279 100644
@@ -427,6 +427,10 @@ static QemuOptsList qemu_machine_opts = {
             .name = "usb",
             .type = QEMU_OPT_BOOL,
             .help = "Set on/off to enable/disable usb",
+        }, {
+            .name = "enable_pv_event",
+            .type = QEMU_OPT_BOOL,
+            .help = "handle pv event"
         },
         { /* End of list */ }
     },

This series implements a new interface, kvm pv event, to notify host when some events happen in guest. Right now there is one supported event: guest panic.

Quoted 4 lines

This series implements a new interface, kvm pv event, to notify host when some events happen in guest. Right now there is one supported event: guest panic.

What other event do you have in mind? Is interface generic enough to accommodate future, yet unknown, events. It allows to pass only one integer specifying even type, what if additional info is needed? My be stop pretending that device is generic and make it do once thing but do it well? For generic even passing interface (whatever it may be needed for) much more powerful virtio should be used.

On implementation itself I do not understand why is this kvm specific. The only thing that makes it so is that you hook device initialization into guest kvm initialization code, but this is obviously incorrect. What stops QEMU tcg or Xen from reusing the same device for the same purpose except the artificial limitation in a guest.

Reading data from a random ioports is not how you discover platform devices in 21 century (and the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version), you use ACPI for that and Marcelo already pointed that to you. Having little knowledge of ACPI (we all do) is not a good reason to not doing it. We probably need to reserve QEMU specific ACPI Plug and Play hardware ID to define our own devices. After that you will be able to create device with _HID(QEMU0001) in DSDT that supplies address information (ioport to use) and capability supported.

Guest uses acpi_get_devices() to discover a platform device by its name (QEMU0001). Then you put the driver for the platform device into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

On QEMU side of things I cannot comment much on how QOMified the device is (it should be),

I hope other reviews will verify it, but I noticed that device is only initialized for PIIX, what about Q35?

Quoted 3 lines

Guest uses acpi_get_devices() to discover a platform device by its name (QEMU0001). Then you put the driver for the platform device into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

Just to clarify it for Hu Tao, the read from a random ioport is how the ACPI code will detect presence of the device.

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

        Name(_CRS, ResourceTemplate() {
            IO(Decode16, 0x505, 0x505, 0x01, 0x01)
        })
    }

Please test this with a QEMU option like "-M pc-1.4". The device should _not_ be detected if you're doing it right.

Quoted 3 lines

Quoted 3 lines

Just to clarify it for Hu Tao, the read from a random ioport is how the ACPI code will detect presence of the device.

Actually no (at least in the long run, for the first version it may be OK).

Since we want to move DSDT generation into QEMU if device will not be present QEMU will not generate corresponded Device() in DSDT, or it will generate it with _STA() { Return (0x00)} hard coded.

Seabios can do
the same if we will pass it info about device presence via fw_cfg.

Il 04/03/2013 11:21, Gleb Natapov ha scritto:

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

Just to clarify it for Hu Tao, the read from a random ioport is how the ACPI code will detect presence of the device.

Actually no (at least in the long run, for the first version it may be OK).

Agreed.

Quoted 3 lines

Since we want to move DSDT generation into QEMU if device will not be present QEMU will not generate corresponded Device() in DSDT, or it will generate it with _STA() { Return (0x00)} hard coded.

Yes, this would be good.

Quoted 2 lines

Seabios can do
the same if we will pass it info about device presence via fw_cfg.

True, but I don't like this a lot. I don't like splitting decisions between SeaBIOS and the DSDT, you end up touching code all over the place and writing ASL is simpler than patching---even with all the machinery that we have.

It is also simpler to move ASL from SeaBIOS to
OVMF and/or viceversa. I don't recall what was the opposition to a fw_cfg driver directly in the DSDT, but I think this would be a good usage for it.

Splitting it between QEMU and DSDT is a bit better, since you have to touch QEMU anyway to implement the feature.

Anyhow, this does not apply to the next submission of this series. I think we can agree to the compromise of using ACPI but still read the port in _STA.

Quoted 3 lines

Anyhow, this does not apply to the next submission of this series. I think we can agree to the compromise of using ACPI but still read the port in _STA.

If you want to make ioport configurable I do not see how can we avoid patching.

Il 04/03/2013 11:43, Gleb Natapov ha scritto:

Quoted 6 lines

Quoted 3 lines

Anyhow, this does not apply to the next submission of this series. I think we can agree to the compromise of using ACPI but still read the port in _STA.

If you want to make ioport configurable I do not see how can we avoid patching.

I want to make the ioport configurable in the device, but the PIIX and ICH9 (which are what the DSDT is written for) will always use port 0x505.

You can configure a different iobase for your serial ports, the guest can still use them but not discover them via ACPI. This is the same thing.

Quoted 2 lines

I want to make the ioport configurable in the device, but the PIIX and ICH9 (which are what the DSDT is written for) will always use port 0x505.

But the device is not part of PIIX or ICH9.

It is additional device that
may or may not be present depending on a command line. So what if someone configures debugcon or debugexit to use this port?

We can always
blame the users, but I fill that we are making unnecessary compromises.

Quoted 2 lines

You can configure a different iobase for your serial ports, the guest can still use them but not discover them via ACPI. This is the same thing.

Probably we should patch DSDT too when it will be in QEMU :) of force iobase to spec values if device is used as part of a chipset.

Il 04/03/2013 11:59, Gleb Natapov ha scritto:

Quoted 4 lines

Quoted 2 lines

I want to make the ioport configurable in the device, but the PIIX and ICH9 (which are what the DSDT is written for) will always use port 0x505.

But the device is not part of PIIX or ICH9.

So is kvmclock, or kvmvapic. I think it makes sense to add this device to PIIX or ICH9 since it is an ISA device.

Quoted 3 lines

It is additional device that
may or may not be present depending on a command line. So what if someone configures debugcon or debugexit to use this port?

I haven't checked if debug{con,exit} will pass the _STA test, but if they do, the user will get a Ctrl-A or respectively an exit of QEMU when the guest panics.

What if someone configures debugcon on port 0x3f8? Some guest will use it, some will not.

Quoted 2 lines

We can always
blame the users, but I fill that we are making unnecessary compromises.

Once we choose an ISA device, where the user has full control of the address space, we already know we'll have to accept compromises. I don't think this compromise is particularly bad: do discovery via ACPI (nice), accept that the user can trick the AML (ugly).

Quoted 8 lines

Quoted 3 lines

It is additional device that
may or may not be present depending on a command line. So what if someone configures debugcon or debugexit to use this port?

I haven't checked if debug{con,exit} will pass the _STA test, but if they do, the user will get a Ctrl-A or respectively an exit of QEMU when the guest panics.

Quoted 3 lines

What if someone configures debugcon on port 0x3f8? Some guest will use it, some will not.

Qemu should fail to start since conflict will be detected during initialization.

Quoted 7 lines

Quoted 2 lines

We can always
blame the users, but I fill that we are making unnecessary compromises.

Once we choose an ISA device, where the user has full control of the address space, we already know we'll have to accept compromises. I don't think this compromise is particularly bad: do discovery via ACPI (nice), accept that the user can trick the AML (ugly).

Why would have we accept compromises, we may, but I disagree that it is necessary? If user configures conflicting ports QEMU will detect it during init, if configuration is correct DSDT should provide enough information for guests to use configured devices.

--
Gleb.

Il 04/03/2013 12:20, Gleb Natapov ha scritto:

Quoted 9 lines · Paolo Bonzini

Quoted 8 lines

Quoted 3 lines

It is additional device that
may or may not be present depending on a command line. So what if someone configures debugcon or debugexit to use this port?

I haven't checked if debug{con,exit} will pass the _STA test, but if they do, the user will get a Ctrl-A or respectively an exit of QEMU when the guest panics.

Quoted 5 lines

Quoted 3 lines

What if someone configures debugcon on port 0x3f8? Some guest will use it, some will not.

Qemu should fail to start since conflict will be detected during initialization.

Not if you _remove_ the serial port and place debugcon at 0x3f8.

Same here, you can remove the panic event port and add debugcon at 0x505. That's the problematic case. But if the user goes to that length, I think we can honestly say we don't care.

Quoted 3 lines

Same here, you can remove the panic event port and add debugcon at 0x505. That's the problematic case. But if the user goes to that length, I think we can honestly say we don't care.

IMO there is a big difference between well know serial ISA ports and PIO ports we allocate for our devices. Later have to be discoverable without resorting to probing. On CPU level we do the same with CPUID bits instead of relaying on MSRs #GP. On KVM API level we do the same with capabilities instead of relying on ioctls returning errors. This is not different.

Il 03/03/2013 10:17, Gleb Natapov ha scritto:

Quoted 12 lines · Hu Tao

Quoted 4 lines

This series implements a new interface, kvm pv event, to notify host when some events happen in guest. Right now there is one supported event: guest panic.

What other event do you have in mind? Is interface generic enough to accommodate future, yet unknown, events. It allows to pass only one integer specifying even type, what if additional info is needed? My be stop pretending that device is generic and make it do once thing but do it well? For generic even passing interface (whatever it may be needed for) much more powerful virtio should be used.

Quoted 5 lines

On implementation itself I do not understand why is this kvm specific. The only thing that makes it so is that you hook device initialization into guest kvm initialization code, but this is obviously incorrect. What stops QEMU tcg or Xen from reusing the same device for the same purpose except the artificial limitation in a guest.

Agreed.

Quoted 9 lines

Reading data from a random ioports is not how you discover platform devices in 21 century (and the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version), you use ACPI for that and Marcelo already pointed that to you. Having little knowledge of ACPI (we all do) is not a good reason to not doing it. We probably need to reserve QEMU specific ACPI Plug and Play hardware ID to define our own devices. After that you will be able to create device with _HID(QEMU0001) in DSDT that supplies address information (ioport to use) and capability supported.

Please also document this HID in a new file in the QEMU docs/ directory.

Quoted 3 lines

Guest uses acpi_get_devices() to discover a platform device by its name (QEMU0001). Then you put the driver for the platform device into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

Just to clarify it for Hu Tao, the read from a random ioport is how the ACPI code will detect presence of the device.

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

        Name(_CRS, ResourceTemplate() {
            IO(Decode16, 0x505, 0x505, 0x01, 0x01)
        })
    }

Please test this with a QEMU option like "-M pc-1.4". The device should _not_ be detected if you're doing it right.

Quoted 3 lines

On QEMU side of things I cannot comment much on how QOMified the device is (it should be),

Please make the device target-independent. It can be used on non-x86 architectures that have I/O ports. You should make the port configurable using a property (DEFINE_PROPERTY_INT16 or something like that), with a default of 0x505.

All the panicked_action is not necessary in my opinion. We have it for watchdogs, but that's really a legacy thing. Let libvirt do it, and always make the guest panic perform the PANICKED_PAUSE action.

If you do it properly, a lot (really a lot) of code will go away.

Quoted 3 lines

I hope other reviews will verify it, but I noticed that device is only initialized for PIIX, what about Q35?

Yup.

Paolo

Quoted 10 lines

Quoted 10 lines

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

Quoted 8 lines

Quoted 8 lines

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the device is not present. Otherwise, the device is present. But as Gleb said, ''the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version''. What should I do to tell if the device is present or not correctly?

Il 06/03/2013 09:56, Hu Tao ha scritto:

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

Quoted 5 lines

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the device is not present. Otherwise, the device is present. But as Gleb said, ''the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version''. What should I do to tell if the device is present or not correctly?

The firmware is tied to the QEMU version, so you can rely on unassigned ports returning zero.

Later we can change this to use fw-cfg.

Paolo

Il 06/03/2013 09:56, Hu Tao ha scritto:

Quoted 18 lines

Quoted 10 lines

Quoted 10 lines

Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

Quoted 8 lines

Quoted 8 lines

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

Quoted 5 lines

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the device is not present. Otherwise, the device is present. But as Gleb said, ''the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version''. What should I do to tell if the device is present or not correctly?

The firmware is tied to the QEMU version, so you can rely on unassigned ports returning zero.

Later we can change this to use fw-cfg.

Quoted 26 lines

Il 06/03/2013 09:56, Hu Tao ha scritto:

Quoted 24 lines

Quoted 11 lines

Quoted 11 lines

Something like this should work (in SeaBIOS's
src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

Quoted 8 lines

Quoted 8 lines

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the device is not present. Otherwise, the device is present. But as Gleb said, ''the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version''. What should I do to tell if the device is present or not correctly?

Quoted 4 lines

The firmware is tied to the QEMU version, so you can rely on unassigned ports returning zero.

Later we can change this to use fw-cfg.

I thought we agreed to do it from the start :)

Quoted 28 lines · Paolo Bonzini

Quoted 26 lines

Il 06/03/2013 09:56, Hu Tao ha scritto:

Quoted 24 lines

Quoted 11 lines

Quoted 11 lines

Something like this should work (in SeaBIOS's
src/acpi-dsdt-isa.dsl):

    Device(PEVT) {
        Name(_HID, EisaId("QEMU0001"))
        OperationRegion(PEOR, SystemIO, 0x505, 0x01)
        Field(PEOR, ByteAcc, NoLock, Preserve) {
            PEPT,   8,
        }

Quoted 8 lines

Quoted 8 lines

        Method(_STA, 0, NotSerialized) {
            Store(PEPT, Local0)
            If (LEqual(Local0, Zero)) {
                Return (0x00)
            } Else {
                Return (0x0F)
            }
        }

IIUC, here _STA reads from ioport 0x505, if the result is 0, then the device is not present. Otherwise, the device is present. But as Gleb said, ''the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version''. What should I do to tell if the device is present or not correctly?

Quoted 6 lines

Quoted 4 lines

The firmware is tied to the QEMU version, so you can rely on unassigned ports returning zero.

Later we can change this to use fw-cfg.

I thought we agreed to do it from the start :)

Then Hu will need to patch the _STA method.

Quoted 4 lines · Hu Tao

This series implements a new interface, kvm pv event, to notify host when some events happen in guest. Right now there is one supported event: guest panic.

What other event do you have in mind? Is interface generic enough to accommodate future, yet unknown, events. It allows to pass only one integer specifying even type, what if additional info is needed? My be

stop pretending that device is generic and make it do once thing but do

it well? For generic even passing interface (whatever it may be needed for) much more powerful virtio should be used.

On implementation itself I do not understand why is this kvm specific. The only thing that makes it so is that you hook device initialization into guest kvm initialization code, but this is obviously incorrect. What stops QEMU tcg or Xen from reusing the same device for the same purpose except the artificial limitation in a guest.

Reading data from a random ioports is not how you discover platform devices in 21 century (and the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version), you use ACPI for that and Marcelo already pointed that to you. Having little knowledge of ACPI (we all do) is not a good reason to not doing it. We probably need to reserve QEMU specific ACPI Plug and Play hardware ID to define our own

devices. After that you will be able to create device with _HID(QEMU0001)

in DSDT that supplies address information (ioport to use) and capability supported. Guest uses acpi_get_devices() to discover a platform device by its name (QEMU0001). Then you put the driver for the platform device into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it.

On QEMU side of things I cannot comment much on how QOMified the device is (it should be), I hope other reviews will verify it, but I noticed that device is only initialized for PIIX, what about Q35?

--
Gleb.

Quoted 8 lines · Gleb Natapov

Quoted 4 lines · Hu Tao

This series implements a new interface, kvm pv event, to notify host when some events happen in guest. Right now there is one supported event: guest panic.

What other event do you have in mind? Is interface generic enough to accommodate future, yet unknown, events. It allows to pass only one integer specifying even type, what if additional info is needed? My be

guest crash, lockup, or warning.[1] But the first purpose is to do panic notification(panic event). Since at the point the guest is panicked, I think it's better to keep the interface as simple as possible.

[1] http://wiki.qemu.org/Features/PVCrashDetection

Quoted 1 line

stop pretending that device is generic and make it do once thing but do

you mean make the interface just do panic notification?

Quoted 9 lines

it well? For generic even passing interface (whatever it may be needed for) much more powerful virtio should be used.

On implementation itself I do not understand why is this kvm specific. The only thing that makes it so is that you hook device initialization into guest kvm initialization code, but this is obviously incorrect. What stops QEMU tcg or Xen from reusing the same device for the same purpose except the artificial limitation in a guest.

Quoted 6 lines

Reading data from a random ioports is not how you discover platform devices in 21 century (and the data you read from unassigned port is not guarantied to be zero, it may depend on QEMU version), you use ACPI for that and Marcelo already pointed that to you. Having little knowledge of ACPI (we all do) is not a good reason to not doing it. We probably need to reserve QEMU specific ACPI Plug and Play hardware ID to define our own

Do we have to request the ID from some orgnazation?

Quoted 1 line

devices. After that you will be able to create device with _HID(QEMU0001)

QMU0001, I think. EISA ID requires it to have only 3 letters for PNP ID.