From: Alex Williamson <alex.williamson@hp.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: dwmw2@infradead.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH] intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough
Date: Thu, 05 Nov 2009 20:19:52 -0700 [thread overview]
Message-ID: <1257477592.2837.94.camel@2710p.home> (raw)
In-Reply-To: <20091106114130J.fujita.tomonori@lab.ntt.co.jp>
On Fri, 2009-11-06 at 11:41 +0900, FUJITA Tomonori wrote:
> On Wed, 04 Nov 2009 15:59:34 -0700
> Alex Williamson <alex.williamson@hp.com> wrote:
> > @@ -2582,7 +2582,7 @@ static dma_addr_t __intel_map_single(struct device *hwdev, phys_addr_t paddr,
> > BUG_ON(dir == DMA_NONE);
> >
> > if (iommu_no_mapping(hwdev))
> > - return paddr;
> > + return paddr + size > dma_mask ? 0 : paddr;
>
> You can use dma_capable(hwdev, paddr, size) here.
Good thought, however __intel_map_single() gets called with either the
dma_mask or the coherent_dma_mask. dma_capable() only checks dma_mask,
so would only work for one of the callers.
> > domain = get_valid_domain_for_dev(pdev);
> > if (!domain)
> > @@ -2767,7 +2767,15 @@ static void *intel_alloc_coherent(struct device *hwdev, size_t size,
> >
> > size = PAGE_ALIGN(size);
> > order = get_order(size);
> > - flags &= ~(GFP_DMA | GFP_DMA32);
> > +
> > + if (!iommu_no_mapping(hwdev))
> > + flags &= ~(GFP_DMA | GFP_DMA32);
> > + else if (hwdev->coherent_dma_mask != DMA_BIT_MASK(64)) {
> > + if (hwdev->coherent_dma_mask < DMA_BIT_MASK(32))
> > + flags |= GFP_DMA;
> > + else
> > + flags |= GFP_DMA32;
> > + }
>
> This is fine for 2.6.32 but we'll cleanly fix this by using
> swiotlb_dma_ops later, right?
I'm open to suggestions. I don't really understand why we dropped
swiotlb for passthrough mode in 2.6.32 to start with. It seems like we
now have a couple corner cases where we have to either hope for the best
or effectively ignore the request to use passthrough. Thanks,
Alex
next prev parent reply other threads:[~2009-11-06 3:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-04 22:59 Alex Williamson
2009-11-06 2:41 ` FUJITA Tomonori
2009-11-06 3:19 ` Alex Williamson [this message]
2009-11-06 3:34 ` FUJITA Tomonori
2009-11-06 4:09 ` Alex Williamson
2009-11-09 23:02 ` David Woodhouse
2009-11-09 23:32 ` Alex Williamson
2009-11-10 0:19 ` David Woodhouse
2009-11-11 15:23 ` [stable][PATCH] PCIe hot-plug for Intel IOMMU Fenghua Yu
2009-11-11 21:27 ` Yinghai Lu
2009-11-28 6:17 ` David Woodhouse
2009-11-12 2:37 ` David Woodhouse
2009-11-12 23:32 ` Yu, Fenghua
2009-11-10 0:46 ` [PATCH] intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough David Woodhouse
2009-11-10 1:01 ` David Woodhouse
2009-11-10 1:28 ` Alex Williamson
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=1257477592.2837.94.camel@2710p.home \
--to=alex.williamson@hp.com \
--cc=akpm@linux-foundation.org \
--cc=dwmw2@infradead.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®