linux-kernel - Re: IOMMU and graphics cards

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Jul 2009 10:05:14 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	Joerg Roedel <joerg.roedel@....com>,
	Joerg Roedel <joro@...tes.org>,
	Zhenyu Wang <zhenyu.z.wang@...el.com>,
	linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp,
	iommu@...ts.linux-foundation.org, mingo@...hat.com,
	David Miller <davem@...emloft.net>, eric@...olt.net
Subject: Re: IOMMU and graphics cards

On Mon, 2009-07-06 at 22:35 +0100, Dave Airlie wrote:
> 
> On Mon, 6 Jul 2009, David Woodhouse wrote:
> 
> > On Mon, 2009-07-06 at 15:11 +0200, Joerg Roedel wrote:
> > > Ok, cool, that sounds good. Which in-kernel DRM drivers break with IOMMU
> > > for you? I'll may probably add a similar temporary workaround for AMD
> > > IOMMU too...
> > 
> > The Intel one definitely broke -- I don't know about the others. There
> > are some old patches at http://people.freedesktop.org/~zhen/agp-mm-*
> > which make it look like _all_ AGP drivers are broken.
> > 
> > I wouldn't bother adding the workaround -- as I said, I'm planning to
> > rip it out of 2.6.32 (and in linux-next as soon as it's reasonable to do
> > so). Let's just let them fix it.
> 
> cc'ing Eric,
> 
> My memory of this is graphics becomes totally useless and can be 10x-50x 
> slower. I think ripping this out without the person doing the ripping 
> taking responsiblity for doing speed regression testing is totally insane.

If the IOMMU is absent, disabled or in pass-through mode, then the
performance impact should be virtually zero.

It's the case where the IOMMU is in use that matters -- and the choice
there is between "slow" and "broken". I'll take "slow", please.

Having said that, I've done a bunch of performance work recently and
especially multi-page mappings are a _lot_ faster than they used to be.
I'll see if I can do more once I can test it with your actual usage
patterns.

We currently have an evil hack which uses a shitload of memory to set up
a full set of page tables to map all of physical memory, for every
graphics device at boot time whether we need it or not. The AMD folks
have so far resisted doing that, partly because of the amount of RAM it
would take. I'm getting poked from all sides to _remove_ our hack.

> I personally have no IOMMU hw from Intel or AMD and nobody has seen it fit 
> to supply me with any at any point in time, I'm not on the correct gravy 
> train. So I suspect the people with the hw will have to do the work and 
> the regression testing.

Anything with Cantiga chipset would suffice. Lenovo x200s, T400, etc...

> Could you also enumerate any limitations of the IOMMUs on the amount  
> of memory they can remap per device if any.

The Intel one basically has no relevant limit -- it's 54 bits of virtual
address space or something like that.

I think I saw something about the AMD one perhaps being limited to 4GiB
per device -- which makes 1:1 mapping of all memory a lot less feasible,
but I'll let Jörg answer that question definitively.

Not sure about other platforms off-hand.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/