Re: [Qemu-devel] [PATCH] vl.c: make default main_loop_wait() timeout independed of slirp

[Stefan Hajnoczi]

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 <address@hidden> 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