linux-kernel - Re: MTRR use in drivers

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:	Sun, 23 Jun 2013 16:09:33 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Brice Goglin <brice.goglin@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org
Subject: Re: MTRR use in drivers

On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 06/23/2013 01:30 PM, Dave Airlie wrote:
>>>>> Why do you care about performance when PAT is disabled?
>>
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
>>
>
> Not "just because", but *if* the choice is between breaking old boxes
> and breaking new boxes I'll take the latter.
>
>> Andy Lutomirski just submitted a bunch of patches to clean up the DRM
>> usage of mtrrs, they are in drm-next, afaik we no longer add them on
>> PAT systems.
>
> Fantastic news.  No issue, then, and no need to break anything.
>
> The only problem I see with having ioremap_wc() installing an MTRR on
> non-PAT, rather than pushing that into the drivers which is clearly not
> the right thing, is that we will need a hook to uninstall it when the
> mapping is destroyed.

I have trouble believing that this will ever work well -- MTRRs have
crazy alignment requirements and interactions with other MTRRs, and a
few drivers have to jump through hoops to set up the right MTRRs.
There aren't really enough to break down every mapping.

My patches (in dri-next) add functions arch_wc_phys_add and
arch_wc_phys_del that do nothing except on x86 with MTRRs on and PAT
off, in which case they try to add a WC MTRR.  That way the handful of
drivers that need WC for performance on old hardware can try (and
possibly fail, depending on the usual vagaries of MTRRs).  With my
patches applied, DRM and agpgart no longer touch MTRRs at all with PAT
on.

I didn't get around to excising MTRRs from the non-DRM video drivers
or from the few odd cases like myri10ge.

This stuff is painful to test.  The only drivers I can really test are
i915 and radeon.  I have a myri10ge device, but it's on a production
server.  I also have several mgag200 devices, but they're in a
super-secret-locked-down datacenter a few thousand miles away, and
trying to gauge framebuffer performance over Dell and/or HP's crappy
remoting interface is a lost cause.  I'm not sure that my oldest
computer (locked in a basement in another state) is old enough to have
an AGP port.

--Andy
--
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/