summaryrefslogtreecommitdiff
path: root/hw/qxl.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 /hw/qxl.c
parentd9cd446b4f6ff464f9520898116534de988d9bc1 (diff)
downloadqemu-12d4536f7d911b6d87a766ad7300482ea663cea2.tar.gz
qemu-12d4536f7d911b6d87a766ad7300482ea663cea2.tar.bz2
qemu-12d4536f7d911b6d87a766ad7300482ea663cea2.zip
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 'hw/qxl.c')
-rw-r--r--hw/qxl.c4
1 files changed, 0 insertions, 4 deletions
diff --git a/hw/qxl.c b/hw/qxl.c
index 1d9077db68..45e24016fc 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1388,11 +1388,7 @@ static void init_pipe_signaling(PCIQXLDevice *d)
dprint(d, 1, "%s: pipe creation failed\n", __FUNCTION__);
return;
}
-#ifdef CONFIG_IOTHREAD
fcntl(d->pipe[0], F_SETFL, O_NONBLOCK);
-#else
- fcntl(d->pipe[0], F_SETFL, O_NONBLOCK /* | O_ASYNC */);
-#endif
fcntl(d->pipe[1], F_SETFL, O_NONBLOCK);
fcntl(d->pipe[0], F_SETOWN, getpid());