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

[Avi Kivity]

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.