qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Babu Moger <babu.moger@amd.com>
Cc: mst@redhat.com, marcel.apfelbaum@gmail.com, pbonzini@redhat.com,
	rth@twiddle.net, mtosatti@redhat.com, qemu-devel@nongnu.org,
	kvm@vger.kernel.org, kash@tripleback.net, geoff@hostfission.com
Subject: Re: [Qemu-devel] [PATCH v14 5/6] i386: Disable TOPOEXT feature if it cannot be supported
Date: Thu, 14 Jun 2018 16:13:17 -0300	[thread overview]
Message-ID: <20180614191317.GY7451@localhost.localdomain> (raw)
In-Reply-To: <1528939107-17193-6-git-send-email-babu.moger@amd.com>

On Wed, Jun 13, 2018 at 09:18:26PM -0400, Babu Moger wrote:
> Disable the TOPOEXT feature if it cannot be supported.
> We cannot support this feature with more than 2 nr_threads
> or more than 32 cores in a socket.
> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
>  target/i386/cpu.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 2eb26da..637d8eb 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4765,7 +4765,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>      X86CPUClass *xcc = X86_CPU_GET_CLASS(dev);
>      CPUX86State *env = &cpu->env;
>      Error *local_err = NULL;
> -    static bool ht_warned;
> +    static bool ht_warned, topo_warned;
>  
>      if (xcc->host_cpuid_required && !accel_uses_host_cpuid()) {
>          char *name = x86_cpu_class_get_model_name(xcc);
> @@ -4779,6 +4779,21 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>          return;
>      }
>  
> +    /* Disable TOPOEXT if topology cannot be supported */
> +    if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
> +        if (!topology_supports_topoext(MAX_CORES_IN_NODE * MAX_NODES_PER_SOCKET,
> +                                      2)) {

I understand you stopped using cpu->nr_cores/cpu->nr_threads
because it was not filled yet.

But why exactly do you need to do this before calling
x86_cpu_expand_features()?

If you really need nr_cores and nr_threads to be available
earlier, we could simply move their initialization to
cpu_exec_initfn() instead of the solution you implemented in
patch 4/6.

> +            env->features[FEAT_8000_0001_ECX] &= !CPUID_EXT3_TOPOEXT;

!CPUID_EXT3_TOPOEXT is 0, this will clear all bits in
env->features[FEAT_8000_0001_ECX].  Did you mean
~CPUID_EXT3_TOPOEXT?


> +            if (!topo_warned) {
> +                error_report("TOPOEXT feature cannot be supported with more"
> +                             " than %d cores or more than 2 threads per socket."
> +                             " Disabling the feature.",
> +                             (MAX_CORES_IN_NODE * MAX_NODES_PER_SOCKET));
> +                topo_warned = true;

This will print a warning for "-cpu EPYC -smp 64,cores=64".
We shouldn't.

I'm starting to believe we shouldn't add TOPOEXT to EPYC unless
we're ready to make the TOPOEXT CPUID leaves work for all valid
-smp configurations.  If the feature will work only on a few
specific cases, the feature should be enabled explicitly using
"-cpu ...,+topoext".

Is it really impossible to make CPUID return reasonable topology
data for larger nr_cores and nr_threads values?  It would make
everything much simpler.

-- 
Eduardo

  reply	other threads:[~2018-06-14 19:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14  1:18 [Qemu-devel] [PATCH v14 0/6] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Babu Moger
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 1/6] i386: Set TOPOEXT unconditionally for comapatibility Babu Moger
2018-06-14  2:21   ` Eduardo Habkost
2018-06-14 13:24     ` Moger, Babu
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 2/6] i386: Enable TOPOEXT feature on AMD EPYC CPU Babu Moger
2018-06-14 18:40   ` Eduardo Habkost
2018-06-14 20:41     ` Moger, Babu
2018-06-14 23:16       ` Moger, Babu
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 3/6] i386: Disable TOPOEXT feature on pc-2.12 Babu Moger
2018-06-14 18:40   ` Eduardo Habkost
2018-06-14 20:41     ` Moger, Babu
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 4/6] cpus: Add new function topology_supports_topoext Babu Moger
2018-06-14 18:42   ` Eduardo Habkost
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 5/6] i386: Disable TOPOEXT feature if it cannot be supported Babu Moger
2018-06-14 19:13   ` Eduardo Habkost [this message]
2018-06-14 22:18     ` Moger, Babu
2018-06-14 23:09       ` Moger, Babu
2018-06-15 14:09         ` Moger, Babu
2018-06-14  1:18 ` [Qemu-devel] [PATCH v14 6/6] i386: Remove generic SMT thread check Babu Moger

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=20180614191317.GY7451@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=geoff@hostfission.com \
    --cc=kash@tripleback.net \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).