linux-kernel - Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

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:	Fri, 1 Jun 2007 14:41:57 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Justin Piszcz <jpiszcz@...idpixels.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
> And normally the MTRRs win, don't they (if I remember the table correctly)
> So if the MTRR says UC and PAT disagrees it might not actually help

I just checked, yes the MTRRs win for UC types.  But it sounds like the cases 
we're talking about are actually situations where there's no MTRR coverage, 
so the default type is used.  The manual doesn't specifically call out how 
memory using the default type interacts with PAT, but it may well be that it 
stays uncached if the default type is uncached.  Again that argues for fixing 
the MTRR mapping problem in some way.

Thanks,
Jesse
-
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/