linux-kernel - Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't already

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] [day] [month] [year] [list]

Message-ID: <20130510082548.GA6892@gmail.com>
Date:	Fri, 10 May 2013 10:25:49 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Theodore Ts'o <tytso@....edu>,
	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't
 already


* Andy Lutomirski <luto@...capital.net> wrote:

> > What do you want WT for, anyway?
> 
> Generically, memory regions in which writes have side effects but reads 
> are just reads and should be cached.
> 
> In particular, persistent (i.e. nonvolatile) memory.  There's an NDA 
> involved, but I can safely say (at least): there seem to be nifty 
> devices that aren't quite RAM that are nonetheless presented to the 
> system as RAM.  Write are durable, but only if they make it out of cache 
> before power fails or the CPU resets in such a way that caches are 
> invalidated but not written back.  UC and WC are a bit heavy-handed 
> because read caching is fine.  (PowerPC has nice instructions for things 
> like "write this back now", but x86 seems to be missing any way other 
> than WT to force data out to RAM without invalidating the cache line.)
> 
> Making this work with a WT MTRR is probably doable, but it's IMO rather 
> ugly.  Even if I go that route, I'd still want to convince graphics 
> drivers to stop wasting MTRRs, since they don't need them and they tend 
> to be in short supply.
> 
> Here's an example:
> 
> http://www.tomshardware.com/news/Viking-ArxCis-NV-NVDIMM-RAM,21892.html

This looks potentially useful.

I'd consider your cache-attributes review and cleanups to drivers and 
infrastructure to be the main upstream benefit we win from your effort.

So as long as your patches go in that general direction, and the PAT code 
and its usage gets cleaner and more organized, and there's no showstopper 
issue discovered, the fact that you gain ioremap_wt() for your driver is 
mostly just a happy coincidence that we don't mind that much.

Maybe in the end we'd have to hide it behind some sort of 
CONFIG_COMPAT_PAT trigger and turn it off on old/buggy systems - but in 
the first approximation it would be nice to try and make this just a 
single variant with no Kconfig complexity?

Thanks,

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