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@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. So, about that update... :-)
