Avi Kivity wrote: > On 07/25/2012 02:12 PM, Stefano Stabellini wrote: > > On Wed, 25 Jul 2012, Michael Tokarev wrote: > >> Stefano, Paul, can you take a look please? > >> > >> https://bugs.launchpad.net/bugs/1021649 > > > > That is a very good bug triage that you did! > > > > However "main_loop_wait: block indefinitely" only increases the maximum > > select timeout of QEMU's main_loop. > > That mean that if one or more emulators have bugs and don't get > > notifications correctly they might hang. > > The reason why it only reproduces with nographic is that both sdl and vnc > > introduce a gui_timer that wakes QEMU up every 30ms. > > > > So the question is: why is kernel_irqchip=on required to repro the bug? > > It strikes me as a bug in kernel_irqchip that prevents QEMU from being > > waken up when it should. > > kernel_irqchip=on means that many guest timers and interrupt sources are > removed from qemu and implemented in the kernel, so qemu sees a lot less > wakeups and hangs. With kernel_irqchip=off the APIC or PIT wakes up > qemu, taking the place of the keypress.
You're not implying the key press waking up qemu was a planned thing are you? Becuase it doesn't work at all when console is a -chardev pty device. With -machine kernel_irqchip=on -display none -chardev pty,... qemu simply hangs and consumes as much cpu as it can, attaching to the terminal and sending data does nothing. I'd hate to think that's the new normal. -- Jamie Heilman http://audible.transient.net/~jamie/