Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region

[Sean Christopherson <seanjc@google.com>]

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.
> 
>   [...]
> 
>   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... :-)