qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] target-i386: prevent users from setting thr


From: Wei Huang
Subject: Re: [Qemu-devel] [PATCH 1/1] target-i386: prevent users from setting threads>1 for AMD CPUs
Date: Tue, 07 Oct 2014 19:41:52 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0



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"?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]