On 31.05.23 10:35, Borislav Petkov wrote:
On Wed, May 31, 2023 at 09:28:57AM +0200, Juergen Gross wrote:Can you please boot the system with the MTRR patches and specify "mtrr=debug" on the command line? I'd be interested in the raw register values being read and the resulting memory type map.This is exactly why I wanted this option. And you're already putting it to good use. :-P Full dmesg below. [ 0.012878] last_pfn = 0x450000 max_arch_pfn = 0x400000000 [ 0.018357] MTRR default type: uncachable [ 0.022347] MTRR fixed ranges enabled: [ 0.026085] 00000-9FFFF write-back [ 0.029650] A0000-BFFFF uncachable [ 0.033214] C0000-FFFFF write-protect [ 0.037039] MTRR variable ranges enabled: [ 0.041038] 0 base 000000000000000 mask 0003FFC00000000 write-back
16 GB WB at address 0.
[ 0.047383] 1 base 000000400000000 mask 0003FFFC0000000 write-back
1 GB WB at address 16GB.
[ 0.053730] 2 base 000000440000000 mask 0003FFFF0000000 write-back
256MB WB at address 17GB. This means per default 0-44fffffff are WB.
[ 0.060076] 3 base 0000000AE000000 mask 0003FFFFE000000 uncachable
32MB UC at AE000000
[ 0.066421] 4 base 0000000B0000000 mask 0003FFFF0000000 uncachable
256MB UC at B0000000
[ 0.072768] 5 base 0000000C0000000 mask 0003FFFC0000000 uncachable
512MB UC at C0000000 So an UC hole at AE000000-FFFFFFFF.
[ 0.079114] 6 disabled [ 0.081635] 7 disabled [ 0.084156] 8 disabled [ 0.086677] 9 disabled [ 0.089203] total RAM covered: 16352M [ 0.093023] Found optimal setting for mtrr clean up
It seems as if mtrr_cleanup() did change the MTRR settings. What it did would have been printed if pr_debug() would have been active. :-(
[ 0.097734] gran_size: 64K chunk_size: 64M num_reg: 8 lose cover RAM: 0G [ 0.104864] MTRR map: 6 entries (3 fixed + 3 variable; max 23), built from 10 variable MTRRs [ 0.113294] 0: 0000000000000000-000000000009ffff write-back [ 0.119033] 1: 00000000000a0000-00000000000bffff uncachable [ 0.124771] 2: 00000000000c0000-00000000000fffff write-protect [ 0.130769] 3: 0000000000100000-00000000adffffff write-back [ 0.136508] 4: 00000000ae000000-00000000afffffff uncachable [ 0.142246] 5: 0000000100000000-000000044fffffff write-back
The MTRR map seems to be fine assuming the MTRR values before the "clean up".
[ 0.147992] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
> [ 0.155122] e820: update [mem 0xae000000-0xafffffff] usable ==> reserved > [ 0.161663] e820: update [mem 0xc0000000-0xffffffff] usable ==> reserved > [ 0.168358] e820: update [mem 0x110000000-0x1ffffffff] usable ==> reserved> [ 0.175227] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 3840MB of RAM.
Clean up messed with the settings, resulting in loss of RAM. Did you check whether CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT was the same in both kernels you've tested? Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
