From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: peter.maydell@linaro.org, pkrempa@redhat.com, cohuck@redhat.com,
qemu-devel@nongnu.org, armbru@redhat.com, pbonzini@redhat.com,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option
Date: Thu, 29 Mar 2018 13:43:03 +0200 [thread overview]
Message-ID: <20180329134303.548a864b@redhat.com> (raw)
In-Reply-To: <20180328192148.GR5046@localhost.localdomain>
On Wed, 28 Mar 2018 16:21:48 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Wed, Mar 28, 2018 at 01:48:35PM +0200, Igor Mammedov wrote:
> > On Tue, 27 Mar 2018 17:05:41 +0200
> > Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > > On Fri, 23 Mar 2018 18:25:08 -0300
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >
> > > > On Mon, Mar 12, 2018 at 02:11:09PM +0100, Igor Mammedov wrote:
> > > [...]
> > [...]
> > > > > @@ -1886,6 +1895,13 @@ static bool main_loop_should_exit(void)
> > > > > RunState r;
> > > > > ShutdownCause request;
> > > > >
> > > > > + if (preconfig_exit_requested) {
> > > > > + if (runstate_check(RUN_STATE_PRECONFIG)) {
> > > >
> > > > Is it possible to have preconfig_exit_request set outside of
> > > > RUN_STATE_PRECONFIG? When and why?
> > > preconfig_exit_requested is initialized with TRUE and
> > > in combo with '-inmigrate' we need this runstate check.
> > > it's the same as it was with
> > > { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
> > > which I probably should remove (I need to check it though)
> > [...]
> >
> > > > > @@ -4594,6 +4623,10 @@ int main(int argc, char **argv, char **envp)
> > > > > }
> > > > > parse_numa_opts(current_machine);
> > > > >
> > > > > + /* do monitor/qmp handling at preconfig state if requested */
> > > > > + main_loop();
> > > >
> > > > Wouldn't it be simpler to do "if (!preconfig) { main_loop(); }"
> > > > instead of entering main_loop() just to exit immediately?
> > > The thought didn't cross my mind, it might work and more readable
> > > as one doesn't have to jump into main_loop() to find out that
> > > it would exit immediately.
> > > I'll try to it on respin.
> > Well doing as suggested end ups more messy:
> >
> > @@static bool main_loop_should_exit(void)
> > ...
> > if (preconfig_exit_requested) {
> > runstate_set(RUN_STATE_PRELAUNCH);
> > return true;
> > }
> >
> > @@main
> > /* do monitor/qmp handling at preconfig state if requested */
> > if (!preconfig_exit_requested) {
> > main_loop();
> > } else if (runstate_check(RUN_STATE_PRECONFIG)) {
> > runstate_set(RUN_STATE_PRELAUNCH);
> > }
>
> This doesn't make sense to me. Why would we enter
> RUN_STATE_PRECONFIG state if -preconfig is not used at all?
because of RUN_STATE_PRECONFIG becomes new initial state of
our state machine where we start of (used to be RUN_STATE_PRELAUNCH)
Lets call it variant 1:
with this we have 2 possible transitions:
RUN_STATE_PRECONFIG -> RUN_STATE_PRELAUNCH (machine_init)
and
RUN_STATE_PRECONFIG -> RUN_STATE_INMIGRATE
ugly but it was the same with RUN_STATE_PRELAUNCH initial transition
Another variant 2, in case we switch to RUN_STATE_PRECONFIG only on -preconfig
transitions would be
RUN_STATE_PRELAUNCH -> RUN_STATE_PRECONFIG
(allow switch from initial to -preconfig)
RUN_STATE_PRECONFIG -> RUN_STATE_PRELAUNCH
while the last is valid transition, the 1st one isn't really
valid because of (beside of switching from initial state) it
allows bouncing back to RUN_STATE_PRECONFIG later.
If we consider only state machine transitions, I think it's
cleaner to start with variant 1 with the same
-inmigrate hack we already have (which potentially could
be fixed later), than allowing arbitrary bouncing to
RUN_STATE_PRECONFIG at later stage.
With this approach all processing before machine_init()
would run at RUN_STATE_PRECONFIG and then we would switch
to RUN_STATE_PRELAUNCH. Even though it is far reaching
goal but at least that's where we should be moving to
have sane initialization flow in vl.c
> > preconfig_exit_requested = false;
> > ...
> >
> > I'd prefer original v4 approach, where only main_loop_should_exit()
> > has to deal with state transitions and book-keeping.
>
> If the above is unavoidable, I agree. But I still don't
> understand we have to enter PRECONFIG state if the user didn't
> specify -preconfig.
>
next prev parent reply other threads:[~2018-03-29 11:43 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 13:11 [Qemu-devel] [PATCH v4 0/9] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 1/9] numa: postpone options post-processing till machine_run_board_init() Igor Mammedov
2018-03-23 20:34 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 2/9] numa: split out NumaOptions parsing into parse_NumaOptions() Igor Mammedov
2018-03-23 20:42 ` Eduardo Habkost
2018-03-23 20:49 ` Eric Blake
2018-03-23 21:09 ` Eduardo Habkost
2018-03-26 8:38 ` Laurent Vivier
2018-03-26 14:33 ` Eric Blake
2018-03-27 13:08 ` Igor Mammedov
2018-03-28 18:54 ` Eduardo Habkost
2018-03-29 13:05 ` Igor Mammedov
2018-03-29 16:31 ` Eduardo Habkost
2018-04-03 13:55 ` Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 3/9] cli: add -preconfig option Igor Mammedov
2018-03-23 21:02 ` Eric Blake
2018-03-23 21:05 ` Eduardo Habkost
2018-03-23 21:25 ` Eduardo Habkost
2018-03-27 15:05 ` Igor Mammedov
2018-03-28 11:48 ` Igor Mammedov
2018-03-28 19:21 ` Eduardo Habkost
2018-03-29 11:43 ` Igor Mammedov [this message]
2018-03-29 16:24 ` Eduardo Habkost
2018-04-03 14:32 ` Igor Mammedov
2018-04-03 15:31 ` Eduardo Habkost
2018-04-04 8:51 ` Igor Mammedov
2018-03-28 19:17 ` Eduardo Habkost
2018-03-29 13:01 ` Igor Mammedov
2018-03-29 16:57 ` Eduardo Habkost
2018-04-03 10:41 ` Peter Krempa
2018-04-03 13:49 ` Igor Mammedov
2018-04-03 13:52 ` Eduardo Habkost
2018-04-30 19:12 ` Dr. David Alan Gilbert
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 4/9] hmp: disable monitor in preconfig state Igor Mammedov
2018-03-23 21:27 ` Eduardo Habkost
2018-03-28 11:16 ` Igor Mammedov
2018-03-28 18:55 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 5/9] qapi: introduce new cmd option "allowed-in-preconfig" Igor Mammedov
2018-03-23 21:11 ` Eric Blake
2018-03-28 15:23 ` Igor Mammedov
2018-03-23 21:28 ` Eduardo Habkost
2018-03-28 12:29 ` Igor Mammedov
2018-03-28 19:30 ` Eduardo Habkost
2018-03-29 9:53 ` Igor Mammedov
2018-03-29 12:21 ` Eduardo Habkost
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 6/9] tests: extend qmp test with preconfig checks Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 7/9] qmp: permit query-hotpluggable-cpus in preconfig state Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 8/9] qmp: add set-numa-node command Igor Mammedov
2018-03-12 13:11 ` [Qemu-devel] [PATCH v4 9/9] tests: functional tests for QMP command set-numa-node Igor Mammedov
2018-04-17 14:13 ` [Qemu-devel] [PATCH v4 0/9] enable numa configuration before machine_init() from QMP Markus Armbruster
2018-04-17 14:27 ` Eduardo Habkost
2018-04-17 15:41 ` Igor Mammedov
2018-04-17 20:41 ` Eduardo Habkost
2018-04-18 7:08 ` Markus Armbruster
2018-04-19 8:00 ` Igor Mammedov
2018-04-19 19:42 ` Eduardo Habkost
2018-04-20 6:31 ` Markus Armbruster
2018-04-23 9:50 ` Igor Mammedov
2018-04-23 13:05 ` Eduardo Habkost
2018-04-23 16:55 ` Igor Mammedov
2018-04-23 20:45 ` Eduardo Habkost
2018-04-26 14:39 ` Igor Mammedov
2018-04-26 14:55 ` Eric Blake
2018-04-27 12:19 ` Igor Mammedov
2018-04-20 5:23 ` David Gibson
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=20180329134303.548a864b@redhat.com \
--to=imammedo@redhat.com \
--cc=armbru@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--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).