aboutsummaryrefslogtreecommitdiff
path: root/stubs/colo.c
diff options
context:
space:
mode:
authorZhao Liu <zhao1.liu@intel.com>2023-06-28 21:54:37 +0800
committerMichael S. Tsirkin <mst@redhat.com>2023-07-10 16:17:08 -0400
commit196ea60a734c346d7d75f1d89aa37703d4d854e7 (patch)
tree5693332e7626e36a4402daf219603d49e9f17497 /stubs/colo.c
parent7298fd7de5551c4501f54381228458e3c21cab4b (diff)
downloadqemu-196ea60a734c346d7d75f1d89aa37703d4d854e7.zip
qemu-196ea60a734c346d7d75f1d89aa37703d4d854e7.tar.gz
qemu-196ea60a734c346d7d75f1d89aa37703d4d854e7.tar.bz2
hw/smbios: Fix core count in type4
>From SMBIOS 3.0 specification, core count field means: Core Count is the number of cores detected by the BIOS for this processor socket. [1] Before 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology"), MachineState.smp.cores means "the number of cores in one package", and it's correct to use smp.cores for core count. But 003f230e37d7 changes the smp.cores' meaning to "the number of cores in one die" and doesn't change the original smp.cores' use in smbios as well, which makes core count in type4 go wrong. Fix this issue with the correct "cores per socket" caculation. [1] SMBIOS 3.0.0, section 7.5.6, Processor Information - Core Count Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'stubs/colo.c')
0 files changed, 0 insertions, 0 deletions