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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <500FF3A1.6080809@canonical.com>
Date:	Wed, 25 Jul 2012 15:24:49 +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 14:32, Avi Kivity wrote:
> On 07/25/2012 02:14 PM, Stefan Bader wrote:
>> On 25.07.2012 12:44, Avi Kivity wrote:
>>> On 07/24/2012 06:52 PM, Cong Wang wrote:
>>>
>>>>> From 6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001
>>>>> From: Stefan Bader <stefan.bader@...onical.com>
>>>>> Date: Fri, 13 Jul 2012 15:16:33 +0200
>>>>> Subject: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32
>>>>>
>>>>> commit 722bc6b (x86/mm: Fix the size calculation of mapping tables)
>>>>> did modify the extra space calculation for mapping tables in order
>>>>> to make up for the first 2/4M memory range using 4K pages.
>>>>> However this setup is only used when compiling for 32bit. On 64bit
>>>>> there is only the trailing area of 4K pages (which is already added).
>>>>>
>>>>> The code was already adapted once for things went wrong on a 8TB
>>>>> machine (bd2753b x86/mm: Only add extra pages count for the first memory
>>>>> range during pre-allocation early page table space), but it looks a bit
>>>>> like it currently would overdo things for 64bit.
>>>>> I only noticed while bisecting for the reason I could not make a crash
>>>>> kernel boot (which ended up on this patch).
>>>>>
>>>>> Signed-off-by: Stefan Bader <stefan.bader@...onical.com>
>>>>> Cc: WANG Cong <xiyou.wangcong@...il.com>
>>>>> Cc: Yinghai Lu <yinghai@...nel.org>
>>>>> Cc: Tejun Heo <tj@...nel.org>
>>>>
>>>> Acked-by: Cong Wang <xiyou.wangcong@...il.com>
>>>>
>>>> Sorry for that I was not aware of x86_64 is different with x86 in the
>>>> first 2/4M.
>>>
>>> Why would there be a difference?
>>>
>>> Shouldn't the IO space at 0xa0000-0x100000 be mapped with uncacheable
>>> attributes (or WC for VGA)?  If it's done later, it can be done later
>>> for both.
>>>
>> arch/x86/mm/init.c
>>
>> unsigned long __init_refok init_memory_mapping(...
>> ...
>> 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.



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