Re: [Qemu-devel] [PATCH] tcg/i386: Do not display HT warning for TCG

[Eduardo Habkost <ehabkost@redhat.com>]

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