]> git.ipfire.org Git - thirdparty/qemu.git/commit
i386/cpu: Select legacy cache model based on vendor in CPUID 0x8000001D
authorZhao Liu <zhao1.liu@intel.com>
Fri, 11 Jul 2025 10:21:42 +0000 (18:21 +0800)
committerPaolo Bonzini <pbonzini@redhat.com>
Sat, 12 Jul 2025 13:28:22 +0000 (15:28 +0200)
commit25acae4c6e7635ff0f0d36945548de4c0dc70608
tree5c17496f04853ba1df479215dd21a861c96fb8ed
parent00fa96c96a864e133c22a5f3793b468bb8a121a5
i386/cpu: Select legacy cache model based on vendor in CPUID 0x8000001D

As preparation for merging cache_info_cpuid4 and cache_info_amd in
X86CPUState, set legacy cache model based on vendor in the CPUID
0x8000001D leaf. For AMD CPU, select legacy AMD cache model (in
cache_info_amd) as the default cache model like before, otherwise,
select legacy Intel cache model (in cache_info_cpuid4).

In fact, for Intel (and Zhaoxin) CPU, this change is safe because the
extended CPUID level supported by Intel is up to 0x80000008. So Intel
Guest doesn't have this 0x8000001D leaf.

Although someone could bump "xlevel" up to 0x8000001D for Intel Guest,
it's meaningless and this is undefined behavior. This leaf should be
considered reserved, but the SDM does not explicitly state this. So,
there's no need to specifically use vendor_cpuid_only_v2 to fix
anything, as it doesn't even qualify as a fix since nothing is
currently broken.

Therefore, it is acceptable to select the default legacy cache model
based on the vendor.

For the CPUID 0x8000001D leaf, in X86CPUState, a unified cache_info is
enough. It only needs to be initialized and configured with the
corresponding legacy cache model based on the vendor.

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-18-zhao1.liu@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
target/i386/cpu.c