Messages in this thread | | | Date | Wed, 27 Jun 2007 14:40:21 -0400 | From | Jeremy Fitzhardinge <> | Subject | Re: dma_mapping_ops for i386 |
| |
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/
| |