From: Igor Mammedov <imammedo@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org,
pkrempa@redhat.com, ehabkost@redhat.com, cohuck@redhat.com,
armbru@redhat.com, pbonzini@redhat.com,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH v3 5/9] QAPI: allow to specify valid runstates per command
Date: Thu, 8 Mar 2018 16:55:15 +0100 [thread overview]
Message-ID: <20180308165515.5f6b6c9a@redhat.com> (raw)
In-Reply-To: <20180307141648.GC3090@work-vm>
On Wed, 7 Mar 2018 14:16:50 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Igor Mammedov (imammedo@redhat.com) wrote:
> > Add optional 'runstates' parameter in QAPI command definition,
> > which will permit to specify RunState variations in which
> > a command could be exectuted via QMP monitor.
> >
> > For compatibility reasons, commands, that don't use
> > 'runstates' explicitly, are not permited to run in
> > preconfig state but allowed in all other states.
> >
> > New option will be used to allow commands, which are
> > prepared/need to run this early, to run in preconfig state.
> > It will include query-hotpluggable-cpus and new set-numa-node
> > commands. Other commands that should be able to run in
> > preconfig state, should be ammeded to not expect machine
> > in initialized state.
> >
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
[...]
> > @@ -224,6 +224,25 @@ static mon_cmd_t mon_cmds[];
> > static mon_cmd_t info_cmds[];
> >
> > QmpCommandList qmp_commands, qmp_cap_negotiation_commands;
> > +const RunState cap_negotiation_valid_runstates[] = {
> > + RUN_STATE_DEBUG,
> > + RUN_STATE_INMIGRATE,
> > + RUN_STATE_INTERNAL_ERROR,
> > + RUN_STATE_IO_ERROR,
> > + RUN_STATE_PAUSED,
> > + RUN_STATE_POSTMIGRATE,
> > + RUN_STATE_PRELAUNCH,
> > + RUN_STATE_FINISH_MIGRATE,
> > + RUN_STATE_RESTORE_VM,
> > + RUN_STATE_RUNNING,
> > + RUN_STATE_SAVE_VM,
> > + RUN_STATE_SHUTDOWN,
> > + RUN_STATE_SUSPENDED,
> > + RUN_STATE_WATCHDOG,
> > + RUN_STATE_GUEST_PANICKED,
> > + RUN_STATE_COLO,
> > + RUN_STATE_PRECONFIG,
> > +};
>
> It's a shame this is such a manual copy.
>
> While you're taking a big hammer to HMP in the preconfig case,
> it's worth noting this more specific code is only protecting QMP
> commands.
>
>
> It's a shame in all the uses below we can't be working with bitmasks
> of run-state's; it would feel a lot easier to have a default and mask
> out or or in extra states.
>
> Dave
[...]
> > @@ -219,7 +219,11 @@
> > # Note: This example has been shortened as the real response is too long.
> > #
> > ##
> > -{ 'command': 'query-commands', 'returns': ['CommandInfo'] }
> > +{ 'command': 'query-commands', 'returns': ['CommandInfo'],
> > + 'runstates': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
> > + 'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> > + 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
> > + 'guest-panicked', 'colo', 'preconfig' ] }
>
> That's going to get to be a pain to update as we add more states.
[...]
Yep it would be a pain so,
In v4 this approach/patch is replaced by a simpler one that Eric's suggested.
It will provide preconfig specific flag in command, similar to what allow-oob
patches on list do. So it would look like following:
------------------------ docs/devel/qapi-code-gen.txt -------------------------
index 25b7180..170f15f 100644
@@ -556,7 +556,8 @@ following example objects:
Usage: { 'command': STRING, '*data': COMPLEX-TYPE-NAME-OR-DICT,
'*returns': TYPE-NAME, '*boxed': true,
- '*gen': false, '*success-response': false }
+ '*gen': false, '*success-response': false,
+ '*allowed-in-preconfig': true }
Commands are defined by using a dictionary containing several members,
where three members are most common. The 'command' member is a
@@ -636,6 +637,13 @@ possible, the command expression should include the optional key
'success-response' with boolean value false. So far, only QGA makes
use of this member.
+A command may use optional 'allowed-in-preconfig' key to permit
+its execution at early runtime configuration stage (preconfig runstate).
+If not specified then a command defaults to 'allowed-in-preconfig: false'.
+
+An example of declaring preconfig enabled command:
+ { 'command': 'qmp_capabilities',
+ 'allowed-in-preconfig': true }
next prev parent reply other threads:[~2018-03-08 15:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-16 12:37 [Qemu-devel] [PATCH v3 0/9] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 1/9] numa: postpone options post-processing till machine_run_board_init() Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 2/9] numa: split out NumaOptions parsing into parse_NumaOptions() Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 3/9] CLI: add -preconfig option Igor Mammedov
2018-02-27 20:39 ` Eric Blake
2018-02-28 15:54 ` Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 4/9] HMP: disable monitor in preconfig state Igor Mammedov
2018-03-07 14:01 ` Dr. David Alan Gilbert
2018-03-08 15:47 ` Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 5/9] QAPI: allow to specify valid runstates per command Igor Mammedov
2018-02-27 22:10 ` Eric Blake
2018-02-28 16:17 ` Igor Mammedov
2018-03-07 14:16 ` Dr. David Alan Gilbert
2018-03-08 15:55 ` Igor Mammedov [this message]
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 6/9] tests: extend qmp test with pereconfig checks Igor Mammedov
2018-02-27 22:13 ` Eric Blake
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 7/9] QMP: permit query-hotpluggable-cpus in preconfig state Igor Mammedov
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 8/9] QMP: add set-numa-node command Igor Mammedov
2018-02-27 22:17 ` Eric Blake
2018-02-16 12:37 ` [Qemu-devel] [PATCH v3 9/9] tests: functional tests for QMP command set-numa-node Igor Mammedov
2018-02-27 22:19 ` Eric Blake
2018-02-27 16:36 ` [Qemu-devel] [PATCH v3 0/9] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-02-27 20:29 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180308165515.5f6b6c9a@redhat.com \
--to=imammedo@redhat.com \
--cc=armbru@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).