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: <20081228073012.GA30012@infradead.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ