aboutsummaryrefslogtreecommitdiff
path: root/vl.c
diff options
context:
space:
mode:
authorAnthony Liguori <aliguori@us.ibm.com>2011-08-22 08:24:58 -0500
committerAnthony Liguori <aliguori@us.ibm.com>2011-09-02 10:34:55 -0500
commit12d4536f7d911b6d87a766ad7300482ea663cea2 (patch)
tree848fe9cb11b82145fae05ee05aace4f90a3564af /vl.c
parentd9cd446b4f6ff464f9520898116534de988d9bc1 (diff)
main: force enabling of I/O thread
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. I know there have been concerns about performance. I think so far the ones that have come up (virtio-net) are most likely due to secondary reasons like decreased batching. I think we ought to force enabling I/O thread early in 1.0 development and commit to resolving any lingering issues. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'vl.c')
-rw-r--r--vl.c18
1 files changed, 0 insertions, 18 deletions
diff --git a/vl.c b/vl.c
index 60bce0cc71..7a6fbacee5 100644
--- a/vl.c
+++ b/vl.c
@@ -1445,17 +1445,6 @@ int main_loop_wait(int nonblocking)
return ret;
}
-#ifndef CONFIG_IOTHREAD
-static int vm_request_pending(void)
-{
- return powerdown_requested ||
- reset_requested ||
- shutdown_requested ||
- debug_requested ||
- vmstop_requested;
-}
-#endif
-
qemu_irq qemu_system_powerdown;
static void main_loop(void)
@@ -1470,14 +1459,7 @@ static void main_loop(void)
qemu_main_loop_start();
for (;;) {
-#ifdef CONFIG_IOTHREAD
nonblocking = !kvm_enabled() && last_io > 0;
-#else
- nonblocking = cpu_exec_all();
- if (vm_request_pending()) {
- nonblocking = true;
- }
-#endif
#ifdef CONFIG_PROFILER
ti = profile_getclock();
#endif