On Mon, Aug 09, 2021, Paolo Bonzini wrote:
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@citrix.com/):
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.
[...]
- On parts with <40 bits, its fully hidden from software
- 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.
So, about that update... :-)