Date: Sun, 28 Dec 2008 19:02:12 +0900
To: mingo@elte.hu
Cc: fujita.tomonori@lab.ntt.co.jp, jeremy@goop.org, tony.luck@intel.com,
       linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
       x86@kernel.org, ian.campbell@citrix.com, beckyb@kernel.crashing.org,
       joerg.roedel@amd.com
Subject: Re: [PATCH 0 of 9] swiotlb: use phys_addr_t for pages
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
In-Reply-To: <20081228093751.GC9022@elte.hu>
References: <20081228020312K.fujita.tomonori@lab.ntt.co.jp>
	<20081228142900W.fujita.tomonori@lab.ntt.co.jp>
	<20081228093751.GC9022@elte.hu>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20081228190111H.fujita.tomonori@lab.ntt.co.jp>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2743
Lines: 59

On Sun, 28 Dec 2008 10:37:51 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > If we really want to clean up the dma mapping operations, we should 
> > define struct dma_mapping_ops in a generic place (such as 
> > include/linux/dma-mapping.h) instead each architecture define the own 
> > struct dma_mapping_ops. These dma_mapping_ops structures are very 
> > similar but a bit different. That's the root cause of the dma mapping 
> > operation ugliness.
> >
> > If we do, X86 and IA64 can share swiotlb and intel VTD code cleanly, 
> > X86, IA64, and POWERPC can share swiotlb cleanly too. For example, we 
> > can define swiotlb_dma_ops in lib/swiotlb.c and then everyone can share 
> > it. Currently, X86 and IA64 define the own swiotlb_dma_ops (and X86 
> > needs swiotlb_map_single_phys hack). It doesn't make sense.
> 
> Sure.
> 
> Note that we went through this process (of unifying dma_mapping_ops) 
> recently on x86 recently - 32-bit and 64-bit x86 had such differences.

Not really. x86_32 did not use the dma_ops scheme.


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


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


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