Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region
From: Paolo Bonzini
Date: Mon Aug 09 2021 - 06:23:33 EST
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