On 7/28/06, Rik van Riel <ri...@redhat.com> wrote:
Rik van Riel wrote:
Rik van Riel wrote:
Any comments on this patch?
I got some comments from Alan, who would like to see this behaviour
tunable with hdparm from inside the guest. This requires larger
qemu changes though, to be specific an ->fsync callback into each
of the backing store drivers, so that is something for the qemu
mailing list.
Considering the AIO-based development going on in the qemu community,
I think we should stick with the O_SYNC band-aid. The idea Alan
described would just be a fancier band-aid.
Another possibility would be to integrate blktap/tapdisk into qemu
which will provide asynchronous completion events and hides the
immediate AIO interaction from qemu. This should also make using qemu
inside a stub domain easier since the code to talk to tapdisk will be
very similar to the blkfront code. Also, this is somewhat required to
use tap devices for HVM domains, the alternative of using blkfront
within dom0 to export the device for qemu to use doesn't sound too
appealing.
Do you fancy looking into this?
The current bottleneck seems to be that MAX_MULT_COUNT is only 16.
Upon closer inspection of the code, this seems to not be the case for
LBA48 transfers.
Any other ideas what could be the bottleneck then?
christian
7 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH][RFC] open HVM...
.patch