From: Andi Kleen <ak@suse.de>
To: "David S. Miller" <davem@redhat.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, richard.brunner@amd.com
Subject: Re: IOMMUs was Re: Intel vs AMD x86-64
Date: Fri, 27 Feb 2004 02:28:49 +0100 [thread overview]
Message-ID: <20040227022849.6d9f88ef.ak@suse.de> (raw)
In-Reply-To: <20040224101340.47341f28.davem@redhat.com>
On Tue, 24 Feb 2004 10:13:40 -0800
"David S. Miller" <davem@redhat.com> wrote:
> On 24 Feb 2004 15:06:47 +0100
> Andi Kleen <ak@suse.de> wrote:
>
> > One side effect of this is that the IOMMU TLB flush strategy is a bit
> > dumb, because it has to do config space accesses for it.
>
> This can be costly, but if you flush the IOMMU like sparc64 does (basically
> it's similar to how KMAPs are flushed on x86), the cost gets real low because
> then you only flush the whole iommu once every time you walk the whole mapping
> table of the iommu.
>
> I'm sure you've probably thought of this already, just mentioning it in case
> you haven't.
Arjan suggested it some time ago already. In fact I implemented it, it's in the current code.
But it caused data corruption with a few devices, in particular 3ware, so I had
to disable it again. I didn't find a bug in the code. It worked fine with others. My theory
was that it triggered some hardware bug that was normally masked by the frequent flushes, but
I wasn't able to track it down without heavy equipment.
Currently it is in there, but disabled by default. Can be enabled with iommu=nofullflush.
Also the other part of the dumbness is that the flush is global, not per mapping. I guess
you don't have that problem on Sparc64.
Anyways, even with these restrictions having the GART as IOMMU is much better than
doing software bouncing.
-Andi
next prev parent reply other threads:[~2004-02-24 18:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0402231625220.9708-100000@chimarrao.boston.redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0402231335430.3005@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <20040223134853.5947a414.davem@redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0402231359280.3005@ppc970.osdl.org.suse.lists.linux.kernel>
2004-02-24 14:06 ` IOMMUs was Re: Intel vs AMD x86-64 Andi Kleen
2004-02-24 18:13 ` David S. Miller
2004-02-27 1:28 ` Andi Kleen [this message]
2004-02-24 18:41 ` David S. Miller
2004-02-25 0:36 ` Benjamin Herrenschmidt
2004-02-24 15:50 richard.brunner
2004-02-24 16:27 ` Mike Fedyk
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=20040227022849.6d9f88ef.ak@suse.de \
--to=ak@suse.de \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.brunner@amd.com \
--cc=torvalds@osdl.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 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.