On Mon, Jun 04, 2018 at 10:14:38PM +0200, Igor Mammedov wrote: > Since commit (047f7038f58 cli: add --preconfig option) QEMU is > stuck with indefinite timeout in os_host_main_loop_wait() > at RUN_STATE_PRECONFIG even if --preconfig option wasn't used > when it's started with -nodefaults CLI option like this: > > ./s390x-softmmu/qemu-system-s390x -nodefaults > > It's caused by the fact that slirp_pollfds_fill() bails out early > and slirp_update_timeout() won't be called to update timeout > to a reasonable value (1 sec) so timeout would be left with > infinite value (0xFFFFFFFF). > > Default infinite timeout though doen't make sense and reducing > it to 1 second as in slirp_update_timeout() won't affect host.
I don't get this part. Why default infinite timeout doesn't make sense? Why would a 1 second timeout make sense? > Fix issue by simplifying default timeout to the same 1sec as it > is in slirp_update_timeout() and cleanup the later. It makes > default timeout the same regardless of slirp_pollfds_fill() > exited early or not (i.e. -nodefaults won't have any effect on > main_loop_wait() anymore, which would provide more consistent > behavior between both variants of startup). > > Reported-by: Lukáš Doktor <[email protected]> > Signed-off-by: Igor Mammedov <[email protected]> > --- > PS: > it doesn't fix issue reported by Max where > "echo foo | $QEMU" > is also broken due to commit 047f7038f58, but there is antoher fix > on the list to fix that (either Michal's or Daniel's). [...] -- Eduardo
