Re: [PATCH 0 of 9] swiotlb: use phys_addr_t for pages

[FUJITA Tomonori]

On Sun, 28 Dec 2008 11:34:19 +0100
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> 
> > > Note that the main complication wasnt even the small variations in 
> > > signatures, but the different _semantics_: one dma_mapping_ops 
> > > implementation passed in kernel-virtual addresses, the other physical 
> > > addresses. Unifying that was invasive and non-trivial, and it can 
> > > break
> > 
> > I guess that you are talking about the dma_map_single difference between 
> > x86_32 and x86_64. As far as I know, Only x64_64 uses physical address 
> > with dma_map_single.
> 
> yes - dma_map_single() has this signature:
> 
>  static inline dma_addr_t
>  dma_map_single(struct device *hwdev, void *ptr, size_t size, int direction)
> 
> on x86 dma_mapping_ops.map_single has this signature:
> 
>         dma_addr_t      (*map_single)(struct device *hwdev, phys_addr_t ptr,
>                                 size_t size, int direction);
> 
> ia64 and powerpc uses kernel-virt addresses for map_single(). So there's 
> material semantic differences between the dma_mapping_ops implementations.

I know. And as I wrote, as far as I know, only x86 use physical
addresses with map_single.

I think except for x86, all other archs use cpu addresses because we
define dma_map_single() in the following way:

dma_addr_t
dma_map_single(struct device *dev, void *cpu_addr, size_t size,
			           enum dma_data_direction direction)


> > > stuff not at the build level but at the runtime level. We can expect 
> > > similar complications when done over 20 architectures as well.
> > 
> > We don't need to touch 20 architectures. We are talking about unifying 
> > dma_mapping_ops. Only architectures that need to handle multiple dma 
> > mapping operations use the dma_mapping_ops scheme; X86, IA64, POWERPC, 
> > SPARC, and PARISC. Unifying X86, IA64 and POWERPC is a must since they 
> > actually share dma_mapping_ops.
> 
> if it's just dma_mapping_ops - then it's those 3 architectures. But 

Well, there are 5 architectures at least, as I wrote.


> there's no reason why the various DMA bouncing implementations in other 
> architectures couldnt use the common code - for example couldnt 
> arch/arm/common/dmabounce.c use the swiotlb too?

Well, it's a different issue. I and hch are talking about
dma_mapping_ops unification. 

You brought up a different topic, DMA bouncing implementations
unification. DMA bouncing implementations unification is a very nice
cleanup. But it's not related with Becky's patch to break IA64 build
at all.


> > > But yes, it's all desired. Obviously extending swiotlb to highmem and 
> > > using it on xen and powerpc is an essential first step in the 
> > > direction of generalizing all this code.
> > 
> > No, it's not about swiotlb highmem patchset.
> > 
> > Due to this problem, IA64 and X86_64 share swiotlb in a very hacky way. 
> > We added more hacky code due to this problem again when we added VT-d 
> > support to IA64.
> > 
> > This problem has been for long time. We added ugly hacks again and again 
> > instead of fixing the root cause.
> 
> well the swiotlb highmem patches are what enable xen (and now powerpc too) 
> to make full use of the swiotlb dma bouncing facilities. And that gives a 
> common platform for unifying all the rest of the lowlevel DMA mapping APIs 
> as well.
> 
> Without that, the swiotlb code is limited, life is going on in separate 
> islands, with everyone doing their own private variations and hacks. We 
> would still probably be nowhere with this had Jeremy not sent the highmem 
> patches.

Again, you are talking about a different issue, which is not related
with Becky's patch to break IA64 build.

As I wrote, Becky's patch is a workaround for the problem that has
been for long time. It's not just about swiotlb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/