From: Zhao Liu <zhao1.liu@intel.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Babu Moger" <babu.moger@amd.com>,
"Ewan Hai" <ewanhai-oc@zhaoxin.com>, "Pu Wen" <puwen@hygon.cn>,
"Tao Su" <tao1.su@intel.com>, "Yi Lai" <yi1.lai@intel.com>,
"Dapeng Mi" <dapeng1.mi@intel.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: [PATCH 03/16] i386/cpu: Add default cache model for Intel CPUs with level < 4
Date: Fri, 20 Jun 2025 17:27:21 +0800 [thread overview]
Message-ID: <20250620092734.1576677-4-zhao1.liu@intel.com> (raw)
In-Reply-To: <20250620092734.1576677-1-zhao1.liu@intel.com>
Old Intel CPUs with CPUID level < 4, use CPUID 0x2 leaf (if available)
to encode cache information.
Introduce a cache model "legacy_intel_cpuid2_cache_info" for the CPUs
with CPUID level < 4, based on legacy_l1d_cache, legacy_l1i_cache,
legacy_l2_cache_cpuid2 and legacy_l3_cache. But for L2 cache, this
cache model completes self_init, sets, partitions, no_invd_sharing and
share_level fields, referring legacy_l2_cache, to avoid someone
increases CPUID level manually and meets assert() error. But the cache
information present in CPUID 0x2 leaf doesn't change.
This new cache model makes it possible to remove legacy_l2_cache_cpuid2
in X86CPUState and help to clarify historical cache inconsistency issue.
Furthermore, apply this legacy cache model to all Intel CPUs with CPUID
level < 4. This includes not only "pentium2" and "pentium3" (which have
0x2 leaf), but also "486" and "pentium" (which only have 0x1 leaf, and
cache model won't be presented, just for simplicity).
A legacy_intel_cpuid2_cache_info cache model doesn't change the cache
information of the above CPUs, because they just depend on 0x2 leaf.
Only when someone adjusts the min-level to >=4 will the cache
information in CPUID leaf 4 differ from before: previously, the L2
cache information in CPUID leaf 0x2 and 0x4 was different, but now with
legacy_intel_cpuid2_cache_info, the information they present will be
consistent. This case almost never happens, emulating a CPUID that is
not supported by the "ancient" hardware is itself meaningless behavior.
Therefore, even though there's the above difference (for really rare
case) and considering these old CPUs ("486", "pentium", "pentium2" and
"pentium3") won't be used for migration, there's no need to add new
versioned CPU models
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
target/i386/cpu.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 995766c9d74c..0a2c32214cc3 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -710,6 +710,67 @@ static CPUCacheInfo legacy_l3_cache = {
.share_level = CPU_TOPOLOGY_LEVEL_DIE,
};
+/*
+ * Only used for the CPU models with CPUID level < 4.
+ * These CPUs (CPUID level < 4) only use CPUID leaf 2 to present
+ * cache information.
+ *
+ * Note: This cache model is just a default one, and is not
+ * guaranteed to match real hardwares.
+ */
+static const CPUCaches legacy_intel_cpuid2_cache_info = {
+ .l1d_cache = &(CPUCacheInfo) {
+ .type = DATA_CACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+ .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+ },
+ .l1i_cache = &(CPUCacheInfo) {
+ .type = INSTRUCTION_CACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+ .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+ },
+ .l2_cache = &(CPUCacheInfo) {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 2 * MiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 4096,
+ .partitions = 1,
+ .no_invd_sharing = true,
+ .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+ },
+ .l3_cache = &(CPUCacheInfo) {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 16 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .sets = 16384,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+ .share_level = CPU_TOPOLOGY_LEVEL_DIE,
+ },
+};
+
/* TLB definitions: */
#define L1_DTLB_2M_ASSOC 1
@@ -3043,6 +3104,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
I486_FEATURES,
.xlevel = 0,
.model_id = "",
+ .cache_info = &legacy_intel_cpuid2_cache_info,
},
{
.name = "pentium",
@@ -3055,6 +3117,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
PENTIUM_FEATURES,
.xlevel = 0,
.model_id = "",
+ .cache_info = &legacy_intel_cpuid2_cache_info,
},
{
.name = "pentium2",
@@ -3067,6 +3130,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
PENTIUM2_FEATURES,
.xlevel = 0,
.model_id = "",
+ .cache_info = &legacy_intel_cpuid2_cache_info,
},
{
.name = "pentium3",
@@ -3079,6 +3143,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
PENTIUM3_FEATURES,
.xlevel = 0,
.model_id = "",
+ .cache_info = &legacy_intel_cpuid2_cache_info,
},
{
.name = "athlon",
--
2.34.1
next prev parent reply other threads:[~2025-06-20 9:06 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 9:27 [PATCH 00/16] i386/cpu: Unify the cache model in X86CPUState Zhao Liu
2025-06-20 9:27 ` [PATCH 01/16] i386/cpu: Refine comment of CPUID2CacheDescriptorInfo Zhao Liu
2025-07-02 8:48 ` Mi, Dapeng
2025-07-03 7:38 ` Zhao Liu
2025-06-20 9:27 ` [PATCH 02/16] i386/cpu: Add descriptor 0x49 for CPUID 0x2 encoding Zhao Liu
2025-07-02 9:04 ` Mi, Dapeng
2025-07-03 7:39 ` Zhao Liu
2025-06-20 9:27 ` Zhao Liu [this message]
2025-07-02 9:53 ` [PATCH 03/16] i386/cpu: Add default cache model for Intel CPUs with level < 4 Mi, Dapeng
2025-07-03 7:47 ` Zhao Liu
2025-06-20 9:27 ` [PATCH 04/16] i386/cpu: Present same cache model in CPUID 0x2 & 0x4 Zhao Liu
2025-07-03 4:14 ` Mi, Dapeng
2025-07-03 6:35 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 05/16] i386/cpu: Consolidate CPUID 0x4 leaf Zhao Liu
2025-06-26 12:10 ` Ewan Hai
2025-06-27 2:44 ` Zhao Liu
2025-07-03 6:41 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 06/16] i386/cpu: Drop CPUID 0x2 specific cache info in X86CPUState Zhao Liu
2025-07-03 7:03 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 07/16] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel Zhao Liu
2025-07-03 7:07 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 08/16] i386/cpu: Fix CPUID[0x80000006] for Intel CPU Zhao Liu
2025-07-03 7:09 ` Mi, Dapeng
2025-07-03 7:52 ` Zhao Liu
2025-06-20 9:27 ` [PATCH 09/16] i386/cpu: Add legacy_intel_cache_info cache model Zhao Liu
2025-07-03 7:15 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 10/16] i386/cpu: Add legacy_amd_cache_info " Zhao Liu
2025-07-03 7:18 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 11/16] i386/cpu: Select legacy cache model based on vendor in CPUID 0x2 Zhao Liu
2025-07-03 8:47 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 12/16] i386/cpu: Select legacy cache model based on vendor in CPUID 0x4 Zhao Liu
2025-07-03 8:49 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 13/16] i386/cpu: Select legacy cache model based on vendor in CPUID 0x80000005 Zhao Liu
2025-07-03 8:52 ` Mi, Dapeng
2025-06-20 9:27 ` [PATCH 14/16] i386/cpu: Select legacy cache model based on vendor in CPUID 0x80000006 Zhao Liu
2025-06-20 9:27 ` [PATCH 15/16] i386/cpu: Select legacy cache model based on vendor in CPUID 0x8000001D Zhao Liu
2025-06-20 9:27 ` [PATCH 16/16] i386/cpu: Use a unified cache_info in X86CPUState Zhao Liu
2025-07-03 8:53 ` Mi, Dapeng
2025-07-03 9:50 ` 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=20250620092734.1576677-4-zhao1.liu@intel.com \
--to=zhao1.liu@intel.com \
--cc=babu.moger@amd.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@intel.com \
--cc=eduardo@habkost.net \
--cc=ewanhai-oc@zhaoxin.com \
--cc=imammedo@redhat.com \
--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=puwen@hygon.cn \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=tao1.su@intel.com \
--cc=yi1.lai@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 NNTP newsgroup(s).