All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] CPU topology and ordering in ACPI MADT
@ 2016-07-02  0:51 Eduardo Habkost
  0 siblings, 0 replies; only message in thread
From: Eduardo Habkost @ 2016-07-02  0:51 UTC (permalink / raw)
  To: qemu-devel; +Cc: libvir-list, Igor Mammedov, pkrempa

I got a bug report yesterday that seems to be related to how CPUs
are ordered 'lscpu' and /proc/cpuinfo:
https://bugzilla.redhat.com/show_bug.cgi?id=1351160

It's not an actual bug, but it's not the first time I see people
confused by CPU numbers not following socket/core/thread IDs in
lscpu and /proc/cpuinfo in the host (making CPU numbers seen in
the guest not matching CPU numbers in the host).

The ordering in /proc/cpuinfo and lscpu seems to come from the
MADT ACPI table, and on some hosts it looks completely
arbitrary[1].

Now that we will allow the APIC ID (or socket/core/thread IDs) to
be explicitly set in each VCPU, we could let management make CPU
ordering match the host exactly, for people that really want to
reproduce the host topology and get easily confused by CPU
numbers that don't match the host.

But this is lot of data to be provided to QEMU, so I don't see it
as an useful feature unless it can be represented in the libvirt
XML configuration in a more compact way, or generated
automatically based on the host. I'm CCing libvir-list to see if
they have any ideas.

...or we could just tell users that sometimes it will be
impossible to make the CPU numbers in the guest match the ones in
the host. To be honest, I am more inclined towards this option,
but I would like to hear your opinions.


[1] Example of lscpu output from a host that doesn't follow
socket/core/thread ID on the MADT table:

# lscpu -e
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
0   1    0      0    0:0:0:0       yes
1   0    1      1    1:1:1:1       yes
2   1    0      2    2:2:2:0       yes
3   0    1      3    3:3:3:1       yes
4   1    0      4    4:4:4:0       yes
5   0    1      5    5:5:5:1       yes
6   1    0      6    6:6:6:0       yes
7   0    1      7    7:7:7:1       yes
8   1    0      8    8:8:8:0       yes
9   0    1      9    9:9:9:1       yes
10  1    0      10   10:10:10:0    yes
11  0    1      11   11:11:11:1    yes
12  1    0      0    0:0:0:0       yes
13  0    1      1    1:1:1:1       yes
14  1    0      2    2:2:2:0       yes
15  0    1      3    3:3:3:1       yes
16  1    0      4    4:4:4:0       yes
17  0    1      5    5:5:5:1       yes
18  1    0      6    6:6:6:0       yes
19  0    1      7    7:7:7:1       yes
20  1    0      8    8:8:8:0       yes
21  0    1      9    9:9:9:1       yes
22  1    0      10   10:10:10:0    yes
23  0    1      11   11:11:11:1    yes
# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Model name:            Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz
Stepping:              2
CPU MHz:               2266.000
BogoMIPS:              4533.26
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23
NUMA node1 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22
# 


-- 
Eduardo

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2016-07-02  0:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-02  0:51 [Qemu-devel] CPU topology and ordering in ACPI MADT Eduardo Habkost

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.