On 10/07/2014 04:36 PM, Paolo Bonzini wrote:
Il 07/10/2014 23:16, Wei Huang ha scritto:
It isn't a bug IMO. I tested various combinations; and current QEMU
handles it very well. It converts threads=n to proper
CPUID_0000_0001_EBX[LogicalProcCount] and CPUID_8000_0008_ECX[NC]
accordingly for AMD.
So if it ain't broken, don't fix it. :)
I am worried that the default CPU is an AMD one when KVM is disabled,
and thus "qemu-system-x86_64 -smp threads=2" will likely be broken.
"-smp threads=2" will be rejected by the patch.
Yeah, I am afraid that is an incompatible change, and one more reason
not to do this. AMD not selling hyperthreaded processors does not mean
that they could not be represented properly with the CPUID leaves that
AMD processors support.
I am OK with either way. The key question is: should QEMU presents
CPUIDs strictly as specified by the command line or QEMU can tweak a
little bit on behalf of end-users? For instance, if end-users say "-smp
8,cores=2,threads=2,sockets=2", they meant "two socket, each has two
2-hyperthread cores". Current QEMU will convert CPUID as "two socket,
each has 4 cores". My patch will forbid the tweaking...
-Wei
Paolo
Unless the meaning of
threads is not limited to threads-per-core, shouldn't end users use
"-smp 2" in this case or something like "-smp 2,cores=2,sockets=1"?
