Re: dma_mapping_ops for i386

[Jeremy Fitzhardinge <jeremy@goop.org>]

Andi Kleen wrote:
> On Wednesday 27 June 2007 16:15:17 Jeremy Fitzhardinge wrote:
>   
> > Andi Kleen wrote:
> >     
> > > Ok, if you can do it without ifdefs. 
> > >   
> > >       
> > That should be OK.  All the existing i386 mapping operations would just 
> > have their own ops structure, right?
> >     
>
> I just mention it because many people's ideas of merging files
> seem to add lots of ifdefs which is imho the totally wrong thing
> to do.
>
>   
> > > And no swiotlb on i386; that is something that is completely broken
> > > in upstream Xen and needs to be fixed properly anyways.
> > >   
> > >       
> > Hm, OK.  I'm not really familiar with the issues here.  What are they?  
> > Looks like Jan has made a number of Xen-ish changes to lib/swiotlb.c; 
> > are more changes be needed?
> >     
>
> See the recent "quiet down swiotlb warnings" thread which uncovered
> quite some corpses in Xen's current IO setup.
>
> Xen apparently bounces for multi page IOs which get merged from block
> lists because the block layer doesn't know they are not really 
> continuous in machine memory.
>
> Proper fix is to tell the block layer to not merge in the first
> place instead.
>
> And probably some similar mechanism for network drivers that limits
> MTUs.
>   

Well, I think there are two issues here.  One is that two 
pseudo-physical pages won't necessarily be contigious in bus space, 
because of the pseudo-phys to machine mapping.

The second problem is that devices which can't address all machine 
physical memory (ie, 32-bit PCI devices on machines with >4G memory) 
will need to have bouncebuffers established for them.  Device drivers 
won't necessarily be able to do it because they're not really aware of 
machine addresses.

> Maybe we'll still need a simple bouncing mechanism for other obscure
> devices with large IOs then, but I would very much prefer if it wasn't 
> swiotlb and could be solved some other way.
>   

I think 32-bit-only devices are a bigger concern, no?

   J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/