LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: andi@firstfloor.org, mingo@elte.hu, joerg.roedel@amd.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] fix GART to respect device's dma_mask about virtual mappings
Date: Thu, 18 Sep 2008 20:20:29 +0200	[thread overview]
Message-ID: <20080918182029.GO25711@one.firstfloor.org> (raw)
In-Reply-To: <20080918035726F.fujita.tomonori@lab.ntt.co.jp>

> The falling back mechanism was moved to pci-nommu from the common code
> since it doesn't work for other IOMMUs that always need virtual

There's no fallback for _map_sg/_map_single. All the fallback to GFP
only works for coherent allocations, but not for streaming mappings.

To make this "fully robust" for masks < 32bit you would need to implement 
a new swiotlb that uses GFP_DMA allocations as fallback (or use the DMA 
allocator's swiotlb which can actually handle this)

So you're right now basically checking for something that you cannot
fix. And also you try to check for (but not handle) something that even 
32bit x86 doesn't handle. So if some driver relied on you checking
for it on 64bit it wouldn't work on 32bit x86 which would be a bad 
thing.

> mappings. Calgary needs this dma_mask trick too but I guess that it's
> unlikely that the IBM servers with Calgary have weird hardware.

On a full IOMMU like calgary it's easier to do because you don't
 need to deal with GFP_DMA at least. But as you say it's unlikely
to be worth the effort on these systems.

Also the earlier problem that it wouldn't work on 32bit x86 and other
systems would make it also not too useful. Having drivers that only
work on Calgary wouldn't be a good thing.

-Andi

-- 
ak@linux.intel.com

  reply	other threads:[~2008-09-18 18:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-12 10:42 FUJITA Tomonori
2008-09-12 10:42 ` [PATCH 1/3] add iommu_device_max_index IOMMU helper function FUJITA Tomonori
2008-09-12 10:42   ` [PATCH 2/3] add dma_get_mask " FUJITA Tomonori
2008-09-12 10:42     ` [PATCH 3/3] x86: make GART to respect device's dma_mask about virtual mappings FUJITA Tomonori
2008-09-12 14:52       ` Joerg Roedel
2008-09-12 15:11         ` FUJITA Tomonori
2008-09-14 14:45 ` [PATCH 0/3] fix " Ingo Molnar
2008-09-16  0:54 ` Andi Kleen
2008-09-16 13:20   ` FUJITA Tomonori
2008-09-16 13:43     ` Andi Kleen
2008-09-16 17:13       ` FUJITA Tomonori
2008-09-16 17:58         ` Andi Kleen
2008-09-16 23:53           ` FUJITA Tomonori
2008-09-17  0:24             ` Andi Kleen
2008-09-17 19:20               ` FUJITA Tomonori
2008-09-18 18:20                 ` Andi Kleen [this message]
2008-09-18 22:15                   ` FUJITA Tomonori
2008-09-19  0:44                     ` Andi Kleen
2008-09-22 19:12                       ` FUJITA Tomonori
2008-09-22 20:35                         ` Andi Kleen
2008-09-23  4:02                           ` FUJITA Tomonori
2008-09-17 10:43             ` Ingo Molnar
2008-09-18 18:25               ` Andi Kleen
2008-09-16 15:52     ` Joerg Roedel
2008-09-16 16:20       ` Andi Kleen

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=20080918182029.GO25711@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --subject='Re: [PATCH 0/3] fix GART to respect device'\''s dma_mask about virtual mappings' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).