From: Wei Huang <wei@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
afaerber@suse.de, ehabkost@redhat.com
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/1] target-i386: prevent users from setting threads>1 for AMD CPUs
Date: Thu, 09 Oct 2014 15:22:02 -0500 [thread overview]
Message-ID: <5436EE6A.6030705@redhat.com> (raw)
In-Reply-To: <5434EC14.5060806@redhat.com>
On 10/08/2014 02:47 AM, Paolo Bonzini wrote:
> Il 08/10/2014 02:41, Wei Huang ha scritto:
>> 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...
>
> Understood---it actually looks like it was intentional:
>
> commit 400281af34e5ee6aa9f5496b53d8f82c6fef9319
> Author: Andre Przywara <andre.przywara@amd.com>
> Date: Wed Aug 19 15:42:42 2009 +0200
>
> set CPUID bits to present cores and threads topology
>
> Controlled by the enhanced -smp option set the CPUID bits to present the
> guest the desired topology. This is vendor specific, but (with the exception
> of the CMP_LEGACY bit) not conflicting, so we set all bits everytime.
> There is no real multithreading support for AMD CPUs, so report cores
> instead.
>
> Signed-off-by: Andre Przywara <andre.przywara@amd.com>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Given that back-ward compatibility is a concern, will the following work?
1. Instead of bailing out, print a warning message (e.g. to log file via
error_report) in QEMU.
2. [optional] Eduardo Habkost suggested that we can create a new machine
model which more strictly checks threads=n option for AMD. For any
existing machine config, we don't force it; but warning message still
applies. This is optional because it is a bit over-killed IMO.
3. Gives out a warning in virt-manager as well. This is similar to
"Overcomming CPUs will slow down performance" in current virt-manager
screen. The message will read "Chosen CPU model doesn't support
hyperthreading" or something similar.
-Wei
>
> Paolo
>
next prev parent reply other threads:[~2014-10-09 20:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 19:44 [Qemu-devel] [PATCH 1/1] target-i386: prevent users from setting threads>1 for AMD CPUs Wei Huang
2014-10-07 20:58 ` Paolo Bonzini
2014-10-07 21:16 ` Wei Huang
2014-10-07 21:36 ` Paolo Bonzini
2014-10-08 0:41 ` Wei Huang
2014-10-08 7:47 ` Paolo Bonzini
2014-10-09 20:22 ` Wei Huang [this message]
2014-10-09 21:08 ` Paolo Bonzini
2014-10-09 22:16 ` Eduardo Habkost
2014-10-21 15:11 ` Wei Huang
-- strict thread matches above, loose matches on Subject: below --
2014-10-07 19:17 Wei Huang
2014-10-07 19:42 ` Wei Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5436EE6A.6030705@redhat.com \
--to=wei@redhat.com \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).