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, geoff@hostfission.com,
	kash@tripleback.net, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH v11 3/5] i386: Add support for CPUID_8000_001E for AMD
Date: Mon, 4 Jun 2018 23:46:20 -0300	[thread overview]
Message-ID: <20180605024620.GI3184@localhost.localdomain> (raw)
In-Reply-To: <1527176614-26271-4-git-send-email-babu.moger@amd.com>

On Thu, May 24, 2018 at 11:43:32AM -0400, Babu Moger wrote:
> Add support for cpuid leaf CPUID_8000_001E. Build the config that closely
> match the underlying hardware. Please refer to the Processor Programming
> Reference (PPR) for AMD Family 17h Model for more details.
> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
>  target/i386/cpu.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 0d423e5..9f8bad9 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -429,6 +429,62 @@ static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, CPUState *cs,
>             (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
>  }
>  
> +/* Data structure to hold the configuration info for a given core index */
> +struct core_topology {
> +    /* core complex id of the current core index */
> +    int ccx_id;
> +    /* Adjusted core id for this core index in the topology */

What's an "adjusted core id"?

> +    int core_id;
> +    /* Node id for this core index */
> +    int node_id;
> +    /* Number of nodes in this config, 0 based */
> +    int num_nodes;

I suggest making num_nodes carry the actual number of nodes, and
using (num_nodes - 1) when building CPUID data.

> +};
> +
> +/*
> + * Build the configuration closely match the EPYC hardware. Using the EPYC
> + * hardware configuration values (MAX_CCX, MAX_CORES_IN_CCX, MAX_CORES_IN_NODE)
> + * right now. This could change in future.
> + * nr_cores : Total number of cores in the config
> + * core_id  : Core index of the current CPU
> + * topo     : Data structure to hold all the config info for this core index
> + */
> +static void build_core_topology(int nr_cores, int core_id,
> +                                struct core_topology *topo)
> +{
> +    int nodes, cores_in_ccx;
> +
> +    /* First get the number of nodes required */
> +    nodes = nodes_in_socket(nr_cores);
> +
> +    cores_in_ccx = cores_in_core_complex(nr_cores);
> +
> +    topo->node_id = core_id / (cores_in_ccx * MAX_CCX);
> +    topo->ccx_id = (core_id % (cores_in_ccx * MAX_CCX)) / cores_in_ccx;
> +    topo->core_id = core_id % cores_in_ccx;
> +    /* num_nodes is 0 based, return n - 1 */
> +    topo->num_nodes = nodes - 1;
> +}

Is this guaranteed to work with any nr_cores value, or only with
a few specific values that match real hardware?



> +
> +/* Encode cache info for CPUID[8000001E] */
> +static void encode_topo_cpuid8000001e(CPUState *cs, X86CPU *cpu,
> +                                       uint32_t *eax, uint32_t *ebx,
> +                                       uint32_t *ecx, uint32_t *edx)
> +{
> +    struct core_topology topo = {0};
> +
> +    build_core_topology(cs->nr_cores, cpu->core_id, &topo);
> +    *eax = cpu->apic_id;
> +    if (cs->nr_threads - 1) {
> +        *ebx = ((cs->nr_threads - 1) << 8) | (topo.node_id << 3) |
> +                (topo.ccx_id << 2) | topo.core_id;
> +    } else {
> +        *ebx = (topo.node_id << 4) | (topo.ccx_id << 3) | topo.core_id;
> +    }

This part confuses me a lot.  Where are those bit offsets in EBX
defined?

Is this guaranteed to work with any cs->nr_cores value?


> +    *ecx = (topo.num_nodes << 8) | (cpu->socket_id << 2) | topo.node_id;

Like on EBX, I'm confused by the bit offsets.  Where are they
defined?

Probably it's safer to not allow TOPOEXT to be enabled if the CPU
socket/core/thread topology configuration can't generate a sane
node/core-complex topology.


> +    *edx = 0;
> +}
> +
>  /*
>   * Definitions of the hardcoded cache entries we expose:
>   * These are legacy cache values. If there is a need to change any
> @@ -4122,6 +4178,11 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>              break;
>          }
>          break;
> +    case 0x8000001E:
> +        assert(cpu->core_id <= 255);
> +        encode_topo_cpuid8000001e(cs, cpu,
> +                                  eax, ebx, ecx, edx);
> +        break;
>      case 0xC0000000:
>          *eax = env->cpuid_xlevel2;
>          *ebx = 0;
> -- 
> 1.8.3.1
> 
> 

-- 
Eduardo

  reply	other threads:[~2018-06-05  2:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 15:43 [Qemu-devel] [PATCH v11 0/5] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Babu Moger
2018-05-24 15:43 ` [Qemu-devel] [PATCH v11 1/5] i386: Clean up cache CPUID code Babu Moger
2018-05-24 19:28   ` Eduardo Habkost
2018-05-24 15:43 ` [Qemu-devel] [PATCH v11 2/5] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D Babu Moger
2018-06-05  1:59   ` Eduardo Habkost
2018-06-05 15:16     ` Moger, Babu
2018-05-24 15:43 ` [Qemu-devel] [PATCH v11 3/5] i386: Add support for CPUID_8000_001E for AMD Babu Moger
2018-06-05  2:46   ` Eduardo Habkost [this message]
2018-06-05 15:49     ` Moger, Babu
2018-06-05 17:14       ` Moger, Babu
2018-05-24 15:43 ` [Qemu-devel] [PATCH v11 4/5] i386: Enable TOPOEXT feature on AMD EPYC CPU Babu Moger
2018-06-05  2:57   ` Eduardo Habkost
2018-06-05 15:54     ` Moger, Babu
2018-05-24 15:43 ` [Qemu-devel] [PATCH v11 5/5] i386: Remove generic SMT thread check Babu Moger
2018-05-24 15:51 ` [Qemu-devel] [PATCH v11 0/5] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Kash Pande
2018-05-24 15:59   ` Moger, Babu
2018-05-24 19:24   ` Eduardo Habkost

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=20180605024620.GI3184@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).