linux-kernel - Re: [patch] x86, voyager: fix ioremap

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]

Date:	Wed, 30 Apr 2008 15:39:15 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	mingo@...e.hu, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [patch] x86, voyager: fix ioremap_nocache()

James Bottomley wrote:
> 
> OK, but look; this is why you broke me.
> 
> The former meaning of ioremap() was give me whatever caching the mtrrs
> set up (assuming you actually have mtrrs.  For voyager, we don't so it
> always meant give me cached memory).
> 

Pre-686 generations of x86 had chipset logic (KEN logic) that did the 
equivalent.  The only change in the 686 was moving this logic into the 
CPU itself.  So no, it didn't always mean "give me cached memory".

> The change broke the QIC ioremap area because it absolutely *requires*
> cached memory.   It drops performance on the Q720 SCSI cards because
> caching was used essentially like write combining to reduce the
> unbursted traffic across the MCA bus.
> 
> When the Voyagers were designed, the only way to get them better
> performace with the slow bus technology was to do a massive amount of
> caching, so they're optimised to the point where every element on the
> voyager bus (sort of like the intel frontside bus) is a primary
> participant in the caching algorithm, and this includes the MCA
> controllers.  So for me, I want every invocation of ioremap to mean
> ioremap_cached() otherwise I don't benefit from the added caches.
> 
> I can fully understand that bus technology has got worse in terms of
> caching since the voyager heydays.  However, I'd rather not be penalised
> for everyone else's hardware failings.  Since the old ioremap is only
> used in the IORESOURCE_CACHABLE case for PCI, and since that used to
> defer to the mtrr settings anyway, it probably does make sense to keep
> it as ioremap_cache() as long as that still defers to the mtrr settings.
> 
> I suppose I could think about an ioremap platform override for voyager
> since, by and large, ioremap_nocache() is the wrong thing on the
> platform.

Sounds like it, or you should just do a global replace of ioremap() with 
ioremap_cache() for the Voyager drivers.

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