aboutsummaryrefslogtreecommitdiff
path: root/scripts/tracetool/backend/simple.py
diff options
context:
space:
mode:
authorZhao Liu <zhao1.liu@intel.com>2025-07-11 18:21:28 +0800
committerPaolo Bonzini <pbonzini@redhat.com>2025-07-12 15:28:21 +0200
commit2c70a50c8c3d8620f34884b340778358b6faf5d4 (patch)
tree56f2ee6f8281b78d7dd1b52b59bf9aca08ac5bf8 /scripts/tracetool/backend/simple.py
parent67d54014afcfdd316a0e9c979a0ff8145d4cf963 (diff)
downloadqemu-2c70a50c8c3d8620f34884b340778358b6faf5d4.zip
qemu-2c70a50c8c3d8620f34884b340778358b6faf5d4.tar.gz
qemu-2c70a50c8c3d8620f34884b340778358b6faf5d4.tar.bz2
i386/cpu: Add default cache model for Intel CPUs with level < 4
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 Tested-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250711102143.1622339-4-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'scripts/tracetool/backend/simple.py')
0 files changed, 0 insertions, 0 deletions