Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS

[Samuel Thibault]

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
http://xenbits.xensource.com/git-http/qemu-xen-unstable.git

> >>>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
> >case.
> 
> 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
> block-raw-xen-pv-block-frontend?

That's it.

> 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.

Samuel