Avi Kivity, le Thu 26 Mar 2009 20:32:28 +0200, a écrit :
> Samuel Thibault wrote:
> >Avi Kivity, le Thu 26 Mar 2009 14:58:55 +0200, a écrit :
> >>Samuel Thibault wrote:
> >>>it should be centralized in the block layer instead of placing the
> >>>burden on all block format drivers ;)
> >>If other drivers need to do that, certainly.
> >In our case the other driver is specific to Xen.
> I'm confused. I can only count one driver which has limited dma size.
Then you are not looking at the same place as I am. The Xen tree is at
> >>>One thing for instance that still have been overlooked although patches
> >>>have been sent is block-raw-posix' read/write_pread_aligned() that
> >>>consider partial read/writes as an error. That's a bug.
> >>Right. Unrelated topic though?
> >Nope. It's exactly the issue: read/write() may not be able to perform
> >the whole operation in just one go, and qemu should continue in that
> Oh, you're overloading block-raw-posix?
I'm not. Actually, I am _also_ implementing the read/write() functions,
but that's another matter. In the xen tree, there is an addition
block-vbd.c driver. I'm here just pointing out that the problem is not
_only_ in the xen-specific driver, but also in the posix driver, on any
OS that doesn't necessarily do all the work the caller asked for (which
is _allowed_ by POSIX).
> Isn't it more natural for you to implement
> You'd be able to use asynchronous requests instead of a thread pool
> (much like block-raw-linux-aio).
That's it. But the xen ring protocols limits the amount of data
transferred at a time, thus the limitation.