[Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

This function should be used when the VM is not supposed to resume
execution (eg. by issuing 'cont' monitor command).

Today, we allow the user to resume execution even when:

 o the guest shuts down and -no-shutdown is used
 o there's a kvm internal error
 o loading the VM state with -loadvm or "loadvm" in the monitor fails

I think only badness can happen from the cases above.

Another possible candidate is migration, that's, when the VM is
automatically stopped following a successful migration.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 cpus.c    |    7 +++++++
 kvm-all.c |    2 +-
 monitor.c |    9 +++++++--
 qerror.c  |    4 ++++
 qerror.h  |    3 +++
 sysemu.h  |    2 ++
 vl.c      |    4 +++-
 7 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/cpus.c b/cpus.c
index 6bf4e3f..5a4a480 100644
--- a/cpus.c
+++ b/cpus.c
@@ -535,6 +535,13 @@ static void qemu_tcg_init_cpu_signals(void)
 }
 #endif /* _WIN32 */
 
+void vm_stop_permanent(int reason)
+{
+    vm_stop(reason);
+    assert(!vm_permanent_stopped);
+    vm_permanent_stopped = 1;
+}
+
 #ifndef CONFIG_IOTHREAD
 int qemu_init_main_loop(void)
 {
diff --git a/kvm-all.c b/kvm-all.c
index cbc2532..4d0ceb3 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1014,7 +1014,7 @@ int kvm_cpu_exec(CPUState *env)
 
     if (ret < 0) {
         cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE);
-        vm_stop(VMSTOP_PANIC);
+        vm_stop_permanent(VMSTOP_PANIC);
     }
 
     env->exit_request = 0;
diff --git a/monitor.c b/monitor.c
index 718935b..86e146c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1307,7 +1307,10 @@ static int do_cont(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
     struct bdrv_iterate_context context = { mon, 0 };
 
-    if (incoming_expected) {
+    if (vm_permanent_stopped) {
+        qerror_report(QERR_VM_PERMANENT_STOPPED);
+        return -1;
+    } else if (incoming_expected) {
         qerror_report(QERR_MIGRATION_EXPECTED);
         return -1;
     }
@@ -2814,7 +2817,9 @@ static void do_loadvm(Monitor *mon, const QDict *qdict)
 
     vm_stop(VMSTOP_LOADVM);
 
-    if (load_vmstate(name) == 0 && saved_vm_running) {
+    if (load_vmstate(name) < 0) {
+        vm_permanent_stopped = 1;
+    } else if (saved_vm_running) {
         vm_start();
     }
 }
diff --git a/qerror.c b/qerror.c
index 69c1bc9..c91f763 100644
--- a/qerror.c
+++ b/qerror.c
@@ -219,6 +219,10 @@ static const QErrorStringTable qerror_table[] = {
                      "supported by this qemu version: %(feature)",
     },
     {
+        .error_fmt = QERR_VM_PERMANENT_STOPPED,
+        .desc      = "The Virtual Machine is permanently stopped",
+    },
+    {
         .error_fmt = QERR_VNC_SERVER_FAILED,
         .desc      = "Could not start VNC server on %(target)",
     },
diff --git a/qerror.h b/qerror.h
index 8058456..c759172 100644
--- a/qerror.h
+++ b/qerror.h
@@ -181,6 +181,9 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
     "{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format': %s, 'feature': %s } }"
 
+#define QERR_VM_PERMANENT_STOPPED \
+    "{ 'class': 'PermanentStopped', 'data': {} }"
+
 #define QERR_VNC_SERVER_FAILED \
     "{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }"
 
diff --git a/sysemu.h b/sysemu.h
index d3013f5..af90fa3 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -12,6 +12,7 @@
 extern const char *bios_name;
 
 extern int vm_running;
+extern int vm_permanent_stopped;
 extern const char *qemu_name;
 extern uint8_t qemu_uuid[];
 int qemu_uuid_parse(const char *str, uint8_t *uuid);
@@ -39,6 +40,7 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
 
 void vm_start(void);
 void vm_stop(int reason);
+void vm_stop_permanent(int reason);
 
 void qemu_system_reset_request(void);
 void qemu_system_shutdown_request(void);
diff --git a/vl.c b/vl.c
index 4b6688b..96403ac 100644
--- a/vl.c
+++ b/vl.c
@@ -186,6 +186,7 @@ NICInfo nd_table[MAX_NICS];
 int vm_running;
 int autostart;
 int incoming_expected; /* Started with -incoming and waiting for incoming */
+int vm_permanent_stopped = 0; /* qemu will never resume if set */
 static int rtc_utc = 1;
 static int rtc_date_offset = -1; /* -1 means no change */
 QEMUClock *rtc_clock;
@@ -1397,7 +1398,7 @@ static void main_loop(void)
             qemu_kill_report();
             monitor_protocol_event(QEVENT_SHUTDOWN, NULL);
             if (no_shutdown) {
-                vm_stop(VMSTOP_SHUTDOWN);
+                vm_stop_permanent(VMSTOP_SHUTDOWN);
             } else
                 break;
         }
@@ -3315,6 +3316,7 @@ int main(int argc, char **argv, char **envp)
     qemu_system_reset(VMRESET_SILENT);
     if (loadvm) {
         if (load_vmstate(loadvm) < 0) {
+            vm_permanent_stopped = 1;
             autostart = 0;
         }
     }
-- 
1.7.6.347.g4db0d

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Blue Swirl]

On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> This function should be used when the VM is not supposed to resume
> execution (eg. by issuing 'cont' monitor command).
>
> Today, we allow the user to resume execution even when:
>
>  o the guest shuts down and -no-shutdown is used
>  o there's a kvm internal error
>  o loading the VM state with -loadvm or "loadvm" in the monitor fails
>
> I think only badness can happen from the cases above.

I'd suppose a system_reset should bring the system back to sanity and
then clear vm_permanent_stopped (where's -ly?) except maybe for KVM
internal error if that can't be recovered. Then it would not very
permanent anymore, so the name would need adjusting.

>
> Another possible candidate is migration, that's, when the VM is
> automatically stopped following a successful migration.
>
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> ---
>  cpus.c    |    7 +++++++
>  kvm-all.c |    2 +-
>  monitor.c |    9 +++++++--
>  qerror.c  |    4 ++++
>  qerror.h  |    3 +++
>  sysemu.h  |    2 ++
>  vl.c      |    4 +++-
>  7 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index 6bf4e3f..5a4a480 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -535,6 +535,13 @@ static void qemu_tcg_init_cpu_signals(void)
>  }
>  #endif /* _WIN32 */
>
> +void vm_stop_permanent(int reason)
> +{
> +    vm_stop(reason);
> +    assert(!vm_permanent_stopped);
> +    vm_permanent_stopped = 1;
> +}
> +
>  #ifndef CONFIG_IOTHREAD
>  int qemu_init_main_loop(void)
>  {
> diff --git a/kvm-all.c b/kvm-all.c
> index cbc2532..4d0ceb3 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1014,7 +1014,7 @@ int kvm_cpu_exec(CPUState *env)
>
>     if (ret < 0) {
>         cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE);
> -        vm_stop(VMSTOP_PANIC);
> +        vm_stop_permanent(VMSTOP_PANIC);
>     }
>
>     env->exit_request = 0;
> diff --git a/monitor.c b/monitor.c
> index 718935b..86e146c 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -1307,7 +1307,10 @@ static int do_cont(Monitor *mon, const QDict *qdict, QObject **ret_data)
>  {
>     struct bdrv_iterate_context context = { mon, 0 };
>
> -    if (incoming_expected) {
> +    if (vm_permanent_stopped) {
> +        qerror_report(QERR_VM_PERMANENT_STOPPED);
> +        return -1;
> +    } else if (incoming_expected) {
>         qerror_report(QERR_MIGRATION_EXPECTED);
>         return -1;
>     }
> @@ -2814,7 +2817,9 @@ static void do_loadvm(Monitor *mon, const QDict *qdict)
>
>     vm_stop(VMSTOP_LOADVM);
>
> -    if (load_vmstate(name) == 0 && saved_vm_running) {
> +    if (load_vmstate(name) < 0) {
> +        vm_permanent_stopped = 1;
> +    } else if (saved_vm_running) {
>         vm_start();
>     }
>  }
> diff --git a/qerror.c b/qerror.c
> index 69c1bc9..c91f763 100644
> --- a/qerror.c
> +++ b/qerror.c
> @@ -219,6 +219,10 @@ static const QErrorStringTable qerror_table[] = {
>                      "supported by this qemu version: %(feature)",
>     },
>     {
> +        .error_fmt = QERR_VM_PERMANENT_STOPPED,
> +        .desc      = "The Virtual Machine is permanently stopped",
> +    },
> +    {
>         .error_fmt = QERR_VNC_SERVER_FAILED,
>         .desc      = "Could not start VNC server on %(target)",
>     },
> diff --git a/qerror.h b/qerror.h
> index 8058456..c759172 100644
> --- a/qerror.h
> +++ b/qerror.h
> @@ -181,6 +181,9 @@ QError *qobject_to_qerror(const QObject *obj);
>  #define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
>     "{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format': %s, 'feature': %s } }"
>
> +#define QERR_VM_PERMANENT_STOPPED \
> +    "{ 'class': 'PermanentStopped', 'data': {} }"
> +
>  #define QERR_VNC_SERVER_FAILED \
>     "{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }"
>
> diff --git a/sysemu.h b/sysemu.h
> index d3013f5..af90fa3 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -12,6 +12,7 @@
>  extern const char *bios_name;
>
>  extern int vm_running;
> +extern int vm_permanent_stopped;
>  extern const char *qemu_name;
>  extern uint8_t qemu_uuid[];
>  int qemu_uuid_parse(const char *str, uint8_t *uuid);
> @@ -39,6 +40,7 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
>
>  void vm_start(void);
>  void vm_stop(int reason);
> +void vm_stop_permanent(int reason);
>
>  void qemu_system_reset_request(void);
>  void qemu_system_shutdown_request(void);
> diff --git a/vl.c b/vl.c
> index 4b6688b..96403ac 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -186,6 +186,7 @@ NICInfo nd_table[MAX_NICS];
>  int vm_running;
>  int autostart;
>  int incoming_expected; /* Started with -incoming and waiting for incoming */
> +int vm_permanent_stopped = 0; /* qemu will never resume if set */
>  static int rtc_utc = 1;
>  static int rtc_date_offset = -1; /* -1 means no change */
>  QEMUClock *rtc_clock;
> @@ -1397,7 +1398,7 @@ static void main_loop(void)
>             qemu_kill_report();
>             monitor_protocol_event(QEVENT_SHUTDOWN, NULL);
>             if (no_shutdown) {
> -                vm_stop(VMSTOP_SHUTDOWN);
> +                vm_stop_permanent(VMSTOP_SHUTDOWN);
>             } else
>                 break;
>         }
> @@ -3315,6 +3316,7 @@ int main(int argc, char **argv, char **envp)
>     qemu_system_reset(VMRESET_SILENT);
>     if (loadvm) {
>         if (load_vmstate(loadvm) < 0) {
> +            vm_permanent_stopped = 1;
>             autostart = 0;
>         }
>     }
> --
> 1.7.6.347.g4db0d
>
>
>

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Avi Kivity]

On 07/28/2011 12:44 AM, Blue Swirl wrote:
> On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino<lcapitulino@redhat.com>  wrote:
> >  This function should be used when the VM is not supposed to resume
> >  execution (eg. by issuing 'cont' monitor command).
> >
> >  Today, we allow the user to resume execution even when:
> >
> >    o the guest shuts down and -no-shutdown is used
> >    o there's a kvm internal error
> >    o loading the VM state with -loadvm or "loadvm" in the monitor fails
> >
> >  I think only badness can happen from the cases above.
>
> I'd suppose a system_reset should bring the system back to sanity and
> then clear vm_permanent_stopped (where's -ly?) except maybe for KVM
> internal error if that can't be recovered. Then it would not very
> permanent anymore, so the name would need adjusting.

Currently, all kvm internal errors are recoverable by reset (and 
possibly by fiddling with memory/registers).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 10:23:22 +0300
Avi Kivity <avi@redhat.com> wrote:

> On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino<lcapitulino@redhat.com>  wrote:
> > >  This function should be used when the VM is not supposed to resume
> > >  execution (eg. by issuing 'cont' monitor command).
> > >
> > >  Today, we allow the user to resume execution even when:
> > >
> > >    o the guest shuts down and -no-shutdown is used
> > >    o there's a kvm internal error
> > >    o loading the VM state with -loadvm or "loadvm" in the monitor fails
> > >
> > >  I think only badness can happen from the cases above.
> >
> > I'd suppose a system_reset should bring the system back to sanity and
> > then clear vm_permanent_stopped (where's -ly?)

What's -ly?

> > except maybe for KVM
> > internal error if that can't be recovered. Then it would not very
> > permanent anymore, so the name would need adjusting.
> 
> Currently, all kvm internal errors are recoverable by reset (and 
> possibly by fiddling with memory/registers).

Ok, but a poweroff in the guest isn't recoverable with system_reset
right? Or does it depend on the guest?

I get funny results if qemu is started with -no-shutdown and I run cont after
a poweroff in a F15 guest. Sometimes qemu will exit after a few seconds,
sometimes 'info status' will say 'running'.

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Avi Kivity]

On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 10:23:22 +0300
> Avi Kivity<avi@redhat.com>  wrote:
>
> >  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino<lcapitulino@redhat.com>   wrote:
> >  >  >   This function should be used when the VM is not supposed to resume
> >  >  >   execution (eg. by issuing 'cont' monitor command).
> >  >  >
> >  >  >   Today, we allow the user to resume execution even when:
> >  >  >
> >  >  >     o the guest shuts down and -no-shutdown is used
> >  >  >     o there's a kvm internal error
> >  >  >     o loading the VM state with -loadvm or "loadvm" in the monitor fails
> >  >  >
> >  >  >   I think only badness can happen from the cases above.
> >  >
> >  >  I'd suppose a system_reset should bring the system back to sanity and
> >  >  then clear vm_permanent_stopped (where's -ly?)
>
> What's -ly?
>

permanent-ly.

> >  >  except maybe for KVM
> >  >  internal error if that can't be recovered. Then it would not very
> >  >  permanent anymore, so the name would need adjusting.
> >
> >  Currently, all kvm internal errors are recoverable by reset (and
> >  possibly by fiddling with memory/registers).
>
> Ok, but a poweroff in the guest isn't recoverable with system_reset
> right? Or does it depend on the guest?

Right, it's not recoverable if you shut the power down where the tractor 
beam is coupled to the main reactor.

> I get funny results if qemu is started with -no-shutdown and I run cont after
> a poweroff in a F15 guest. Sometimes qemu will exit after a few seconds,
> sometimes 'info status' will say 'running'.

Yes, best fixed.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On 2011-07-28 15:37, Avi Kivity wrote:
> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
>> On Thu, 28 Jul 2011 10:23:22 +0300
>> Avi Kivity<avi@redhat.com>  wrote:
>>
>> >  On 07/28/2011 12:44 AM, Blue Swirl wrote:
>> >  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
>> Capitulino<lcapitulino@redhat.com>   wrote:
>> >  >  >   This function should be used when the VM is not supposed to
>> resume
>> >  >  >   execution (eg. by issuing 'cont' monitor command).
>> >  >  >
>> >  >  >   Today, we allow the user to resume execution even when:
>> >  >  >
>> >  >  >     o the guest shuts down and -no-shutdown is used
>> >  >  >     o there's a kvm internal error
>> >  >  >     o loading the VM state with -loadvm or "loadvm" in the
>> monitor fails
>> >  >  >
>> >  >  >   I think only badness can happen from the cases above.
>> >  >
>> >  >  I'd suppose a system_reset should bring the system back to
>> sanity and
>> >  >  then clear vm_permanent_stopped (where's -ly?)
>>
>> What's -ly?
>>
> 
> permanent-ly.
> 
>> >  >  except maybe for KVM
>> >  >  internal error if that can't be recovered. Then it would not very
>> >  >  permanent anymore, so the name would need adjusting.
>> >
>> >  Currently, all kvm internal errors are recoverable by reset (and
>> >  possibly by fiddling with memory/registers).
>>
>> Ok, but a poweroff in the guest isn't recoverable with system_reset
>> right? Or does it depend on the guest?
> 
> Right, it's not recoverable if you shut the power down where the tractor
> beam is coupled to the main reactor.

system_reset will bring all emulated devices back into their power-on
state - unless we have remaining bugs to fix. Actually, one may consider
issuing this reset automatically on vm_start after "permant" vm_stop.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 16:19:19 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

> On 2011-07-28 15:37, Avi Kivity wrote:
> > On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> >> On Thu, 28 Jul 2011 10:23:22 +0300
> >> Avi Kivity<avi@redhat.com>  wrote:
> >>
> >> >  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >> >  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> >> Capitulino<lcapitulino@redhat.com>   wrote:
> >> >  >  >   This function should be used when the VM is not supposed to
> >> resume
> >> >  >  >   execution (eg. by issuing 'cont' monitor command).
> >> >  >  >
> >> >  >  >   Today, we allow the user to resume execution even when:
> >> >  >  >
> >> >  >  >     o the guest shuts down and -no-shutdown is used
> >> >  >  >     o there's a kvm internal error
> >> >  >  >     o loading the VM state with -loadvm or "loadvm" in the
> >> monitor fails
> >> >  >  >
> >> >  >  >   I think only badness can happen from the cases above.
> >> >  >
> >> >  >  I'd suppose a system_reset should bring the system back to
> >> sanity and
> >> >  >  then clear vm_permanent_stopped (where's -ly?)
> >>
> >> What's -ly?
> >>
> > 
> > permanent-ly.
> > 
> >> >  >  except maybe for KVM
> >> >  >  internal error if that can't be recovered. Then it would not very
> >> >  >  permanent anymore, so the name would need adjusting.
> >> >
> >> >  Currently, all kvm internal errors are recoverable by reset (and
> >> >  possibly by fiddling with memory/registers).
> >>
> >> Ok, but a poweroff in the guest isn't recoverable with system_reset
> >> right? Or does it depend on the guest?
> > 
> > Right, it's not recoverable if you shut the power down where the tractor
> > beam is coupled to the main reactor.
> 
> system_reset will bring all emulated devices back into their power-on
> state - unless we have remaining bugs to fix. Actually, one may consider
> issuing this reset automatically on vm_start after "permant" vm_stop.

I'm going to abandon the vm_stop_permanent() idea.

I'm thinking something towards having a stop_kind argument to vm_stop(),
which could be temporary (which is what we have today), only with
system_reset or permanent.

Or maybe vm_stop_opt(), which allows for fine grained control of stop
(vm_stop() would default to today's behavior)...

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

On 2011-07-28 17:18, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 16:19:19 +0200
> Jan Kiszka <jan.kiszka@web.de> wrote:
> 
>> On 2011-07-28 15:37, Avi Kivity wrote:
>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
>>>> On Thu, 28 Jul 2011 10:23:22 +0300
>>>> Avi Kivity<avi@redhat.com>  wrote:
>>>>
>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
>>>> Capitulino<lcapitulino@redhat.com>   wrote:
>>>>>  >  >   This function should be used when the VM is not supposed to
>>>> resume
>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
>>>>>  >  >
>>>>>  >  >   Today, we allow the user to resume execution even when:
>>>>>  >  >
>>>>>  >  >     o the guest shuts down and -no-shutdown is used
>>>>>  >  >     o there's a kvm internal error
>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
>>>> monitor fails
>>>>>  >  >
>>>>>  >  >   I think only badness can happen from the cases above.
>>>>>  >
>>>>>  >  I'd suppose a system_reset should bring the system back to
>>>> sanity and
>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
>>>>
>>>> What's -ly?
>>>>
>>>
>>> permanent-ly.
>>>
>>>>>  >  except maybe for KVM
>>>>>  >  internal error if that can't be recovered. Then it would not very
>>>>>  >  permanent anymore, so the name would need adjusting.
>>>>>
>>>>>  Currently, all kvm internal errors are recoverable by reset (and
>>>>>  possibly by fiddling with memory/registers).
>>>>
>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
>>>> right? Or does it depend on the guest?
>>>
>>> Right, it's not recoverable if you shut the power down where the tractor
>>> beam is coupled to the main reactor.
>>
>> system_reset will bring all emulated devices back into their power-on
>> state - unless we have remaining bugs to fix. Actually, one may consider
>> issuing this reset automatically on vm_start after "permant" vm_stop.
> 
> I'm going to abandon the vm_stop_permanent() idea.
> 
> I'm thinking something towards having a stop_kind argument to vm_stop(),
> which could be temporary (which is what we have today), only with
> system_reset or permanent.
> 
> Or maybe vm_stop_opt(), which allows for fine grained control of stop
> (vm_stop() would default to today's behavior)...

But the right point for reset is start, not stop. Otherwise we loose the
state before the stop.

Jam


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 17:20:41 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

> On 2011-07-28 17:18, Luiz Capitulino wrote:
> > On Thu, 28 Jul 2011 16:19:19 +0200
> > Jan Kiszka <jan.kiszka@web.de> wrote:
> > 
> >> On 2011-07-28 15:37, Avi Kivity wrote:
> >>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> >>>> On Thu, 28 Jul 2011 10:23:22 +0300
> >>>> Avi Kivity<avi@redhat.com>  wrote:
> >>>>
> >>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> >>>> Capitulino<lcapitulino@redhat.com>   wrote:
> >>>>>  >  >   This function should be used when the VM is not supposed to
> >>>> resume
> >>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> >>>>>  >  >
> >>>>>  >  >   Today, we allow the user to resume execution even when:
> >>>>>  >  >
> >>>>>  >  >     o the guest shuts down and -no-shutdown is used
> >>>>>  >  >     o there's a kvm internal error
> >>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> >>>> monitor fails
> >>>>>  >  >
> >>>>>  >  >   I think only badness can happen from the cases above.
> >>>>>  >
> >>>>>  >  I'd suppose a system_reset should bring the system back to
> >>>> sanity and
> >>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> >>>>
> >>>> What's -ly?
> >>>>
> >>>
> >>> permanent-ly.
> >>>
> >>>>>  >  except maybe for KVM
> >>>>>  >  internal error if that can't be recovered. Then it would not very
> >>>>>  >  permanent anymore, so the name would need adjusting.
> >>>>>
> >>>>>  Currently, all kvm internal errors are recoverable by reset (and
> >>>>>  possibly by fiddling with memory/registers).
> >>>>
> >>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> >>>> right? Or does it depend on the guest?
> >>>
> >>> Right, it's not recoverable if you shut the power down where the tractor
> >>> beam is coupled to the main reactor.
> >>
> >> system_reset will bring all emulated devices back into their power-on
> >> state - unless we have remaining bugs to fix. Actually, one may consider
> >> issuing this reset automatically on vm_start after "permant" vm_stop.

The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.

Are you saying that system_reset should be able to recover from that too?

If yes, then I guess the right place is do_cont(). But I'm not sure we
should do that (if -no-shutdown is not used, we'll exit() anyway).

> > 
> > I'm going to abandon the vm_stop_permanent() idea.
> > 
> > I'm thinking something towards having a stop_kind argument to vm_stop(),
> > which could be temporary (which is what we have today), only with
> > system_reset or permanent.
> > 
> > Or maybe vm_stop_opt(), which allows for fine grained control of stop
> > (vm_stop() would default to today's behavior)...
> 
> But the right point for reset is start, not stop. Otherwise we loose the
> state before the stop.

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 14:39:23 -0300
Luiz Capitulino <lcapitulino@redhat.com> wrote:

> On Thu, 28 Jul 2011 17:20:41 +0200
> Jan Kiszka <jan.kiszka@web.de> wrote:
> 
> > On 2011-07-28 17:18, Luiz Capitulino wrote:
> > > On Thu, 28 Jul 2011 16:19:19 +0200
> > > Jan Kiszka <jan.kiszka@web.de> wrote:
> > > 
> > >> On 2011-07-28 15:37, Avi Kivity wrote:
> > >>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> > >>>> On Thu, 28 Jul 2011 10:23:22 +0300
> > >>>> Avi Kivity<avi@redhat.com>  wrote:
> > >>>>
> > >>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > >>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> > >>>> Capitulino<lcapitulino@redhat.com>   wrote:
> > >>>>>  >  >   This function should be used when the VM is not supposed to
> > >>>> resume
> > >>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> > >>>>>  >  >
> > >>>>>  >  >   Today, we allow the user to resume execution even when:
> > >>>>>  >  >
> > >>>>>  >  >     o the guest shuts down and -no-shutdown is used
> > >>>>>  >  >     o there's a kvm internal error
> > >>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> > >>>> monitor fails
> > >>>>>  >  >
> > >>>>>  >  >   I think only badness can happen from the cases above.
> > >>>>>  >
> > >>>>>  >  I'd suppose a system_reset should bring the system back to
> > >>>> sanity and
> > >>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> > >>>>
> > >>>> What's -ly?
> > >>>>
> > >>>
> > >>> permanent-ly.
> > >>>
> > >>>>>  >  except maybe for KVM
> > >>>>>  >  internal error if that can't be recovered. Then it would not very
> > >>>>>  >  permanent anymore, so the name would need adjusting.
> > >>>>>
> > >>>>>  Currently, all kvm internal errors are recoverable by reset (and
> > >>>>>  possibly by fiddling with memory/registers).
> > >>>>
> > >>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> > >>>> right? Or does it depend on the guest?
> > >>>
> > >>> Right, it's not recoverable if you shut the power down where the tractor
> > >>> beam is coupled to the main reactor.
> > >>
> > >> system_reset will bring all emulated devices back into their power-on
> > >> state - unless we have remaining bugs to fix. Actually, one may consider
> > >> issuing this reset automatically on vm_start after "permant" vm_stop.
> 
> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
> 
> Are you saying that system_reset should be able to recover from that too?

It already does, so we don't have permanent stops.

> 
> If yes, then I guess the right place is do_cont(). But I'm not sure we
> should do that (if -no-shutdown is not used, we'll exit() anyway).
> 
> > > 
> > > I'm going to abandon the vm_stop_permanent() idea.
> > > 
> > > I'm thinking something towards having a stop_kind argument to vm_stop(),
> > > which could be temporary (which is what we have today), only with
> > > system_reset or permanent.
> > > 
> > > Or maybe vm_stop_opt(), which allows for fine grained control of stop
> > > (vm_stop() would default to today's behavior)...
> > 
> > But the right point for reset is start, not stop. Otherwise we loose the
> > state before the stop.
> 

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

On 2011-07-28 19:48, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 14:39:23 -0300
> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> 
>> On Thu, 28 Jul 2011 17:20:41 +0200
>> Jan Kiszka <jan.kiszka@web.de> wrote:
>>
>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
>>>> On Thu, 28 Jul 2011 16:19:19 +0200
>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>
>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
>>>>>>>
>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
>>>>>>>>  >  >   This function should be used when the VM is not supposed to
>>>>>>> resume
>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
>>>>>>>>  >  >
>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
>>>>>>>>  >  >
>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
>>>>>>>>  >  >     o there's a kvm internal error
>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
>>>>>>> monitor fails
>>>>>>>>  >  >
>>>>>>>>  >  >   I think only badness can happen from the cases above.
>>>>>>>>  >
>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
>>>>>>> sanity and
>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
>>>>>>>
>>>>>>> What's -ly?
>>>>>>>
>>>>>>
>>>>>> permanent-ly.
>>>>>>
>>>>>>>>  >  except maybe for KVM
>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
>>>>>>>>  >  permanent anymore, so the name would need adjusting.
>>>>>>>>
>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
>>>>>>>>  possibly by fiddling with memory/registers).
>>>>>>>
>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
>>>>>>> right? Or does it depend on the guest?
>>>>>>
>>>>>> Right, it's not recoverable if you shut the power down where the tractor
>>>>>> beam is coupled to the main reactor.
>>>>>
>>>>> system_reset will bring all emulated devices back into their power-on
>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
>>
>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
>>
>> Are you saying that system_reset should be able to recover from that too?
> 
> It already does, so we don't have permanent stops.

Exactly. We just have stops over inconsistent states that require a
reset to continue with anything useful.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 19:52:31 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

> On 2011-07-28 19:48, Luiz Capitulino wrote:
> > On Thu, 28 Jul 2011 14:39:23 -0300
> > Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > 
> >> On Thu, 28 Jul 2011 17:20:41 +0200
> >> Jan Kiszka <jan.kiszka@web.de> wrote:
> >>
> >>> On 2011-07-28 17:18, Luiz Capitulino wrote:
> >>>> On Thu, 28 Jul 2011 16:19:19 +0200
> >>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>
> >>>>> On 2011-07-28 15:37, Avi Kivity wrote:
> >>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> >>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
> >>>>>>> Avi Kivity<avi@redhat.com>  wrote:
> >>>>>>>
> >>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> >>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
> >>>>>>>>  >  >   This function should be used when the VM is not supposed to
> >>>>>>> resume
> >>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> >>>>>>>>  >  >
> >>>>>>>>  >  >   Today, we allow the user to resume execution even when:
> >>>>>>>>  >  >
> >>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
> >>>>>>>>  >  >     o there's a kvm internal error
> >>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> >>>>>>> monitor fails
> >>>>>>>>  >  >
> >>>>>>>>  >  >   I think only badness can happen from the cases above.
> >>>>>>>>  >
> >>>>>>>>  >  I'd suppose a system_reset should bring the system back to
> >>>>>>> sanity and
> >>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> >>>>>>>
> >>>>>>> What's -ly?
> >>>>>>>
> >>>>>>
> >>>>>> permanent-ly.
> >>>>>>
> >>>>>>>>  >  except maybe for KVM
> >>>>>>>>  >  internal error if that can't be recovered. Then it would not very
> >>>>>>>>  >  permanent anymore, so the name would need adjusting.
> >>>>>>>>
> >>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
> >>>>>>>>  possibly by fiddling with memory/registers).
> >>>>>>>
> >>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> >>>>>>> right? Or does it depend on the guest?
> >>>>>>
> >>>>>> Right, it's not recoverable if you shut the power down where the tractor
> >>>>>> beam is coupled to the main reactor.
> >>>>>
> >>>>> system_reset will bring all emulated devices back into their power-on
> >>>>> state - unless we have remaining bugs to fix. Actually, one may consider
> >>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
> >>
> >> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
> >>
> >> Are you saying that system_reset should be able to recover from that too?
> > 
> > It already does, so we don't have permanent stops.
> 
> Exactly. We just have stops over inconsistent states that require a
> reset to continue with anything useful.

Yes. If I got you right, you suggest that we do the reset automatically.

I think it's better to let the user do it, because s/he might want to
do something else before resetting. For example, for the kvm error the
user might want to save the vm state.

For the poweroff case with -no-shutdown it's probably fine, but I don't
want to hard code special cases. It's better and easier to treat them all
as "require system_reset to recover".

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]

On 2011-07-28 20:00, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 19:52:31 +0200
> Jan Kiszka <jan.kiszka@web.de> wrote:
> 
>> On 2011-07-28 19:48, Luiz Capitulino wrote:
>>> On Thu, 28 Jul 2011 14:39:23 -0300
>>> Luiz Capitulino <lcapitulino@redhat.com> wrote:
>>>
>>>> On Thu, 28 Jul 2011 17:20:41 +0200
>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>
>>>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
>>>>>> On Thu, 28 Jul 2011 16:19:19 +0200
>>>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>>>
>>>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
>>>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
>>>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
>>>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
>>>>>>>>>
>>>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
>>>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
>>>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
>>>>>>>>>>  >  >   This function should be used when the VM is not supposed to
>>>>>>>>> resume
>>>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
>>>>>>>>>>  >  >
>>>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
>>>>>>>>>>  >  >
>>>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
>>>>>>>>>>  >  >     o there's a kvm internal error
>>>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
>>>>>>>>> monitor fails
>>>>>>>>>>  >  >
>>>>>>>>>>  >  >   I think only badness can happen from the cases above.
>>>>>>>>>>  >
>>>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
>>>>>>>>> sanity and
>>>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
>>>>>>>>>
>>>>>>>>> What's -ly?
>>>>>>>>>
>>>>>>>>
>>>>>>>> permanent-ly.
>>>>>>>>
>>>>>>>>>>  >  except maybe for KVM
>>>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
>>>>>>>>>>  >  permanent anymore, so the name would need adjusting.
>>>>>>>>>>
>>>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
>>>>>>>>>>  possibly by fiddling with memory/registers).
>>>>>>>>>
>>>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
>>>>>>>>> right? Or does it depend on the guest?
>>>>>>>>
>>>>>>>> Right, it's not recoverable if you shut the power down where the tractor
>>>>>>>> beam is coupled to the main reactor.
>>>>>>>
>>>>>>> system_reset will bring all emulated devices back into their power-on
>>>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
>>>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
>>>>
>>>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
>>>>
>>>> Are you saying that system_reset should be able to recover from that too?
>>>
>>> It already does, so we don't have permanent stops.
>>
>> Exactly. We just have stops over inconsistent states that require a
>> reset to continue with anything useful.
> 
> Yes. If I got you right, you suggest that we do the reset automatically.
> 
> I think it's better to let the user do it, because s/he might want to
> do something else before resetting. For example, for the kvm error the
> user might want to save the vm state.

Associating the reset with a cont means requesting an explicit action
from the user. I'm not suggesting to do the reset when the stop state is
entered.

> 
> For the poweroff case with -no-shutdown it's probably fine, but I don't
> want to hard code special cases. It's better and easier to treat them all
> as "require system_reset to recover".

In any case, we need to tag the current state as stopped-and-invalid or
so vs. a normal stop. That remains a valuable first step. How to deal
with that information is the second one.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Thu, 28 Jul 2011 20:04:58 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

> On 2011-07-28 20:00, Luiz Capitulino wrote:
> > On Thu, 28 Jul 2011 19:52:31 +0200
> > Jan Kiszka <jan.kiszka@web.de> wrote:
> > 
> >> On 2011-07-28 19:48, Luiz Capitulino wrote:
> >>> On Thu, 28 Jul 2011 14:39:23 -0300
> >>> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> >>>
> >>>> On Thu, 28 Jul 2011 17:20:41 +0200
> >>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>
> >>>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
> >>>>>> On Thu, 28 Jul 2011 16:19:19 +0200
> >>>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>>>
> >>>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
> >>>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> >>>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
> >>>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
> >>>>>>>>>
> >>>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >>>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> >>>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
> >>>>>>>>>>  >  >   This function should be used when the VM is not supposed to
> >>>>>>>>> resume
> >>>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> >>>>>>>>>>  >  >
> >>>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
> >>>>>>>>>>  >  >
> >>>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
> >>>>>>>>>>  >  >     o there's a kvm internal error
> >>>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> >>>>>>>>> monitor fails
> >>>>>>>>>>  >  >
> >>>>>>>>>>  >  >   I think only badness can happen from the cases above.
> >>>>>>>>>>  >
> >>>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
> >>>>>>>>> sanity and
> >>>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> >>>>>>>>>
> >>>>>>>>> What's -ly?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> permanent-ly.
> >>>>>>>>
> >>>>>>>>>>  >  except maybe for KVM
> >>>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
> >>>>>>>>>>  >  permanent anymore, so the name would need adjusting.
> >>>>>>>>>>
> >>>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
> >>>>>>>>>>  possibly by fiddling with memory/registers).
> >>>>>>>>>
> >>>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> >>>>>>>>> right? Or does it depend on the guest?
> >>>>>>>>
> >>>>>>>> Right, it's not recoverable if you shut the power down where the tractor
> >>>>>>>> beam is coupled to the main reactor.
> >>>>>>>
> >>>>>>> system_reset will bring all emulated devices back into their power-on
> >>>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
> >>>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
> >>>>
> >>>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
> >>>>
> >>>> Are you saying that system_reset should be able to recover from that too?
> >>>
> >>> It already does, so we don't have permanent stops.
> >>
> >> Exactly. We just have stops over inconsistent states that require a
> >> reset to continue with anything useful.
> > 
> > Yes. If I got you right, you suggest that we do the reset automatically.
> > 
> > I think it's better to let the user do it, because s/he might want to
> > do something else before resetting. For example, for the kvm error the
> > user might want to save the vm state.
> 
> Associating the reset with a cont means requesting an explicit action
> from the user. I'm not suggesting to do the reset when the stop state is
> entered.

I see. But automatically resetting on cont might be unexpected to the
user, even on a bad state.

Another option would be to add a force option to cont, where the reset is
done when the state is invalid (otherwise cont will return an error).

I still prefer to let the user do it manually though.

> > For the poweroff case with -no-shutdown it's probably fine, but I don't
> > want to hard code special cases. It's better and easier to treat them all
> > as "require system_reset to recover".
> 
> In any case, we need to tag the current state as stopped-and-invalid or
> so vs. a normal stop. That remains a valuable first step. How to deal
> with that information is the second one.

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Alon Levy]

On Thu, Jul 28, 2011 at 03:22:52PM -0300, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 20:04:58 +0200
> Jan Kiszka <jan.kiszka@web.de> wrote:
> 
> > On 2011-07-28 20:00, Luiz Capitulino wrote:
> > > On Thu, 28 Jul 2011 19:52:31 +0200
> > > Jan Kiszka <jan.kiszka@web.de> wrote:
> > > 
> > >> On 2011-07-28 19:48, Luiz Capitulino wrote:
> > >>> On Thu, 28 Jul 2011 14:39:23 -0300
> > >>> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > >>>
> > >>>> On Thu, 28 Jul 2011 17:20:41 +0200
> > >>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> > >>>>
> > >>>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
> > >>>>>> On Thu, 28 Jul 2011 16:19:19 +0200
> > >>>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> > >>>>>>
> > >>>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
> > >>>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> > >>>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
> > >>>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
> > >>>>>>>>>
> > >>>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > >>>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> > >>>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
> > >>>>>>>>>>  >  >   This function should be used when the VM is not supposed to
> > >>>>>>>>> resume
> > >>>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> > >>>>>>>>>>  >  >
> > >>>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
> > >>>>>>>>>>  >  >
> > >>>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
> > >>>>>>>>>>  >  >     o there's a kvm internal error
> > >>>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> > >>>>>>>>> monitor fails
> > >>>>>>>>>>  >  >
> > >>>>>>>>>>  >  >   I think only badness can happen from the cases above.
> > >>>>>>>>>>  >
> > >>>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
> > >>>>>>>>> sanity and
> > >>>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> > >>>>>>>>>
> > >>>>>>>>> What's -ly?
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> permanent-ly.
> > >>>>>>>>
> > >>>>>>>>>>  >  except maybe for KVM
> > >>>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
> > >>>>>>>>>>  >  permanent anymore, so the name would need adjusting.
> > >>>>>>>>>>
> > >>>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
> > >>>>>>>>>>  possibly by fiddling with memory/registers).
> > >>>>>>>>>
> > >>>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> > >>>>>>>>> right? Or does it depend on the guest?
> > >>>>>>>>
> > >>>>>>>> Right, it's not recoverable if you shut the power down where the tractor
> > >>>>>>>> beam is coupled to the main reactor.
> > >>>>>>>
> > >>>>>>> system_reset will bring all emulated devices back into their power-on
> > >>>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
> > >>>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
> > >>>>
> > >>>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
> > >>>>
> > >>>> Are you saying that system_reset should be able to recover from that too?
> > >>>
> > >>> It already does, so we don't have permanent stops.
> > >>
> > >> Exactly. We just have stops over inconsistent states that require a
> > >> reset to continue with anything useful.
> > > 
> > > Yes. If I got you right, you suggest that we do the reset automatically.
> > > 
> > > I think it's better to let the user do it, because s/he might want to
> > > do something else before resetting. For example, for the kvm error the
> > > user might want to save the vm state.
> > 
> > Associating the reset with a cont means requesting an explicit action
> > from the user. I'm not suggesting to do the reset when the stop state is
> > entered.
> 
> I see. But automatically resetting on cont might be unexpected to the
> user, even on a bad state.

I use this feature a lot in testing, i.e. that there is no automatic reset
when I run a vm with -no-shutdown and I do a guest initiated shutdown.
Very convenient when running with snapshot - great time to do commit ide0.
I have a patch I send a month or so ago to make sure you can do this endlessly -
currently after the first shutdown the -no-shutdown set flag is reset.

> 
> Another option would be to add a force option to cont, where the reset is
> done when the state is invalid (otherwise cont will return an error).
> 
> I still prefer to let the user do it manually though.
> 
> > > For the poweroff case with -no-shutdown it's probably fine, but I don't
> > > want to hard code special cases. It's better and easier to treat them all
> > > as "require system_reset to recover".
> > 
> > In any case, we need to tag the current state as stopped-and-invalid or
> > so vs. a normal stop. That remains a valuable first step. How to deal
> > with that information is the second one.
> 

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Blue Swirl]

On Thu, Jul 28, 2011 at 9:22 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Thu, 28 Jul 2011 20:04:58 +0200
> Jan Kiszka <jan.kiszka@web.de> wrote:
>
>> On 2011-07-28 20:00, Luiz Capitulino wrote:
>> > On Thu, 28 Jul 2011 19:52:31 +0200
>> > Jan Kiszka <jan.kiszka@web.de> wrote:
>> >
>> >> On 2011-07-28 19:48, Luiz Capitulino wrote:
>> >>> On Thu, 28 Jul 2011 14:39:23 -0300
>> >>> Luiz Capitulino <lcapitulino@redhat.com> wrote:
>> >>>
>> >>>> On Thu, 28 Jul 2011 17:20:41 +0200
>> >>>> Jan Kiszka <jan.kiszka@web.de> wrote:
>> >>>>
>> >>>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
>> >>>>>> On Thu, 28 Jul 2011 16:19:19 +0200
>> >>>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
>> >>>>>>
>> >>>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
>> >>>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
>> >>>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
>> >>>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
>> >>>>>>>>>
>> >>>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
>> >>>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
>> >>>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
>> >>>>>>>>>>  >  >   This function should be used when the VM is not supposed to
>> >>>>>>>>> resume
>> >>>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
>> >>>>>>>>>>  >  >
>> >>>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
>> >>>>>>>>>>  >  >
>> >>>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
>> >>>>>>>>>>  >  >     o there's a kvm internal error
>> >>>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
>> >>>>>>>>> monitor fails
>> >>>>>>>>>>  >  >
>> >>>>>>>>>>  >  >   I think only badness can happen from the cases above.
>> >>>>>>>>>>  >
>> >>>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
>> >>>>>>>>> sanity and
>> >>>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
>> >>>>>>>>>
>> >>>>>>>>> What's -ly?
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> permanent-ly.
>> >>>>>>>>
>> >>>>>>>>>>  >  except maybe for KVM
>> >>>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
>> >>>>>>>>>>  >  permanent anymore, so the name would need adjusting.
>> >>>>>>>>>>
>> >>>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
>> >>>>>>>>>>  possibly by fiddling with memory/registers).
>> >>>>>>>>>
>> >>>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
>> >>>>>>>>> right? Or does it depend on the guest?
>> >>>>>>>>
>> >>>>>>>> Right, it's not recoverable if you shut the power down where the tractor
>> >>>>>>>> beam is coupled to the main reactor.
>> >>>>>>>
>> >>>>>>> system_reset will bring all emulated devices back into their power-on
>> >>>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
>> >>>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
>> >>>>
>> >>>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
>> >>>>
>> >>>> Are you saying that system_reset should be able to recover from that too?
>> >>>
>> >>> It already does, so we don't have permanent stops.
>> >>
>> >> Exactly. We just have stops over inconsistent states that require a
>> >> reset to continue with anything useful.
>> >
>> > Yes. If I got you right, you suggest that we do the reset automatically.
>> >
>> > I think it's better to let the user do it, because s/he might want to
>> > do something else before resetting. For example, for the kvm error the
>> > user might want to save the vm state.
>>
>> Associating the reset with a cont means requesting an explicit action
>> from the user. I'm not suggesting to do the reset when the stop state is
>> entered.
>
> I see. But automatically resetting on cont might be unexpected to the
> user, even on a bad state.
>
> Another option would be to add a force option to cont, where the reset is
> done when the state is invalid (otherwise cont will return an error).
>
> I still prefer to let the user do it manually though.
>
>> > For the poweroff case with -no-shutdown it's probably fine, but I don't
>> > want to hard code special cases. It's better and easier to treat them all
>> > as "require system_reset to recover".
>>
>> In any case, we need to tag the current state as stopped-and-invalid or
>> so vs. a normal stop. That remains a valuable first step. How to deal
>> with that information is the second one.

I think the right way to fix this is to disable 'cont' until a
system_reset is issued. 'cont' should not perform reset but print an
error message about inconsistent state and suggest issuing a
'system_reset'.

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Sat, 30 Jul 2011 10:41:48 +0300
Blue Swirl <blauwirbel@gmail.com> wrote:

> On Thu, Jul 28, 2011 at 9:22 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > On Thu, 28 Jul 2011 20:04:58 +0200
> > Jan Kiszka <jan.kiszka@web.de> wrote:
> >
> >> On 2011-07-28 20:00, Luiz Capitulino wrote:
> >> > On Thu, 28 Jul 2011 19:52:31 +0200
> >> > Jan Kiszka <jan.kiszka@web.de> wrote:
> >> >
> >> >> On 2011-07-28 19:48, Luiz Capitulino wrote:
> >> >>> On Thu, 28 Jul 2011 14:39:23 -0300
> >> >>> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> >> >>>
> >> >>>> On Thu, 28 Jul 2011 17:20:41 +0200
> >> >>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> >> >>>>
> >> >>>>> On 2011-07-28 17:18, Luiz Capitulino wrote:
> >> >>>>>> On Thu, 28 Jul 2011 16:19:19 +0200
> >> >>>>>> Jan Kiszka <jan.kiszka@web.de> wrote:
> >> >>>>>>
> >> >>>>>>> On 2011-07-28 15:37, Avi Kivity wrote:
> >> >>>>>>>> On 07/28/2011 04:31 PM, Luiz Capitulino wrote:
> >> >>>>>>>>> On Thu, 28 Jul 2011 10:23:22 +0300
> >> >>>>>>>>> Avi Kivity<avi@redhat.com>  wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>>  On 07/28/2011 12:44 AM, Blue Swirl wrote:
> >> >>>>>>>>>>  >  On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> >> >>>>>>>>> Capitulino<lcapitulino@redhat.com>   wrote:
> >> >>>>>>>>>>  >  >   This function should be used when the VM is not supposed to
> >> >>>>>>>>> resume
> >> >>>>>>>>>>  >  >   execution (eg. by issuing 'cont' monitor command).
> >> >>>>>>>>>>  >  >
> >> >>>>>>>>>>  >  >   Today, we allow the user to resume execution even when:
> >> >>>>>>>>>>  >  >
> >> >>>>>>>>>>  >  >     o the guest shuts down and -no-shutdown is used
> >> >>>>>>>>>>  >  >     o there's a kvm internal error
> >> >>>>>>>>>>  >  >     o loading the VM state with -loadvm or "loadvm" in the
> >> >>>>>>>>> monitor fails
> >> >>>>>>>>>>  >  >
> >> >>>>>>>>>>  >  >   I think only badness can happen from the cases above.
> >> >>>>>>>>>>  >
> >> >>>>>>>>>>  >  I'd suppose a system_reset should bring the system back to
> >> >>>>>>>>> sanity and
> >> >>>>>>>>>>  >  then clear vm_permanent_stopped (where's -ly?)
> >> >>>>>>>>>
> >> >>>>>>>>> What's -ly?
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> permanent-ly.
> >> >>>>>>>>
> >> >>>>>>>>>>  >  except maybe for KVM
> >> >>>>>>>>>>  >  internal error if that can't be recovered. Then it would not very
> >> >>>>>>>>>>  >  permanent anymore, so the name would need adjusting.
> >> >>>>>>>>>>
> >> >>>>>>>>>>  Currently, all kvm internal errors are recoverable by reset (and
> >> >>>>>>>>>>  possibly by fiddling with memory/registers).
> >> >>>>>>>>>
> >> >>>>>>>>> Ok, but a poweroff in the guest isn't recoverable with system_reset
> >> >>>>>>>>> right? Or does it depend on the guest?
> >> >>>>>>>>
> >> >>>>>>>> Right, it's not recoverable if you shut the power down where the tractor
> >> >>>>>>>> beam is coupled to the main reactor.
> >> >>>>>>>
> >> >>>>>>> system_reset will bring all emulated devices back into their power-on
> >> >>>>>>> state - unless we have remaining bugs to fix. Actually, one may consider
> >> >>>>>>> issuing this reset automatically on vm_start after "permant" vm_stop.
> >> >>>>
> >> >>>> The only permanent vm_stop we'd have is poweroff when -no-shutdown is used.
> >> >>>>
> >> >>>> Are you saying that system_reset should be able to recover from that too?
> >> >>>
> >> >>> It already does, so we don't have permanent stops.
> >> >>
> >> >> Exactly. We just have stops over inconsistent states that require a
> >> >> reset to continue with anything useful.
> >> >
> >> > Yes. If I got you right, you suggest that we do the reset automatically.
> >> >
> >> > I think it's better to let the user do it, because s/he might want to
> >> > do something else before resetting. For example, for the kvm error the
> >> > user might want to save the vm state.
> >>
> >> Associating the reset with a cont means requesting an explicit action
> >> from the user. I'm not suggesting to do the reset when the stop state is
> >> entered.
> >
> > I see. But automatically resetting on cont might be unexpected to the
> > user, even on a bad state.
> >
> > Another option would be to add a force option to cont, where the reset is
> > done when the state is invalid (otherwise cont will return an error).
> >
> > I still prefer to let the user do it manually though.
> >
> >> > For the poweroff case with -no-shutdown it's probably fine, but I don't
> >> > want to hard code special cases. It's better and easier to treat them all
> >> > as "require system_reset to recover".
> >>
> >> In any case, we need to tag the current state as stopped-and-invalid or
> >> so vs. a normal stop. That remains a valuable first step. How to deal
> >> with that information is the second one.
> 
> I think the right way to fix this is to disable 'cont' until a
> system_reset is issued. 'cont' should not perform reset but print an
> error message about inconsistent state and suggest issuing a
> 'system_reset'.

That's exactly what the series I'm working on does, although the error
message is not explicit about issuing a system_reset (will change).

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Daniel P. Berrange]

On Thu, Jul 28, 2011 at 10:31:43AM -0300, Luiz Capitulino wrote:
> On Thu, 28 Jul 2011 10:23:22 +0300
> Avi Kivity <avi@redhat.com> wrote:
> 
> > On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > > On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino<lcapitulino@redhat.com>  wrote:
> > > >  This function should be used when the VM is not supposed to resume
> > > >  execution (eg. by issuing 'cont' monitor command).
> > > >
> > > >  Today, we allow the user to resume execution even when:
> > > >
> > > >    o the guest shuts down and -no-shutdown is used
> > > >    o there's a kvm internal error
> > > >    o loading the VM state with -loadvm or "loadvm" in the monitor fails
> > > >
> > > >  I think only badness can happen from the cases above.
> > >
> > > I'd suppose a system_reset should bring the system back to sanity and
> > > then clear vm_permanent_stopped (where's -ly?)
> 
> What's -ly?
> 
> > > except maybe for KVM
> > > internal error if that can't be recovered. Then it would not very
> > > permanent anymore, so the name would need adjusting.
> > 
> > Currently, all kvm internal errors are recoverable by reset (and 
> > possibly by fiddling with memory/registers).
> 
> Ok, but a poweroff in the guest isn't recoverable with system_reset
> right? Or does it depend on the guest?
> 
> I get funny results if qemu is started with -no-shutdown and I run cont after
> a poweroff in a F15 guest. Sometimes qemu will exit after a few seconds,
> sometimes 'info status' will say 'running'.

libvirt uses this approach to fake a controlled soft reboot of guests.
eg

  $ qemu .... -no-shutdown
  ...some time later...
  system_shutdown
  ...wait for SHUTDOWN event...
  system_reset
  cont

Previous releases of QEMU had a bug in some device backends which would
cause a crash sometimes, but in general it ought to work IMHO.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [RFC] Introduce vm_stop_permanent()

[Luiz Capitulino]

On Tue, 2 Aug 2011 11:22:15 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Thu, Jul 28, 2011 at 10:31:43AM -0300, Luiz Capitulino wrote:
> > On Thu, 28 Jul 2011 10:23:22 +0300
> > Avi Kivity <avi@redhat.com> wrote:
> > 
> > > On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > > > On Wed, Jul 27, 2011 at 9:42 PM, Luiz Capitulino<lcapitulino@redhat.com>  wrote:
> > > > >  This function should be used when the VM is not supposed to resume
> > > > >  execution (eg. by issuing 'cont' monitor command).
> > > > >
> > > > >  Today, we allow the user to resume execution even when:
> > > > >
> > > > >    o the guest shuts down and -no-shutdown is used
> > > > >    o there's a kvm internal error
> > > > >    o loading the VM state with -loadvm or "loadvm" in the monitor fails
> > > > >
> > > > >  I think only badness can happen from the cases above.
> > > >
> > > > I'd suppose a system_reset should bring the system back to sanity and
> > > > then clear vm_permanent_stopped (where's -ly?)
> > 
> > What's -ly?
> > 
> > > > except maybe for KVM
> > > > internal error if that can't be recovered. Then it would not very
> > > > permanent anymore, so the name would need adjusting.
> > > 
> > > Currently, all kvm internal errors are recoverable by reset (and 
> > > possibly by fiddling with memory/registers).
> > 
> > Ok, but a poweroff in the guest isn't recoverable with system_reset
> > right? Or does it depend on the guest?
> > 
> > I get funny results if qemu is started with -no-shutdown and I run cont after
> > a poweroff in a F15 guest. Sometimes qemu will exit after a few seconds,
> > sometimes 'info status' will say 'running'.
> 
> libvirt uses this approach to fake a controlled soft reboot of guests.
> eg
> 
>   $ qemu .... -no-shutdown
>   ...some time later...
>   system_shutdown
>   ...wait for SHUTDOWN event...
>   system_reset
>   cont
> 
> Previous releases of QEMU had a bug in some device backends which would
> cause a crash sometimes, but in general it ought to work IMHO.

Yes, you're doing a system_reset before cont, that's ok.

The problem happens when you issue cont w/o issuing system_reset first.