On 08/22/2011 08:50 AM, Peter Maydell wrote:
On 22 August 2011 14:24, Anthony Liguori<aligu...@us.ibm.com> wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
currently requires a (racey) signal based alarm system.
Even with iothread it's still signal based (and still racy) -- the only way
to get a thread currently executing TCG code to stop doing so is to send it
a signal.
What I meant is that we use SIGALRM to effectively do preemptive
multiple tasking between the VCPU thread and the I/O thread.
We still need to use signals with the I/O thread because we run the two
in lock step. The race I was referring to with SIGALRM has to do with a
guest disabling timer interrupts and any other event source. It'll
cause a live lock in TCG.
The only way to fix this is by moving to the I/O thread or setting SIGIO
on every fd. Since every fd doesn't support SIGIO, I/O thread is really
the only correct solution.
Regards,
Anthony Liguori
-- PMM
