From: Michal Privoznik <mprivozn@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
"Max Reitz" <mreitz@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] vl: don't use RUN_STATE_PRECONFIG unless --preconfig is given
Date: Mon, 4 Jun 2018 12:41:41 +0200 [thread overview]
Message-ID: <748b2e3a-194b-c769-f93b-04572cbf16d7@redhat.com> (raw)
In-Reply-To: <20180604103515.GE19749@redhat.com>
On 06/04/2018 12:35 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 12:33:04PM +0200, Max Reitz wrote:
>> On 2018-06-04 12:27, Daniel P. Berrangé wrote:
>>> The RUN_STATE_PRECONFIG state is not supposed to be reachable unless the
>>> --preconfig argument is given to QEMU, but when it was introduced in:
>>>
>>> commit 047f7038f586d2150f16c6d9ba9cfd0479f0f6ac
>>> Author: Igor Mammedov <imammedo@redhat.com>
>>> Date: Fri May 11 19:24:43 2018 +0200
>>>
>>> cli: add --preconfig option
>>>
>>> The global 'current_run_state' variable was changed to have an initial
>>> value of RUN_STATE_PRECONFIG regardless of whether --preconfig is given.
>>>
>>> It then relies on the main loop to toggle it back to RUN_STATE_PRELAUNCH
>>> when --preconfig is not given. This is racy because it means that there
>>> is a window where QEMU is in RUN_STATE_PRECONFIG despite --preconfig not
>>> being given. This can be seen with the failure:
>>>
>>> $ echo | x86_64-softmmu/qemu-system-x86_64 -monitor stdio
>>> QEMU 2.12.50 monitor - type 'help' for more information
>>> (qemu)
>>> HMP not available in preconfig state, use QMP instead
>>>
>>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
>>> ---
>>> vl.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> This indeed fixes the issue that the preconfig state is reachable
>> without --preconfig, but it still keeps the main loop being invoked
>> twice (which means that e.g. HMP will process a single character before
>> the main loop is actually really invoked:
>>
>> $ echo quit | x86_64-softmmu/qemu-system-x86_64 \
>> -drive file=/dev/null,if=ide,readonly=on -monitor stdio
>> QEMU 2.12.50 monitor - type 'help' for more information
>> (qemu) qqemu-system-x86_64: Initialization of device ide-hd failed:
>> Block node is read-only
>>
>> (Note the "q" before "qemu-system-x86_64"))
>>
>> (Naively,) I agree with Michal that the main loop should only be invoked
>> twice if --preconfig has been given, which is implemented by his patch:
>>
>> http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00367.html
>
> I think we probably need a combination of both patches for maximum safety.
Yes, looks like that. Except when your patch is merged then:
+ runstate_set(RUN_STATE_PRELAUNCH);
from my patch becomes unnecessary. So I'll wait for you to merge your
patch and then I can resend v2 of mine.
Michal
next prev parent reply other threads:[~2018-06-04 10:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 10:27 [Qemu-devel] [PATCH] vl: don't use RUN_STATE_PRECONFIG unless --preconfig is given Daniel P. Berrangé
2018-06-04 10:33 ` Max Reitz
2018-06-04 10:35 ` Daniel P. Berrangé
2018-06-04 10:35 ` Max Reitz
2018-06-04 10:41 ` Michal Privoznik [this message]
2018-06-04 11:58 ` Igor Mammedov
2018-06-04 12:05 ` Daniel P. Berrangé
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=748b2e3a-194b-c769-f93b-04572cbf16d7@redhat.com \
--to=mprivozn@redhat.com \
--cc=berrange@redhat.com \
--cc=imammedo@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@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).