linux-kernel - Re: [PATCH 0 of 9] swiotlb: use phys_addr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081228190111H.fujita.tomonori@lab.ntt.co.jp>
Date:	Sun, 28 Dec 2008 19:02:12 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	mingo@...e.hu
Cc:	fujita.tomonori@....ntt.co.jp, jeremy@...p.org,
	tony.luck@...el.com, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xensource.com, x86@...nel.org,
	ian.campbell@...rix.com, beckyb@...nel.crashing.org,
	joerg.roedel@....com
Subject: Re: [PATCH 0 of 9] swiotlb: use phys_addr_t for pages

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

> 
> * FUJITA Tomonori <fujita.tomonori@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/