From: Ingo Molnar <mingo@elte.hu>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: 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 <joerg.roedel@amd.com>
Subject: Re: [PATCH 0 of 9] swiotlb: use phys_addr_t for pages
Date: Sun, 28 Dec 2008 10:37:51 +0100 [thread overview]
Message-ID: <20081228093751.GC9022@elte.hu> (raw)
In-Reply-To: <20081228142900W.fujita.tomonori@lab.ntt.co.jp>
* 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.
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
stuff not at the build level but at the runtime level. We can expect
similar complications when done over 20 architectures as well.
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.
Ingo
next prev parent reply other threads:[~2008-12-28 9:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-22 18:26 [PATCH 0 of 9] swiotlb: use phys_addr_t for pages Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 1 of 9] revert "swiotlb: support bouncing of HighMem pages." Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 2 of 9] revert "swiotlb: factor out copy to/from device." Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 3 of 9] swiotlb: add hwdev to swiotlb_phys_to_bus Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 4 of 9] swiotlb: Drop SG_ENT_VIRT_ADDRESS macro Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 5 of 9] swiotlb: Rename SG_ENT_PHYS_ADDRESS to SG_ENT_BUS_ADDRESS Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 6 of 9] swiotlb: Store phys address in io_tlb_orig_addr array Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 7 of 9] swiotlb: Add support for systems with highmem Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 8 of 9] swiotlb: cleanups to swiotlb_bounce() Jeremy Fitzhardinge
2008-12-22 18:26 ` [PATCH 9 of 9] ia64/x86/swiotlb: use enum dma_data_direciton in dma_ops Jeremy Fitzhardinge
2008-12-22 18:43 ` [PATCH 0 of 9] swiotlb: use phys_addr_t for pages FUJITA Tomonori
2008-12-27 10:48 ` Ingo Molnar
2008-12-27 15:06 ` FUJITA Tomonori
2008-12-28 5:01 ` Jeremy Fitzhardinge
2008-12-28 9:50 ` Ingo Molnar
2008-12-27 16:44 ` FUJITA Tomonori
2008-12-27 16:56 ` Ingo Molnar
2008-12-27 17:03 ` FUJITA Tomonori
2008-12-28 5:29 ` FUJITA Tomonori
2008-12-28 7:30 ` Christoph Hellwig
2008-12-28 9:36 ` FUJITA Tomonori
2008-12-28 21:37 ` Benjamin Herrenschmidt
2008-12-28 9:37 ` Ingo Molnar [this message]
2008-12-28 10:02 ` FUJITA Tomonori
2008-12-28 10:34 ` Ingo Molnar
2008-12-28 11:00 ` FUJITA Tomonori
2008-12-28 11:56 ` Ingo Molnar
2008-12-28 12:34 ` FUJITA Tomonori
2008-12-28 12:49 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081228093751.GC9022@elte.hu \
--to=mingo@elte.hu \
--cc=beckyb@kernel.crashing.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=ian.campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=joerg.roedel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox