linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Olof Johansson <olof@lixom.net>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH] DMA 4GB boundary protection
Date: Sat, 03 Mar 2007 09:27:31 +0100	[thread overview]
Message-ID: <1172910451.8184.51.camel@localhost.localdomain> (raw)
In-Reply-To: <20070302222748.GA1206@lixom.net>

On Fri, 2007-03-02 at 16:27 -0600, Olof Johansson wrote:
> On Fri, Mar 02, 2007 at 03:49:43PM -0600, Jake Moilanen wrote:
> > There are many adapters which can not handle DMAing acrosss any 4 GB
> > boundary.  For instance the latest Emulex adapters.  
> > 
> > This normally is not an issue as firmware gives us dma-windows under
> > 4gigs.  However, some of the new System-P boxes have dma-windows above
> > 4gigs, and this present a problem.
> > 
> > I propose fixing it in the IOMMU allocation instead of making each
> > driver protect against it as it is more efficient, and won't require
> > changing every driver which has not considered this issue.
> 
> Sorry, but you need to fix the drivers. They might be used on a system
> without an IOMMU, or with direct mapping. It's particularily likely in
> the case of DAC-capable devices, and that's the only case for which you
> can cross a 4GB boundary in the first place.

Hrm... ok, that would be ideal, _but_

- We currently don't have platforms that DMA > 32 bits and don't have an
iommu

- Drivers are broken -today- and I doubt they can all be audited and
fixed (and fixes bacported to distros) quickly

- That problem is very common and can be very hard to debug when it
happens.

So while I agree, the logical fix would be in the drivers, I think that
-also- making sure the iommu code will not hand off sections crossing 4G
boundaries does make some sense. It will at least reduce the likehood of
strange and hard to debug problems on those setups that do have an iommu
and >4G of RAM, which is pretty much all of them at the moment on ppc64.

Can you double check the correctness of the patch ? I'll have a better
look myself next week hopefully.

Ben.

  reply	other threads:[~2007-03-03  8:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02 21:49 [PATCH] DMA 4GB boundary protection Jake Moilanen
2007-03-02 22:27 ` Olof Johansson
2007-03-03  8:27   ` Benjamin Herrenschmidt [this message]
2007-03-03 23:25     ` Olof Johansson
2007-03-04  5:17     ` Christoph Hellwig
2007-03-04  5:52       ` Olof Johansson
2007-03-03 23:29 ` Olof Johansson
2007-03-03 23:32   ` Segher Boessenkool
2007-03-03 23:57     ` Olof Johansson
2007-03-21 21:05   ` Jake Moilanen
2007-03-21 21:39     ` Olof Johansson
2007-03-22 17:53     ` Olof Johansson
2007-03-22 17:47       ` Jake Moilanen
2007-03-22 22:52       ` Segher Boessenkool
2007-03-27 20:10       ` Jake Moilanen
2007-03-27 20:55         ` Benjamin Herrenschmidt
2007-03-27 23:48         ` Paul Mackerras
2007-03-28 15:56         ` Olof Johansson
2007-03-28 18:17           ` Jake Moilanen
2007-03-28 23:23             ` Benjamin Herrenschmidt
2007-03-29 13:44               ` Jake Moilanen
2007-03-29 14:52                 ` Olof Johansson
2007-03-29 21:54                 ` Benjamin Herrenschmidt
2007-04-23 12:22                 ` Paul Mackerras
2007-04-24  3:07                   ` Olof Johansson

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=1172910451.8184.51.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=olof@lixom.net \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).