On 09/08/21 12:00, Joao Martins wrote:
[0]https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf 1286 Spurious #GP May Occur When Hypervisor Running on Another Hypervisor Description The processor may incorrectly generate a #GP fault if a hypervisor running on a hypervisor attempts to access the following secure memory areas: • The reserved memory address region starting at FFFD_0000_0000h and extending up to FFFF_FFFF_FFFFh. • ASEG and TSEG memory regions for SMM (System Management Mode) • MMIO APIC Space
This errata took a few months to debug so we're quite familiar with it :) but I only knew about the ASEG/TSEG/APIC cases.
So this HyperTransport region is not related to this issue, but the errata does point out that FFFD_0000_0000h and upwards is special in guests.
The Xen folks also had to deal with it only a couple months ago (https://yhbt.net/lore/all/1eb16baa-6b1b-3b18-c712-4459bd83e1aa@xxxxxxxxxx/):
From "Open-Source Register Reference for AMD Family 17h Processors (PUB)":
https://developer.amd.com/wp-content/resources/56255_3_03.PDF "The processor defines a reserved memory address region starting at FFFD_0000_0000h and extending up to FFFF_FFFF_FFFFh." It's still doesn't say that it's at the top of physical address space although I understand that's how it's now implemented. The official document doesn't confirm it will move along with physical address space extension. [...] 1) On parts with <40 bits, its fully hidden from software 2) Before Fam17h, it was always 12G just below 1T, even if there was more RAM above this location 3) On Fam17h and later, it is variable based on SME, and is either just below 2^48 (no encryption) or 2^43 (encryption)
It's interesting that fn8000_000A EDX[28] is part of the reserved bits from that CPUID leaf.
It's only been defined after AMD deemed that the errata was not fixable in current generation processors); it's X86_FEATURE_SVME_ADDR_CHK now.
I'll update the patch based on the findings from the Xen team. Paolo
