linux-kernel - Re: x86/mm: Limit 2/4M size calculation to x86

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]

Message-ID: <5017A9EB.1030903@canonical.com>
Date:	Tue, 31 Jul 2012 11:48:27 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Cong Wang <xiyou.wangcong@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Yinghai Lu <yinghai@...nel.org>,
	Tejun Heo <tj@...nel.org>
Subject: Re: x86/mm: Limit 2/4M size calculation to x86_32

On 25.07.2012 15:40, Avi Kivity wrote:
> On 07/25/2012 04:24 PM, Stefan Bader wrote:
>>>> ...
>>>> ifdef CONFIG_X86_32
>>>>         /*
>>>>          * Don't use a large page for the first 2/4MB of memory
>>>>          * because there are often fixed size MTRRs in there
>>>>          * and overlapping MTRRs into large pages can cause
>>>>          * slowdowns.
>>>>          */
>>>>
>>>
>>> That's equally true for X86_64.
>>>
>>> Best would be to merge the MTRRs into PAT, but that might not work for SMM.
>>>
>>>
>> Ok, true. Not sure why this was restricted to 32bit when reconsidering. Except
>> if in 64bit it was assumed (or asserted) that the regions are aligned to 2M...
>> But maybe this can be answered by someone knowing the details. I would not mind
>> either way (have the first range with 4K pages in all cases or fixing the
>> additional PTE allocation). Just as it is now it is inconsistent.
> 
> Sometimes CONFIG_X86_32 is used as an alias for "machines so old they
> don't support x86_64".  As a 32-bit kernel can be run on a machine that
> does support x86_64, it should be replaced by a runtime test for
> X86_FEATURE_LM, until a more accurate test can be found.
> 

So basically the first range being 4k exist because MTRRs might define ranges
there and those are always aligned to 4k but not necessarily to the bigger pages
used. Reading through the Intel and AMD docs indicates various levels of badness
when this is not the case. Though afaict MTRRs are not tied to long mode capable
CPUs. For example Atom is 32bit only (the earlier ones at least) and uses MTRRs.
So testing for LM would miss those.
Would it not be better to unconditionally have the first 2/4M as 4k pages? At
least as long as there is no check for the alignment of the MTRR ranges. Or
thinking of it, the runtime test should look for X86_FEATURE_MTRR, shouldn't it?



Download attachment "signature.asc" of type "application/pgp-signature" (901 bytes)