qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Babu Moger <babu.moger@amd.com>
Cc: ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
	pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [PATCH v5 14/16] hw/i386: Move arch_id decode inside x86_cpus_init
Date: Tue, 10 Mar 2020 09:35:37 +0100	[thread overview]
Message-ID: <20200310093537.192f855f@redhat.com> (raw)
In-Reply-To: <b008461c-d7c0-58f2-1c77-69a2fb5dae3e@amd.com>

On Mon, 9 Mar 2020 14:31:31 -0500
Babu Moger <babu.moger@amd.com> wrote:

> On 3/9/20 10:21 AM, Igor Mammedov wrote:
> > On Tue, 03 Mar 2020 13:58:24 -0600
> > Babu Moger <babu.moger@amd.com> wrote:
> >   
> >> Apicid calculation depends on knowing the total number of numa nodes
> >> for EPYC cpu models. Right now, we are calculating the arch_id while
> >> parsing the numa(parse_numa). At this time, it is not known how many
> >> total numa nodes are configured in the system.
> >>
> >> Move the arch_id inside x86_cpus_init. At this time smp parameter is already
> >> completed and numa node information is available.
> >>
> >> Signed-off-by: Babu Moger <babu.moger@amd.com>
> >> ---
> >>  hw/i386/x86.c |   17 +++++++++++------
> >>  1 file changed, 11 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> >> index d46dd4ad9e..66998b065c 100644
> >> --- a/hw/i386/x86.c
> >> +++ b/hw/i386/x86.c
> >> @@ -121,6 +121,9 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version)
> >>      MachineState *ms = MACHINE(x86ms);
> >>      MachineClass *mc = MACHINE_GET_CLASS(x86ms);
> >>  
> >> +    /* Initialize apicid handlers first */
> >> +    cpu_x86_init_apicid_fns(ms);
> >> +
> >>      x86_cpu_set_default_version(default_cpu_version);
> >>  
> >>      /*
> >> @@ -134,6 +137,12 @@ void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version)
> >>      x86ms->apic_id_limit = x86_cpu_apic_id_from_index(x86ms,
> >>                                                        ms->smp.max_cpus - 1) + 1;
> >>      possible_cpus = mc->possible_cpu_arch_ids(ms);
> >> +
> >> +    for (i = 0; i < ms->smp.cpus; i++) {
> >> +        ms->possible_cpus->cpus[i].arch_id =
> >> +            x86_cpu_apic_id_from_index(x86ms, i);
> >> +    }
> >> +
> >>      for (i = 0; i < ms->smp.cpus; i++) {
> >>          x86_cpu_new(x86ms, possible_cpus->cpus[i].arch_id, &error_fatal);
> >>      }
> >> @@ -158,8 +167,7 @@ int64_t x86_get_default_cpu_node_id(const MachineState *ms, int idx)
> >>     init_topo_info(&topo_info, x86ms);
> >>  
> >>     assert(idx < ms->possible_cpus->len);
> >> -   x86ms->topo_ids_from_apicid(ms->possible_cpus->cpus[idx].arch_id,
> >> -                               &topo_info, &topo_ids);
> >> +   x86_topo_ids_from_idx(&topo_info, idx, &topo_ids);  
> > not necessary if default x86ms->topo_ids_from_apicid were initialized from x86 machine class
> > 
> > I also wonder if this default contraption we have is going to work
> > in case of EPYC cpu (i.e. is would generate valid nodeids).  
> 
> From what I understand, we call this x86_get_default_cpu_node_id only when
> the user does not specify the numa binding requirements. We tried to
> generate the default node it for a given config. This works fine for EPYC
> also. I am not sure about changing this right now. what do you think?

if it work for EPYC with default x86_topo_ids_from_idx() then it's fine.

Just keep callback here, given that callback is always initialized early (class_init)
there is no point to create mix of callback/non-callback usage.
 
> > 
> > Bot instead of than trying to fix it if it's broken,
> > I'd rather deprecate and drop get_default_cpu_node_id() requiring users
> > to explicitly define CPU mapping to numa nodes.
> > That would be consistent with req for explicit RAM for numa nodes
> > (postponed till 5.1 due to libvirt not being ready),
> > i.e if one wants numa, one should explicitly provide necessary mapping
> > or machine won't start.
> > 
> >   
> >>     return topo_ids.pkg_id % ms->numa_state->num_nodes;
> >>  }
> >>  
> >> @@ -193,10 +201,7 @@ const CPUArchIdList *x86_possible_cpu_arch_ids(MachineState *ms)
> >>  
> >>          ms->possible_cpus->cpus[i].type = ms->cpu_type;
> >>          ms->possible_cpus->cpus[i].vcpus_count = 1;
> >> -        ms->possible_cpus->cpus[i].arch_id =
> >> -            x86_cpu_apic_id_from_index(x86ms, i);
> >> -        x86ms->topo_ids_from_apicid(ms->possible_cpus->cpus[i].arch_id,
> >> -                                 &topo_info, &topo_ids);
> >> +        x86_topo_ids_from_idx(&topo_info, i, &topo_ids);  
> > ditto
> >   
> >>          ms->possible_cpus->cpus[i].props.has_socket_id = true;
> >>          ms->possible_cpus->cpus[i].props.socket_id = topo_ids.pkg_id;
> >>          if (x86ms->smp_dies > 1) {
> >>  
> >   
> 



  reply	other threads:[~2020-03-10  8:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 19:56 [PATCH v5 00/16] APIC ID fixes for AMD EPYC CPU model Babu Moger
2020-03-03 19:56 ` [PATCH v5 01/16] hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs Babu Moger
2020-03-03 19:57 ` [PATCH v5 02/16] hw/i386: Introduce X86CPUTopoInfo to contain topology info Babu Moger
2020-03-09 14:10   ` Igor Mammedov
2020-03-10 23:04   ` Eduardo Habkost
2020-03-03 19:57 ` [PATCH v5 03/16] hw/i386: Consolidate topology functions Babu Moger
2020-03-03 19:57 ` [PATCH v5 04/16] machine: Add SMP Sockets in CpuTopology Babu Moger
2020-03-09 14:17   ` Igor Mammedov
2020-03-09 18:01     ` Babu Moger
2020-03-03 19:57 ` [PATCH v5 05/16] hw/i386: Remove unnecessary initialization in x86_cpu_new Babu Moger
2020-03-09 14:18   ` Igor Mammedov
2020-03-03 19:57 ` [PATCH v5 06/16] hw/i386: Update structures to save the number of nodes per package Babu Moger
2020-03-09 14:26   ` Igor Mammedov
2020-03-03 19:57 ` [PATCH v5 07/16] hw/i386: Rename apicid_from_topo_ids to x86_apicid_from_topo_ids Babu Moger
2020-03-03 19:57 ` [PATCH v5 08/16] hw/386: Add EPYC mode topology decoding functions Babu Moger
2020-03-03 19:57 ` [PATCH v5 09/16] target/i386: Cleanup and use the EPYC mode topology functions Babu Moger
2020-03-03 19:57 ` [PATCH v5 10/16] hw/i386: Introduce apicid functions inside X86MachineState Babu Moger
2020-03-09 14:34   ` Igor Mammedov
2020-03-03 19:58 ` [PATCH v5 11/16] target/i386: Load apicid model specific handlers from X86CPUDefinition Babu Moger
2020-03-09 14:49   ` Igor Mammedov
2020-03-09 14:55     ` Igor Mammedov
2020-03-09 19:04     ` Babu Moger
2020-03-10  8:27       ` Igor Mammedov
2020-03-03 19:58 ` [PATCH v5 12/16] hw/i386: Use the apicid handlers from X86MachineState Babu Moger
2020-03-09 15:01   ` Igor Mammedov
2020-03-09 19:08     ` Babu Moger
2020-03-10  8:31       ` Igor Mammedov
2020-03-03 19:58 ` [PATCH v5 13/16] target/i386: Add EPYC model specific handlers Babu Moger
2020-03-09 15:03   ` Igor Mammedov
2020-03-09 19:12     ` Babu Moger
2020-03-10  8:25       ` Igor Mammedov
2020-03-03 19:58 ` [PATCH v5 14/16] hw/i386: Move arch_id decode inside x86_cpus_init Babu Moger
2020-03-09 15:21   ` Igor Mammedov
2020-03-09 19:31     ` Babu Moger
2020-03-10  8:35       ` Igor Mammedov [this message]
2020-03-10 20:05         ` Babu Moger
2020-03-03 19:58 ` [PATCH v5 15/16] i386: Fix pkg_id offset for EPYC cpu models Babu Moger
2020-03-09 15:22   ` Igor Mammedov
2020-03-03 19:58 ` [PATCH v5 16/16] tests: Update the Unit tests Babu Moger
2020-03-10 23:06   ` Eduardo Habkost
2020-03-10 23:09     ` Moger, Babu
2020-03-08 13:25 ` [PATCH v5 00/16] APIC ID fixes for AMD EPYC CPU model Michael S. Tsirkin
2020-03-09 17:50   ` Babu Moger
2020-03-10  8:40 ` Igor Mammedov
2020-03-10 20:07   ` 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=20200310093537.192f855f@redhat.com \
    --to=imammedo@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=ehabkost@redhat.com \
    --cc=mst@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).