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]

Date:	Sun, 28 Dec 2008 02:30:12 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	mingo@...e.hu, 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
Subject: Re: [PATCH 0 of 9] swiotlb: use phys_addr_t for pages

On Sun, Dec 28, 2008 at 02:29:54PM +0900, FUJITA Tomonori 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.

Yes, please.  For people hacking on different architectures occasionally
the current setup with per-arch ops (and sometimes none at all) is pain.

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

Also the calgary iommu is very similar to those used on some pseries
machines, but I'd have to look at the code if the interface actually
still is similar, or if the PPC firmware adds too much abstractions
inbetween.

Also the older IA64 altixens have a slightly updated version of the
iommu used on MIPS IP27 (and the same as on MIPS IP35 which we'll
hopefully support one day)

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