From: Zhao Liu <zhao1.liu@intel.com>
To: "Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Zhenyu Wang <zhenyu.z.wang@intel.com>,
Zhuocheng Ding <zhuocheng.ding@intel.com>,
Babu Moger <babu.moger@amd.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Dapeng Mi <dapeng1.mi@intel.com>,
Yongwei Ma <yongwei.ma@intel.com>, Zhao Liu <zhao1.liu@intel.com>
Subject: [PATCH v11 01/21] hw/core/machine: Introduce the module as a CPU topology level
Date: Wed, 24 Apr 2024 23:49:09 +0800 [thread overview]
Message-ID: <20240424154929.1487382-2-zhao1.liu@intel.com> (raw)
In-Reply-To: <20240424154929.1487382-1-zhao1.liu@intel.com>
In x86, module is the topology level above core, which contains a set
of cores that share certain resources (in current products, the resource
usually includes L2 cache, as well as module scoped features and MSRs).
Though smp.clusters could also share the L2 cache resource [1], there
are following reasons that drive us to introduce the new smp.modules:
* As the CPU topology abstraction in device tree [2], cluster supports
nesting (though currently QEMU hasn't support that). In contrast,
(x86) module does not support nesting.
* Due to nesting, there is great flexibility in sharing resources
on cluster, rather than narrowing cluster down to sharing L2 (and
L3 tags) as the lowest topology level that contains cores.
* Flexible nesting of cluster allows it to correspond to any level
between the x86 package and core.
* In Linux kernel, x86's cluster only represents the L2 cache domain
but QEMU's smp.clusters is the CPU topology level. Linux kernel will
also expose module level topology information in sysfs for x86. To
avoid cluster ambiguity and keep a consistent CPU topology naming
style with the Linux kernel, we introduce module level for x86.
The module is, in existing hardware practice, the lowest layer that
contains the core, while the cluster is able to have a higher
topological scope than the module due to its nesting.
Therefore, place the module between the cluster and the core:
drawer/book/socket/die/cluster/module/core/thread
With the above topological hierarchy order, introduce module level
support in MachineState and MachineClass.
[1]: https://lore.kernel.org/qemu-devel/c3d68005-54e0-b8fe-8dc1-5989fe3c7e69@huawei.com/
[2]: https://www.kernel.org/doc/Documentation/devicetree/bindings/cpu/cpu-topology.txt
Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
---
Changes since v8:
* Add the reason of why a new module level is needed in commit message.
(Markus).
* Add the description about how Linux kernel supports x86 module level.
(Daniel)
Changes since v7:
* New commit to introduce module level in -smp.
---
hw/core/machine-smp.c | 2 +-
hw/core/machine.c | 1 +
include/hw/boards.h | 4 ++++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/core/machine-smp.c b/hw/core/machine-smp.c
index 27864c950766..2e68fcfdfd79 100644
--- a/hw/core/machine-smp.c
+++ b/hw/core/machine-smp.c
@@ -266,7 +266,7 @@ void machine_parse_smp_config(MachineState *ms,
unsigned int machine_topo_get_cores_per_socket(const MachineState *ms)
{
- return ms->smp.cores * ms->smp.clusters * ms->smp.dies;
+ return ms->smp.cores * ms->smp.modules * ms->smp.clusters * ms->smp.dies;
}
unsigned int machine_topo_get_threads_per_socket(const MachineState *ms)
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 582c2df37aaf..996664115939 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1157,6 +1157,7 @@ static void machine_initfn(Object *obj)
ms->smp.sockets = 1;
ms->smp.dies = 1;
ms->smp.clusters = 1;
+ ms->smp.modules = 1;
ms->smp.cores = 1;
ms->smp.threads = 1;
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 69c1ba45cf94..2fa800f11ae4 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -144,6 +144,7 @@ typedef struct {
* provided SMP configuration
* @books_supported - whether books are supported by the machine
* @drawers_supported - whether drawers are supported by the machine
+ * @modules_supported - whether modules are supported by the machine
*/
typedef struct {
bool prefer_sockets;
@@ -152,6 +153,7 @@ typedef struct {
bool has_clusters;
bool books_supported;
bool drawers_supported;
+ bool modules_supported;
} SMPCompatProps;
/**
@@ -339,6 +341,7 @@ typedef struct DeviceMemoryState {
* @sockets: the number of sockets in one book
* @dies: the number of dies in one socket
* @clusters: the number of clusters in one die
+ * @modules: the number of modules in one cluster
* @cores: the number of cores in one cluster
* @threads: the number of threads in one core
* @max_cpus: the maximum number of logical processors on the machine
@@ -350,6 +353,7 @@ typedef struct CpuTopology {
unsigned int sockets;
unsigned int dies;
unsigned int clusters;
+ unsigned int modules;
unsigned int cores;
unsigned int threads;
unsigned int max_cpus;
--
2.34.1
next prev parent reply other threads:[~2024-04-24 15:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 15:49 [PATCH v11 00/21] i386: Introduce smp.modules and clean up cache topology Zhao Liu
2024-04-24 15:49 ` Zhao Liu [this message]
2024-04-24 15:49 ` [PATCH v11 02/21] hw/core/machine: Support modules in -smp Zhao Liu
2024-04-24 15:49 ` [PATCH v11 03/21] hw/core: Introduce module-id as the topology subindex Zhao Liu
2024-04-24 15:49 ` [PATCH v11 04/21] hw/core: Support module-id in numa configuration Zhao Liu
2024-04-24 15:49 ` [PATCH v11 05/21] i386/cpu: Fix i/d-cache topology to core level for Intel CPU Zhao Liu
2024-04-24 15:49 ` [PATCH v11 06/21] i386/cpu: Use APIC ID info to encode cache topo in CPUID[4] Zhao Liu
2024-04-24 15:49 ` [PATCH v11 07/21] i386/cpu: Use APIC ID info get NumSharingCache for CPUID[0x8000001D].EAX[bits 25:14] Zhao Liu
2024-04-24 15:49 ` [PATCH v11 08/21] i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid() Zhao Liu
2024-04-24 15:49 ` [PATCH v11 09/21] i386/cpu: Introduce bitmap to cache available CPU topology levels Zhao Liu
2024-04-24 15:49 ` [PATCH v11 10/21] i386: Split topology types of CPUID[0x1F] from the definitions of CPUID[0xB] Zhao Liu
2024-04-24 15:49 ` [PATCH v11 11/21] i386/cpu: Decouple CPUID[0x1F] subleaf with specific topology level Zhao Liu
2024-04-24 15:49 ` [PATCH v11 12/21] i386: Introduce module level cpu topology to CPUX86State Zhao Liu
2024-04-24 15:49 ` [PATCH v11 13/21] i386: Support modules_per_die in X86CPUTopoInfo Zhao Liu
2024-04-24 15:49 ` [PATCH v11 14/21] i386: Expose module level in CPUID[0x1F] Zhao Liu
2024-04-24 15:49 ` [PATCH v11 15/21] i386: Support module_id in X86CPUTopoIDs Zhao Liu
2024-04-24 15:49 ` [PATCH v11 16/21] i386/cpu: Introduce module-id to X86CPU Zhao Liu
2024-04-24 15:49 ` [PATCH v11 17/21] tests: Add test case of APIC ID for module level parsing Zhao Liu
2024-04-24 15:49 ` [PATCH v11 18/21] hw/i386/pc: Support smp.modules for x86 PC machine Zhao Liu
2024-04-24 15:49 ` [PATCH v11 19/21] i386: Add cache topology info in CPUCacheInfo Zhao Liu
2024-04-30 6:14 ` Tejus GK
2024-05-06 7:32 ` Zhao Liu
2024-04-24 15:49 ` [PATCH v11 20/21] i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[4] Zhao Liu
2024-04-24 15:49 ` [PATCH v11 21/21] i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[0x8000001D].EAX[bits 25:14] Zhao Liu
2024-04-25 8:06 ` [PATCH v11 00/21] i386: Introduce smp.modules and clean up cache topology Philippe Mathieu-Daudé
2024-04-25 13:30 ` Zhao Liu
2024-05-15 14:48 ` Zhao Liu
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=20240424154929.1487382-2-zhao1.liu@intel.com \
--to=zhao1.liu@intel.com \
--cc=armbru@redhat.com \
--cc=babu.moger@amd.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@intel.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wangyanan55@huawei.com \
--cc=xiaoyao.li@intel.com \
--cc=yongwei.ma@intel.com \
--cc=zhenyu.z.wang@intel.com \
--cc=zhuocheng.ding@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).