diff mbox series

[RFC,5/9] qapi: Implement 'next-machine-phase' command

Message ID 20210513082549.114275-6-mirela.grujic@greensocs.com
State New
Headers show
Series Initial support for machine creation via QMP | expand

Commit Message

Mirela Grujic May 13, 2021, 8:25 a.m. UTC
This command will be used to control via QMP the advancing of machine
through initialization phases. The feature is needed to enable the
machine configuration via QMP.

The command triggers QEMU to advance the machine to the next init phase,
i.e. to execute initialization steps required to enter the next phase.
The command is used in combination with -preconfig command line option.

Note: advancing the machine to the final phase has the same effect as
executing 'x-exit-preconfig' command.

Signed-off-by: Mirela Grujic <mirela.grujic@greensocs.com>
---
 qapi/machine.json          | 24 ++++++++++++++++++++++++
 include/sysemu/sysemu.h    |  3 +++
 hw/core/machine-qmp-cmds.c | 12 ++++++++++++
 softmmu/vl.c               |  3 +--
 4 files changed, 40 insertions(+), 2 deletions(-)

Comments

Eric Blake June 4, 2021, 2:25 p.m. UTC | #1
On Thu, May 13, 2021 at 10:25:45AM +0200, Mirela Grujic wrote:
> This command will be used to control via QMP the advancing of machine
> through initialization phases. The feature is needed to enable the
> machine configuration via QMP.
> 
> The command triggers QEMU to advance the machine to the next init phase,
> i.e. to execute initialization steps required to enter the next phase.
> The command is used in combination with -preconfig command line option.
> 
> Note: advancing the machine to the final phase has the same effect as
> executing 'x-exit-preconfig' command.
> 
> Signed-off-by: Mirela Grujic <mirela.grujic@greensocs.com>
> ---
>  qapi/machine.json          | 24 ++++++++++++++++++++++++
>  include/sysemu/sysemu.h    |  3 +++
>  hw/core/machine-qmp-cmds.c | 12 ++++++++++++
>  softmmu/vl.c               |  3 +--
>  4 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 47bdbec817..968d67dd95 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -1328,3 +1328,27 @@
>  ##
>  { 'command': 'query-machine-phase', 'returns': 'MachineInitPhaseStatus',
>               'allow-preconfig': true }
> +
> +##
> +# @next-machine-phase:
> +#
> +# Increment machine initialization phase
> +#
> +# Since: #FIXME

You can put 6.1 instead of #FIXME if that's what you're aiming for
(but then you may have to adjust it to 6.2 if it misses soft
freeze...)

> +#
> +# Returns: If successful, nothing

This sentence doesn't add much.

> +#
> +# Notes: This command will trigger QEMU to execute initialization steps
> +#        that are required to enter the next machine initialization phase.
> +#        If by incrementing the initialization phase the machine reaches
> +#        the final phase, the guest will start running immediately unless
> +#        the -S option is used. The command is available only if the
> +#        -preconfig command line option was passed.
> +#
> +# Example:
> +#
> +# -> { "execute": "next-machine-phase" }
> +# <- { "return": {} }

As an API, this command seems awkward.  How do I query what phase I'm
currently in?  How many times do I have to call it?  Do we anticipate
the number of times I need to call it to change in future qemu
releases?

Would it be better to require me to pass an enum parameter stating the
phase I intend to move into (and error out if that is not actually the
next phase), where the introspection of the enum tells me how many
times to use this command?  Should this command return a struct
containing "new-state":"enum-value" telling me what state I moved to
on success?
Paolo Bonzini June 5, 2021, 2:40 p.m. UTC | #2
Il ven 4 giu 2021, 16:26 Eric Blake <eblake@redhat.com> ha scritto:

> As an API, this command seems awkward.  How do I query what phase I'm
> currently in?  How many times do I have to call it?  Do we anticipate
> the number of times I need to call it to change in future qemu
> releases?
>

Indeed this has been changed in the last version of the proposal. There
will be an x-machine-init command and the existing x-exit-preconfig.

Paolo


> Would it be better to require me to pass an enum parameter stating the
> phase I intend to move into (and error out if that is not actually the
> next phase), where the introspection of the enum tells me how many
> times to use this command?  Should this command return a struct
> containing "new-state":"enum-value" telling me what state I moved to
> on success?
>
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>
>
diff mbox series

Patch

diff --git a/qapi/machine.json b/qapi/machine.json
index 47bdbec817..968d67dd95 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -1328,3 +1328,27 @@ 
 ##
 { 'command': 'query-machine-phase', 'returns': 'MachineInitPhaseStatus',
              'allow-preconfig': true }
+
+##
+# @next-machine-phase:
+#
+# Increment machine initialization phase
+#
+# Since: #FIXME
+#
+# Returns: If successful, nothing
+#
+# Notes: This command will trigger QEMU to execute initialization steps
+#        that are required to enter the next machine initialization phase.
+#        If by incrementing the initialization phase the machine reaches
+#        the final phase, the guest will start running immediately unless
+#        the -S option is used. The command is available only if the
+#        -preconfig command line option was passed.
+#
+# Example:
+#
+# -> { "execute": "next-machine-phase" }
+# <- { "return": {} }
+#
+##
+{ 'command': 'next-machine-phase', 'allow-preconfig': true }
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 8fae667172..0df06d095d 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -2,6 +2,7 @@ 
 #define SYSEMU_H
 /* Misc. things related to the system emulator.  */
 
+#include "hw/qdev-core.h"
 #include "qemu/timer.h"
 #include "qemu/notify.h"
 #include "qemu/uuid.h"
@@ -20,6 +21,8 @@  void qemu_run_machine_init_done_notifiers(void);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 void qemu_remove_machine_init_done_notifier(Notifier *notify);
 
+void qemu_machine_enter_phase(MachineInitPhase target_phase, Error **errp);
+
 void configure_rtc(QemuOpts *opts);
 
 void qemu_init_subsystems(void);
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 23f837dadb..8aa743d59b 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -207,3 +207,15 @@  MachineInitPhaseStatus *qmp_query_machine_phase(Error **errp)
 
     return status;
 }
+
+void qmp_next_machine_phase(Error **errp)
+{
+    MachineInitPhase target_phase = phase_get() + 1;
+
+    if (target_phase >= MACHINE_INIT_PHASE__MAX) {
+        error_setg(errp, "Cannot increment machine init phase any further");
+        return;
+    }
+
+    qemu_machine_enter_phase(target_phase, errp);
+}
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 88f504aff9..0f402806f5 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2578,8 +2578,7 @@  static void qemu_machine_creation_done(void)
     }
 }
 
-static void qemu_machine_enter_phase(MachineInitPhase target_phase,
-                                     Error **errp)
+void qemu_machine_enter_phase(MachineInitPhase target_phase, Error **errp)
 {
     /* target phases before initialization are not handled here */
     if (target_phase < MACHINE_INIT_PHASE_INITIALIZED) {