On Fri, Apr 21, 2017 at 11:38:30AM +0200, Paolo Bonzini wrote: > > > On 20/04/2017 20:42, Eduardo Habkost wrote: > >> -smp 4,threads=4 shows 4 cores > > This means 1 socket with 1 core, 4 threads per core. But if > > vendor ID is AMD, guests will probably ignore the hyperthreading > > info and treat each thread as a separate core. That's why we have > > a warning. > > I'm not sure about the "probably". As long as the HT bit is 1 and the > number of threads is > 1 in CPUID[EAX=1].EBX[bits 23:16], I am not sure > why the OS would care about the vendor. >
On my testing, "-cpu qemu64,vendor=AuthenticAMD" and "-cpu qemu64,vendor=GenuineIntel" gave different results on lscpu and /proc/cpuinfo in a Fedora 25 guest (Linux 4.8.6-300.fc25). > x86info does care (it just does not try to detect the topology for > !Intel processors), but Linux seems not to. detect_ht is called > unconditionally. I see detect_ht() inside a "#ifdef CONFIG_X86_32" in amd_cpu_dev.c_init (init_amd()), and intel_cpudev.c_init (init_intel()). It is inside a "#ifdef CONFIG_X86_64" in identify_cpu(), though, so it looks like it is called at different places, but always called. But the logic becomes very confusing after that: the core/sibling CPU masks are initialized based on phys_proc_id and cpu_core_id, and detect_ht() isn't the only place where those fields are initialized (see amd_get_topology(), amd_detect_cmp(), detect_extended_topology()). It looks like amd_detect_cmp() and/or amd_get_topology() will undo what detect_ht() did. -- Eduardo
