From: Joerg Roedel <joerg.roedel@amd.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [PATCH] x86: avoid unnecessary low zone allocation in AMD IOMMU's alloc_coherent
Date: Wed, 10 Sep 2008 14:48:22 +0200 [thread overview]
Message-ID: <20080910124822.GG6329@amd.com> (raw)
In-Reply-To: <20080910213155M.fujita.tomonori@lab.ntt.co.jp>
On Wed, Sep 10, 2008 at 09:38:11PM +0900, FUJITA Tomonori wrote:
> On Wed, 10 Sep 2008 14:03:10 +0200
> Joerg Roedel <joerg.roedel@amd.com> wrote:
> > It needs a fix anyway and the
> > right solution here is to fall back to one of the software iommu
> > implementations. The stackable dma_ops patches I have currently in work
> > will do exactly that.
>
> I'm not sure you need the stackable dma_ops support. Calgary IOMMU had
> the same problem and already solved it with dma_ops-per-device option.
We need stackable dma_ops anyway for paravirt IOMMU support in KVM. And
they will fix this issue too.
> > These flags are already removed in the dma_alloc_coherent function which
> > calls this one. Further I think in the case of a remapping IOMMU like
>
> Not true about x86/tip/iommu. dma_alloc_coherent in dma-mapping.h does
> that so that swiotlb and pci-nommu don't need the gfp hack. Clearing
> the gfp flags is much simpler than setting up the flags correctly
> mainly because of the fallback device, setting up the flags is really
> difficult.
Yes, dma_alloc_coherent in dma-mapping.h clears the flags. And this
function also calls ops->alloc_coherent which points to the AMD IOMMUs
alloc_coherent function if the driver is in place.
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
next prev parent reply other threads:[~2008-09-10 12:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 11:19 [PATCH] x86: avoid unnecessary low zone allocation in AMD IOMMU's alloc_coherent FUJITA Tomonori
2008-09-10 11:57 ` Ingo Molnar
2008-09-10 12:03 ` Joerg Roedel
2008-09-10 12:18 ` Ingo Molnar
2008-09-10 12:38 ` FUJITA Tomonori
2008-09-10 12:48 ` Joerg Roedel [this message]
2008-09-10 13:03 ` FUJITA Tomonori
2008-09-10 13:10 ` Joerg Roedel
2008-09-10 13:37 ` FUJITA Tomonori
2008-09-10 13:53 ` Joerg Roedel
2008-09-10 14:24 ` FUJITA Tomonori
2008-09-10 14:38 ` Joerg Roedel
2008-09-10 14:45 ` FUJITA Tomonori
2008-09-11 9:10 ` Joerg Roedel
2008-09-11 13:36 ` FUJITA Tomonori
2008-09-10 14:39 ` FUJITA Tomonori
2008-09-10 14:52 ` Joerg Roedel
2008-09-10 15:09 ` FUJITA Tomonori
2008-09-10 15:29 ` Joerg Roedel
2008-09-10 16:29 ` FUJITA Tomonori
2008-09-10 17:05 ` Joerg Roedel
2008-09-10 17:15 ` FUJITA Tomonori
2008-09-10 17:25 ` Joerg Roedel
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=20080910124822.GG6329@amd.com \
--to=joerg.roedel@amd.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.