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

[Samuel Thibault]

Avi Kivity, le Thu 26 Mar 2009 21:40:18 +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
> >  
> 
> I wasn't looking at any tree.  I count one driver with limited DMA sizes 
> - block-vbd.  What's the other one?

Ah, I thought you understood that the posix driver has the same kind of
limitation (and qemu is actually _bugged_ in that regard).

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

Sure, and I could do the same in the block-vbd driver, thus then my
original remark "it should be centralized in the block layer instead of
placing the burden on all block format drivers".  Just to make sure: I'm
_not_ saying that should be done in the DMA code.  I said it should be
done in the block layer, shared by all block drivers.

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

Why making it "late"?  Exposing the lower limits to let upper layers
decide how they should manage fragmentation usually gets better
performance.  (Note that in my case there is no system involved, so it's
really _not_ costly to do the fragmentation on the qemu side).

Samuel