On Tue, Feb 08, 2011 at 12:07:02PM +0100, Tristan Gingold wrote: > > On Feb 8, 2011, at 6:58 PM, Anthony Liguori wrote: > > > On 02/08/2011 04:06 AM, Aurelien Jarno wrote: > >> Yes, it's slow. But is it a problem? You assume that people use QEMU > >> only for emulating SMP platforms. This is a wrong assumption. Beside the > >> x86 target, only sparc really supports SMP emulation. > >> > > > > It's *not* just about performance. > > > > TCG requires a signal to break out of a tight chained TB loop. If you have > > a guest in a tight loop waiting for something external (like polling on a > > in-memory flag), the device emulation will not get to run until a signal is > > fired. > > > > Unless you set SIGIO on every file descriptor that selects polls on (and > > you can't because there are a number that just don't support SIGIO), then > > you have a race condition. > > A race condition ? Looks like you are describing a dead-lock. > > But the dead lock doesn't happen because of the timer which periodically > exits from TCG. Hence the performance issue. > > > This can be fixed by running TCG in a separate thread than select() and > > sending a signal to the TCG VCPU when select() returns (effectively SIGIO > > in userspace). > > > > This is exactly what the I/O thread does. > > > (Nobody was able to make it working on Windows - or nobody was interested in > ?) > Given the I/O thread is disabled by default, my guess is that nobody really see an interest in looking at that.
-- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
