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 v12 3/4] i386: Enable TOPOEXT feature on AMD EPYC CPU
Date: Wed, 6 Jun 2018 19:39:56 -0300	[thread overview]
Message-ID: <20180606223956.GD7451@localhost.localdomain> (raw)
In-Reply-To: <1528295806-90593-4-git-send-email-babu.moger@amd.com>

On Wed, Jun 06, 2018 at 10:36:45AM -0400, Babu Moger wrote:
> Enable TOPOEXT feature on EPYC CPU. This is required to support
> hyperthreading on VM guests. Also extend xlevel to 0x8000001E.
> 
> Disable TOPOEXT feature for legacy machines.
> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>

Now, I just noticed we have a problem here:

"-machine pc -cpu EPYC -smp 64" works today

This patch makes it stop working, but it shouldn't.

On the other hand, I believe you expect:
* "-machine pc -cpu EPYC -smp 8" to automatically enable topoext.
* "-machine pc -cpu Opteron_G1 -smp 8" to not enable topoext.
* What about "-machine -cpu Opteron_G1 -smp 8,threads=2"?


We also have other requirements, I will try to enumerate all of
them below:

0) "-topoext" explicitly configured (any machine-type):
* Must never enable topoext.

1) "+topoext" explicitly configured (any machine-type):
* Must validate topology and refuse to start if unsupported.

2) Older machine-types:
* Must never enable topoext automatically, even if using "EPYC"
  or "threads=2"

3) "EPYC" CPU model (on new machine-types):
* Should enable topoext automatically, but only if topology is
  supported.
* Must not error out if topology is not supported.
* Should this enable topoext automatically even if threads=1?

4) Other AMD CPU models with "threads=2" (on new machine-types):
* We might want to make this enable topoext automatically, too.
  What do you think?

Is the above description accurate?  Do you agree with these
requirements?

We're trying to use the "topoext" property to cover all cases
above, but it looks like we need at least 2 bits to represent all
possible cases.


Maybe we can represent the cases above with two properties:
"topoext" and "auto-topoext".  Then each case would be
represented by:

0) "-topoext" explicitly configured (any machine-type):
* Will clear TOPOEXT on env->features and set TOPOEXT on
  env->user_features
  (already done today)

1) "+topoext" explicitly configured (any machine-type):
* Will set TOPOEXT on both env->user_features and env->features
  (already done today)

2) Older machine-types:
* Will set auto-topoext=off (can be done on compat_props)
* Will set topoext=off on EPYC CPU model (so TOPOEXT won't be set
  by default on env->features) (can be done on compat_props)

3) "EPYC" CPU model (on new machine-types):
* Will set auto-topoext=on (can be the default for all CPU
  models)
* Will set TOPOEXT on env->features) (can be done on CPU model table)

4) Other AMD CPU models with "threads=2" (on new machine-types):
* Will set auto-topoext=on (can be the default on all CPU models)
* Will keep TOPOEXT disabled on env->features (done on the CPU
  model table)


Then the rules would be:

  if {auto_topoext && TOPOEXT not in env->user_features) {
      if (supported_topology) {
          if (threads > 1)
              set TOPOEXT in env->features
      } else
          unset TOPOEXT in env->features
  }

  if (TOPOEXT in env->features && !supported_topology)
      error;
  }

I think this would fulfill all the requirements above.  Please
help me confirm that.

-- 
Eduardo

  reply	other threads:[~2018-06-06 22:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 14:36 [Qemu-devel] [PATCH v12 0/4] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Babu Moger
2018-06-06 14:36 ` [Qemu-devel] [PATCH v12 1/4] i386: Add support for CPUID_8000_001E for AMD Babu Moger
2018-06-06 21:26   ` Eduardo Habkost
2018-06-08 18:15     ` Moger, Babu
2018-06-06 14:36 ` [Qemu-devel] [PATCH v12 2/4] i386: Verify if topoext feature can be supported Babu Moger
2018-06-06 22:05   ` Eduardo Habkost
2018-06-07 14:24     ` Moger, Babu
2018-06-07 14:38       ` Eduardo Habkost
2018-06-06 14:36 ` [Qemu-devel] [PATCH v12 3/4] i386: Enable TOPOEXT feature on AMD EPYC CPU Babu Moger
2018-06-06 22:39   ` Eduardo Habkost [this message]
2018-06-08 18:40     ` Moger, Babu
2018-06-08 19:23       ` Eduardo Habkost
2018-06-08 19:36         ` Moger, Babu
2018-06-08 19:50           ` Eduardo Habkost
2018-06-08 20:00             ` Moger, Babu
2018-06-08 22:59             ` Moger, Babu
2018-06-06 14:36 ` [Qemu-devel] [PATCH v12 4/4] 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=20180606223956.GD7451@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).