[S] Change in coreboot[main]: soc/amd/common: use common physical address bit reservation code

[Felix Held (Code Review)]

Attention is currently required from: Fred Reitberger, Jason Glenesk, Jérémy Compostella, Marshall Dawson, Matt DeVillier.

Hello Fred Reitberger, Jason Glenesk, Marshall Dawson, Matt DeVillier, build bot (Jenkins),

I'd like you to reexamine a change. Please visit

https://review.coreboot.org/c/coreboot/+/78074?usp=email

to look at the new patch set (#4).

The following approvals got outdated and were removed:
Verified+1 by build bot (Jenkins)

Change subject: soc/amd/common: use common physical address bit reservation code
......................................................................

soc/amd/common: use common physical address bit reservation code

Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.

Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version version 6.5 of the
Linux kernel.

The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.

TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.

TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:

mtrr: your BIOS has configured an incorrect mask, fixing it.

Signed-off-by: Felix Held 
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
---
M src/soc/amd/common/block/cpu/Kconfig
M src/soc/amd/common/block/cpu/noncar/Makefile.inc
M src/soc/amd/common/block/cpu/noncar/cpu.c
M src/soc/amd/common/block/cpu/smm/smm_relocate.c
M src/soc/amd/common/block/data_fabric/domain.c
M src/soc/amd/common/block/include/amdblocks/cpu.h
6 files changed, 12 insertions(+), 10 deletions(-)

git pull ssh://review.coreboot.org:29418/coreboot refs/changes/74/78074/4