The QEMU code that we use doesn't go through the dom0 buffer cache, we modified 
the
code to use O_DIRECT. Can't user buffer cache and accelerated drivers (they go 
right
to the disk) together, it can cause disk corruption. The performance numbers 
we get
from this version of QEMU is still 4 to 6 times slower that native disk I/O.

I doubt O_DIRECT buys you much in the way of performance -- as you say
it's just a correctness thing. Still, the qemu block code is all
completely synchronous -- the fact that you simply can't have more
than a single outstanding block request at a time is going to
seriously harm performance. As Anthony explained, some form of
asynchronous IO in the qemu drivers would clearly improve performance.

You might be right, however even with pipelining and async I/O, I don't think 
it is going to get close to native I/O numbers. I guess we'll just have to wait
and see.

I'd expect that disk can be made to perform reasonably well with qemu,
using dma emulation and async IO. The old vmware workstation paper on
device virtualization does a pretty good job of demonstrating that
trap and emulate device access sucks, and would seem to imply that
it's pretty unlikely to be practical for high-rate networking.
a.
[1] http://www.usenix.org/event/usenix01/sugerman/sugerman.pdf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel