public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joerg.roedel@amd.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	mingo@redhat.com, fujita.tomonori@lab.ntt.co.jp,
	airlied@linux.ie
Subject: Re: IOMMU and graphics cards
Date: Tue, 28 Apr 2009 18:04:48 +0200	[thread overview]
Message-ID: <20090428160448.GA17438@amd.com> (raw)
In-Reply-To: <1240932530.2567.91.camel@macbook.infradead.org>

On Tue, Apr 28, 2009 at 04:28:50PM +0100, David Woodhouse wrote:
> On Tue, 2009-04-28 at 17:05 +0200, Joerg Roedel wrote:
> 
> For that device, yes. The IOMMU still catches errors from _other_
> devices, of course.

Yes, it is in effect for other devices. But since its a security feature
it only makes sense if it covers all devices.

> Is the reason you're doing this actually because of broken drivers? Or
> just because of the performance implications? I've heard both cited as
> reasons for the 1:1 mapping... and if it's mostly the former, then
> perhaps the best way for me to help you is to stop enabling the option
> in Fedora (rawhide, at least), so that the buggy drivers get _fixed_ and
> you don't get stuck with "it works on Intel, why can't you make it
> work?" reports?

Currently some graphics drivers don't work with IOMMU enabled because
they don't use the DMA-API. The silently assume that device addess ==
physical address.
I don't know how it is solved for VT-d but for AMD IOMMU the available
DMA memory address space is limited per device. This is a problem for
graphics card drivers because, as developers told me, they may need
gigabytes of DMA memory. I am currently thinking about ways to fix that
without enlarging the DMA address space for each device (which would be
a huge waste of memory). But unless this problem isn't solved the
drivers won't be fixed, I guess.
I guess the DRM code in the kernel may have the same problem with IOMMU
enabled?

> > 	* Implement a kernel command line option to enable/disable the
> > 	  workaround (what should be default?)
> > 	* Use the IOMMU-API and write a kernel module which creates a
> > 	  direct mapped protection domain and assigns the graphics
> > 	  cards to it (need to be done carefully to not break graphics 
> > 	  drivers which do everything right and use the DMA-API)
> > 	* Any other great idea?
> 
> I think I also prefer your second option. I don't like having this as a
> hack in the IOMMU code.

Ok, so I will implement such a module and send the code around for
discussion.

	Joerg

-- 
           | Advanced Micro Devices GmbH
 Operating | Karl-Hammerschmidt-Str. 34, 85609 Dornach bei München
 System    | 
 Research  | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
 Center    | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
           | Registergericht München, HRB Nr. 43632


  reply	other threads:[~2009-04-28 16:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 15:05 IOMMU and graphics cards Joerg Roedel
2009-04-28 15:28 ` David Woodhouse
2009-04-28 16:04   ` Joerg Roedel [this message]
2009-05-07  7:47     ` FUJITA Tomonori
2009-05-07 10:01       ` Joerg Roedel
2009-05-07 10:22         ` David Woodhouse
2009-05-07 10:42           ` FUJITA Tomonori
2009-05-07 12:15           ` Joerg Roedel
2009-05-07 12:59             ` FUJITA Tomonori
2009-05-07 14:37               ` Joerg Roedel
2009-05-07 17:04             ` Christoph Hellwig
2009-05-07 18:36           ` David Miller
2009-05-08  9:35             ` Joerg Roedel
2009-07-06 12:26               ` David Woodhouse
2009-07-06 13:11                 ` Joerg Roedel
2009-07-06 14:18                   ` David Woodhouse
2009-07-06 21:35                     ` Dave Airlie
2009-07-06 22:00                       ` Dave Airlie
2009-07-07  8:54                         ` Joerg Roedel
2009-07-07 15:24                         ` Duran, Leo
2009-07-07 15:33                           ` Duran, Leo
2009-07-07 15:36                             ` David Woodhouse
2009-07-07  8:59                       ` Joerg Roedel
2009-07-07  9:16                         ` David Woodhouse
2009-07-07  9:05                       ` David Woodhouse
2009-05-07 10:23         ` FUJITA Tomonori
2009-05-07 11:01           ` Ingo Molnar
2009-05-07 11:14             ` FUJITA Tomonori
2009-05-07 11:26               ` Ingo Molnar
2009-05-07 12:00           ` Joerg Roedel
2009-05-07 10:55         ` Ingo Molnar

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=20090428160448.GA17438@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=airlied@linux.ie \
    --cc=dwmw2@infradead.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    /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