[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/AMD: make HT range dynamic for Fam17 and up


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
  • Date: Fri, 18 Jun 2021 18:25:13 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=89VJQLXCF12yB6848z6j6LbU4nssVh1otDcC+GyiXQM=; b=ecwRWGhv3vWVkDwRRa3ZIllx1JPcpkOt74hNyc1kp3CmR47kW5dt21PYJ0c+7sXOP6p+HL6dw8g9u1jNxtpqrGCMX4ComX2MmMYpPMqJ0pvWe6VDGlmOnaccu2XdrUK+BIUF2bFHPCSHXKYsYGd4aFj0sMJBTcU3AmmMk5Fwx3O0grBDYUfp0T9egQsUUodNUkPjJwdv1clquVCwmjCmmsJup8OAe0cEV9H1usANw7skW6xS9bILQZnhGWhN5XRjud4ruXCuPv12RJ6nBk0XYTKGNhDPGLflA41h5vpH/PNUFct6FCl/2Zqk+ZXWPuOyrBBhGhnUjPvlLmQs+rZhnQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HCIo83evMgyIa6x7ZXj9kzN0NEVX60dwF8732j6mK3QbEhhlRx4NJKzHMgO1kdhtSj7VjcugfADc/5YOCFIaO5XJcy9sssESQNPqis15V9K40ngPvoRcIgInh3I3zEqvQlHrQvaDJK2Hu8D4Pdn/EUnXtwRum+0RwRB4an4JdAa2NkmerCf4PgxEqsw/CHA9lB8x/Zvj5hOjr1JDC1usLf0aATyetMTmxgDsrAwVTt/o3woEHgIODq/YI6nLs1zGR8TyPxJylunFTa9aYw66889kea4BepA+7vFHIpsnCkNhcHXdsxA1FOAEKskRqtpKjjzl5LMa3WZU4sMZEMIxtg==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 17:25:35 +0000
  • Ironport-hdrordr: A9a23:/NDAA6tOG/EG5uiYjCLX3ojH7skDjNV00zEX/kB9WHVpm6yj+v xGUs566faUskd0ZJhEo7q90ca7Lk80maQa3WBzB8bGYOCFghrKEGgK1+KLrwEIcxeUygc379 YDT0ERMrzN5VgRt7eG3OG7eexQvOVuJsqT9JjjJ3QGd3AVV0l5hT0JbTpyiidNNXJ77ZxSLu v72uN34wCOVF4wdcqBCnwMT4H41qf2fMKPW29+O/Y/gjP+9Q+V1A==
  • Ironport-sdr: DZQknM9K3i8mRakznPiQUeQfK9FxKYFiPyznlTVxkHnQIIeL+MhdVmW99eEZm0j0gr5sGkMKAO HT6KQR/eu4P4Mp1ZjuETPJXLn7EX4AlWME8YbD8SbHerXxan9allkaQfB3UxmLrtXT2iqUr8Xe ToZXF+oSo8oTMVJrQrZikU8DkJeUvy35c4OFuAgVlIpofk5LM5QhgTn9RS8wTIpwyqVCcLXWgm /tDsdpoh0Kxyg8a0EodqbD0k7qbnfhgmAHC9s/tjQkBbsXZWhnBgPEgdu43HTauvoHc7Hml//i AwE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18/06/2021 18:15, Igor Druzhinin wrote:
On 18/06/2021 17:00, Jan Beulich wrote:
At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
address range") documentation correctly stated that the range was
completely fixed. For Fam17 and newer, it lives at the top of physical
address space, though.

 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.

To correctly determine the top of physical address space, we need to
account for their physical address reduction, hence the calculation of
paddr_bits also gets adjusted.

While for paddr_bits < 40 the HT range is completely hidden, there's no
need to suppress the range insertion in that case: It'll just have no
real meaning.

Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -349,13 +349,17 @@ void __init early_cpu_init(void)
      eax = cpuid_eax(0x80000000);
      if ((eax >> 16) == 0x8000 && eax >= 0x80000008) {
+        ebx = eax >= 0x8000001f ? cpuid_ebx(0x8000001f) : 0;
          eax = cpuid_eax(0x80000008);
-        paddr_bits = eax & 0xff;
+

I understand Andrew has some concerns regarding changing paddr_bits but
some comment explaining what's located at 0x8000001f:ebx[11:6] and why
we're doing this might be useful.

+        paddr_bits = (eax & 0xff) - ((ebx >> 6) & 0x3f);
          if (paddr_bits > PADDR_BITS)
              paddr_bits = PADDR_BITS;
+
          vaddr_bits = (eax >> 8) & 0xff;
          if (vaddr_bits > VADDR_BITS)
              vaddr_bits = VADDR_BITS;
+
          hap_paddr_bits = ((eax >> 16) & 0xff) ?: paddr_bits;
          if (hap_paddr_bits > PADDR_BITS)
              hap_paddr_bits = PADDR_BITS;
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -524,8 +524,11 @@ int __init dom0_setup_permissions(struct
                                           MSI_ADDR_DEST_ID_MASK));
      /* HyperTransport range. */
      if ( boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
-        rc |= iomem_deny_access(d, paddr_to_pfn(0xfdULL << 32),
-                                paddr_to_pfn((1ULL << 40) - 1));
+    {
+        mfn = paddr_to_pfn(1UL <<
+                           (boot_cpu_data.x86 < 0x17 ? 40 : paddr_bits));

That doesn't really follow what Andrew gave us, namely:

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)

Do we need (1) to be coded here as well?

Ignore this last paragraph - I lost your statement in comment description.

Igor



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.