All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Cc: Wei Liu <wl@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Pu Wen <puwen@hygon.cn>, Brian Woods <brian.woods@amd.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] x86/AMD: make use of CPUID leaf 0xb when available
Date: Fri, 07 Jun 2019 06:50:09 -0600	[thread overview]
Message-ID: <5CFA5D8102000078002363C1@prv1-mh.provo.novell.com> (raw)

Initially I did simply stumble across a backport of Linux commit
e0ceeae708 ("x86/CPU/hygon: Fix phys_proc_id calculation logic for
multi-die processors") to our kernels. There I got puzzled by the claim
that a similar change isn't needed on the AMD side. As per the web page
cited [1], there aren't supposed to be affected AMD processors, but
according to my reading there are: The EPYC 7000 series comes with 8,
16, 24, or 32 cores, which I imply to be 1, 2, 3, or 4 die processors.
And many of them have "1P/2P" in the "socket count" column. Therefore
our calculation, being based on CPUID.80000008.EBX[15:12], would be
similarly wrong on such 2-socket 1- or 2-die systems.

Checking Linux code I then found that they don't even rely on the
calculation we currently use anymore, at least not in the case when
leaf 0xb is available (which is the case on Fam17). Let's follow
Suravee's Linux commit 3986a0a805 ("x86/CPU/AMD: Derive CPU topology
from CPUID function 0xB when available") in this regard to address this.

To avoid logging duplicate information, make the function return bool.
Move its and detect_ht()'s declaration to a private header at the same
time.

[1] https://www.amd.com/en/products/specifications/processors 

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I wonder whether Hygon code wouldn't better call
detect_extended_topology() as well.

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -515,6 +515,13 @@ static void amd_get_topology(struct cpui
                         c->cpu_core_id = ebx & 0xFF;
                         c->x86_max_cores /= c->x86_num_siblings;
                 }
+
+                /*
+                 * In case leaf B is available, use it to derive
+                 * topology information.
+                 */
+                if (detect_extended_topology(c))
+                        return;
         }
         
         if (opt_cpu_info)
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -533,7 +533,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
  * Check for extended topology enumeration cpuid leaf 0xb and if it
  * exists, use it for cpu topology detection.
  */
-void detect_extended_topology(struct cpuinfo_x86 *c)
+bool detect_extended_topology(struct cpuinfo_x86 *c)
 {
 	unsigned int eax, ebx, ecx, edx, sub_index;
 	unsigned int ht_mask_width, core_plus_mask_width;
@@ -541,13 +541,13 @@ void detect_extended_topology(struct cpu
 	unsigned int initial_apicid;
 
 	if ( c->cpuid_level < 0xb )
-		return;
+		return false;
 
 	cpuid_count(0xb, SMT_LEVEL, &eax, &ebx, &ecx, &edx);
 
 	/* Check if the cpuid leaf 0xb is actually implemented */
 	if ( ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE) )
-		return;
+		return false;
 
 	__set_bit(X86_FEATURE_XTOPOLOGY, c->x86_capability);
 
@@ -588,6 +588,8 @@ void detect_extended_topology(struct cpu
 			printk("CPU: Processor Core ID: %d\n",
 			       c->cpu_core_id);
 	}
+
+	return true;
 }
 
 void detect_ht(struct cpuinfo_x86 *c)
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -14,5 +14,8 @@ extern unsigned int opt_cpuid_mask_ext_e
 
 extern int get_model_name(struct cpuinfo_x86 *c);
 extern void display_cacheinfo(struct cpuinfo_x86 *c);
+
+extern void detect_ht(struct cpuinfo_x86 *c);
+extern bool detect_extended_topology(struct cpuinfo_x86 *c);
 
 void early_init_amd(struct cpuinfo_x86 *c);
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -170,10 +170,6 @@ extern void setup_force_cpu_cap(unsigned
 extern void print_cpu_info(unsigned int cpu);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 
-extern void detect_extended_topology(struct cpuinfo_x86 *c);
-
-extern void detect_ht(struct cpuinfo_x86 *c);
-
 #define cpu_to_core(_cpu)   (cpu_data[_cpu].cpu_core_id)
 #define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id)
 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

             reply	other threads:[~2019-06-07 12:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 12:50 Jan Beulich [this message]
2019-06-07 12:53 ` [Xen-devel] [PATCH] x86/AMD: make use of CPUID leaf 0xb when available Andrew Cooper
2019-06-07 13:07   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5CFA5D8102000078002363C1@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=brian.woods@amd.com \
    --cc=puwen@hygon.cn \
    --cc=roger.pau@citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.