On Tue, Jun 05, 2018 at 09:47:44AM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 05, 2018 at 10:27:03AM +0200, Igor Mammedov wrote: > > On Mon, 4 Jun 2018 22:04:13 -0300 > > Eduardo Habkost <[email protected]> wrote: > > > > > 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? > > I've meant that there is no reason for infinite timeuot, > > and 1sec is good as any other finite one. > > I don't really agree - it is better to not wakeup at all if there's > no work todo rather than pointlessly wake up once a second, to deal > with a hack for the SLIRP feature that's almost never used in most > production scenarios..
Right, a host with 1000 VMs should experience 1000 wakeups/second for no good reason. QEMU needs to be scalable. Stefan
signature.asc
Description: PGP signature
