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

[Avi Kivity <avi@redhat.com>]

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
>   

I wasn't looking at any tree.  I count one driver with limited DMA sizes 
- block-vbd.  What's the other one?  Forgive me for not cloning and 
rummaging in qemu-xen.

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

But that's not limited DMA (or at least, not limited up-front).  And 
it's easily corrected, place a while loop around preadv/pwritev, no need 
to split a request a priori somewhere up the stack.  IDE_MAX_DMA_BUFFER 
(or however it's called) wouldn't help here.

And it wouldn't be right for block-vbd - you should split your requests 
as late as possible, IMO.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.