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

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


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 18 Jun 2021 18:00:19 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=gDu8v9Z6S9LCduvADm2MEdzkMI9LRIFgjRlVPFAk6+k=; b=PNfnMdwokdFkZmMFu02E13ESOC24hcV1Cv/PVB/WJ9JzLIq2tIfjHIM78r6CxpOhzCqkVMDcUPdePCGo1HDGd1sFxk1uHGnnSCgUtAQHY8cD6VRjmSZi5PwXv2CnhMygM+TyBEltZoWpLyI4lJopcQi2tDEqPmxN/6qhvbgy9nG4MgRtuxKB1XHTyOvLn7By53+ksYWTRNF8shO+ghov11hHgcMqZ4tLV4X5bHeirL76uCjvuZ4giPhkeKpsavinZrLttBm51efgYEEaVvBnobHS2wVG86XSJtwiQ8S9lEUFWAwQPXoe8eqpUh/4+/oSkSKxdALdFYigWY49X48cKw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMfvnT1t2ckkboxwxZkK92n++C5W6YLHO7iDPu9RzDhICL/bBUrWBmCE3VkkGQFiRjqe8IsLpBvK5vHHkn0X2N6MlWjv00w3VQck30jelQ6GKmb0JytUTSoTzcGA9I/4+RnM756JiQis5IjPisCYwDR/1prNlzha7CUHCAkeuHS5zOSgfkUQ5+GK187cggqUiJ5riL+I1VG/QuAAdHVmlGkp8lFP/bXaguUgzNIM5YloID9Lc9TN3IQTuK3kHyWldJumsc2QvesA4CZdjc44pcNnMRnsXxQKo6NkdRbfy5RCw/t45/x7evSwovc9Y7StHQbgHXV4Nh5OTOJnYWdHoQ==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 16:00:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

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;
+
+               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));
+        rc |= iomem_deny_access(d, mfn - paddr_to_pfn(3UL << 32), mfn - 1);
+    }
 
     /* Remove access to E820_UNUSABLE I/O regions above 1MB. */
     for ( i = 0; i < e820.nr_map; i++ )




 


Rackspace

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