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

From: Paolo Bonzini <pbonzini@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>,
	Maxim Levitsky <mlevitsk@redhat.com>
Cc: stable@vger.kernel.org, David Matlack <dmatlack@google.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region
Date: Mon, 9 Aug 2021 12:23:21 +0200	[thread overview]
Message-ID: <ac72b77c-f633-923b-8019-69347db706be@redhat.com> (raw)
In-Reply-To: <bab67d1c-f9b7-0a91-2d4f-9881e3f47218@oracle.com>

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@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.

Paolo