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 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 <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>

2 files changed, 3 insertions, 6 deletions

diff --git a/src/soc/amd/common/block/cpu/noncar/Makefile.inc b/src/soc/amd/common/block/cpu/noncar/Makefile.inc
index 3204667fc1..f8ca357c40 100644
--- a/src/soc/amd/common/block/cpu/noncar/Makefile.inc
+++ b/src/soc/amd/common/block/cpu/noncar/Makefile.inc
@@ -2,6 +2,7 @@
 ifeq ($(CONFIG_SOC_AMD_COMMON_BLOCK_NONCAR),y)
 
 bootblock-y += bootblock.c
+bootblock-y += cpu.c
 bootblock-y += early_cache.c
 bootblock-y += pre_c.S
 bootblock-y += write_resume_eip.c
diff --git a/src/soc/amd/common/block/cpu/noncar/cpu.c b/src/soc/amd/common/block/cpu/noncar/cpu.c
index eec593c8a9..eefd62fcf0 100644
--- a/src/soc/amd/common/block/cpu/noncar/cpu.c
+++ b/src/soc/amd/common/block/cpu/noncar/cpu.c
@@ -35,7 +35,8 @@ void set_cstate_io_addr(void)
 	wrmsr(MSR_CSTATE_ADDRESS, cst_addr);
 }
 
-static uint32_t get_sme_reserved_address_bits(void)
+/* Number of most significant physical address bits reserved for secure memory encryption */
+unsigned int get_reserved_phys_addr_bits(void)
 {
 	if (rdmsr(SYSCFG_MSR).raw & SYSCFG_MSR_SMEE)
 		return (cpuid_ebx(CPUID_EBX_MEM_ENCRYPT) &
@@ -44,8 +45,3 @@ static uint32_t get_sme_reserved_address_bits(void)
 	else
 		return 0;
 }
-
-uint32_t get_usable_physical_address_bits(void)
-{
-	return cpu_phys_address_size() - get_sme_reserved_address_bits();
-}