soc/intel/xeon_sp: Reserve MMIO high range

Xeon-SP supports MMIO high range, a.k.a. MMIO range above 4G. FSP will
assign domain MMIO high windows from this range.

However, there will be unassigned parts among these high windows for
non-domain device usage (e.g. misc devices belonging to an IIO stack
but not belonged to any PCIe domains under that stack). This will cause
segmentation in MTRR UC coverage.

For example, in SPR-XCC where only CPM0/HQM0 are supported and
instantiated to PCIe domains, MMIO ranges are still reserved for
CPM1/HQM1. See more at src/soc/intel/xeon_sp/spr/ioat.c.

Reserve MMIO high range as a whole under domain0/00:0.0. During MTRR
calculation, this reservation will connect the discontinued domain MMIO
high windows together to form one continuous range, and save MTRR
register usage from inadequacy.

This change is initially raised for SPR but could be effective for GNR
as well.

TESTED = Build and boot in intel/archercity CRB, MTRR register usage
decreases from 7 to 3 in 2S system.

TESTED = Only setting MTRR for below 4GB ranges test fails with
LinuxBoot on SPR (through x86_setup_mtrrs_with_detect_no_above_4gb)

tsc: Detected 2000.000 MHz processor
last_pfn = 0x2080000 max_arch_pfn = 0x10000000000
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 129024MB of RAM.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/mtrr/cleanup.c:978 mtrr_trim_uncached_memory+0x2b9/0x2f9
...
Call Trace:
 ? 0xffffffff8f600000
 ? setup_arch+0x4bb/0xaed
 ? printk+0x53/0x6a
 ? start_kernel+0x55/0x507
 ? load_ucode_intel_bsp+0x1c/0x4d
 ? secondary_startup_64_no_verify+0xc2/0xcb
random: get_random_bytes called from init_oops_id+0x1d/0x2c with crng_init=0
---[ end trace 0e56686fd458f0c5 ]---
update e820 for mtrr
modified physical RAM map:
modified: [mem 0x0000000000000000-0x0000000000000fff] reserved
...
modified: [mem 0x00000000ff000000-0x000000207fffffff] reserved
last_pfn = 0x6354e max_arch_pfn = 0x10000000000
Memory KASLR using RDRAND RDTSC...
x2apic: enabled by BIOS, switching to x2apic ops
Using GB pages for direct mapping
...
Initmem setup node 0 [mem 0x0000000000001000-0x000000006354dfff]
  DMA zone: 28769 pages in unavailable ranges
  DMA32 zone: 19122 pages in unavailable ranges
BUG: unable to handle page fault for address: ff24b56eba60cff8
BAD
Oops: 0000 [#1] SMP NOPTI
CPU: 0 PID: 0 Comm: swapper Tainted: G        W         5.10.50 #2
...
Call Trace:
 ? set_pte_vaddr_p4d+0x24/0x35
 ? __native_set_fixmap+0x21/0x28
 ? map_vsyscall+0x35/0x56
 ? setup_arch+0xa00/0xaed
 ? printk+0x53/0x6a
 ? start_kernel+0x55/0x507
 ? load_ucode_intel_bsp+0x1c/0x4d
 ? secondary_startup_64_no_verify+0xc2/0xcb
CR2: ff24b56eba60cff8
---[ end trace 0e56686fd458f0c6 ]---
RIP: 0010:fill_pud+0xa/0x62
...
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

Change-Id: Ib2a0e1f1f13e797c1fab6aca589d060c4d3fa15b
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83538
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>

0 files changed, 0 insertions, 0 deletions