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>

1 files changed, 6 insertions, 1 deletions

diff --git a/src/soc/amd/common/block/cpu/smm/smm_relocate.c b/src/soc/amd/common/block/cpu/smm/smm_relocate.c
index 4004726e29..ae008853bd 100644
--- a/src/soc/amd/common/block/cpu/smm/smm_relocate.c
+++ b/src/soc/amd/common/block/cpu/smm/smm_relocate.c
@@ -65,6 +65,11 @@ static void smm_relocation_handler(void)
 	uintptr_t tseg_base;
 	size_t tseg_size;
 
+	/* For the TSEG masks all physical address bits including the ones reserved for memory
+	   encryption need to be taken into account. TODO: Find out why this is the case */
+	const unsigned int total_physical_address_bits =
+		cpu_phys_address_size() + get_reserved_phys_addr_bits();
+
 	smm_region(&tseg_base, &tseg_size);
 
 	msr_t msr;
@@ -73,7 +78,7 @@ static void smm_relocation_handler(void)
 
 	msr.lo = ~(tseg_size - 1);
 	msr.lo |= SMM_TSEG_WB;
-	msr.hi = (1 << (cpu_phys_address_size() - 32)) - 1;
+	msr.hi = (1 << (total_physical_address_bits - 32)) - 1;
 	wrmsr(SMM_MASK_MSR, msr);
 
 	uintptr_t smbase = smm_get_cpu_smbase(cpu_index());