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 13/16] target/i386: Add EPYC model specific handlers
Date: Tue, 10 Mar 2020 09:25:03 +0100	[thread overview]
Message-ID: <20200310092503.10e7dac2@redhat.com> (raw)
In-Reply-To: <df9e6525-f9a7-2f98-d5b4-985efc634335@amd.com>

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

> On 3/9/20 10:03 AM, Igor Mammedov wrote:
> > On Tue, 03 Mar 2020 13:58:16 -0600
> > Babu Moger <babu.moger@amd.com> wrote:
> >   
> >> Add the new EPYC model specific handlers to fix the apicid decoding.
> >>
> >> The APIC ID is decoded based on the sequence sockets->dies->cores->threads.
> >> This works fine for most standard AMD and other vendors' configurations,
> >> but this decoding sequence does not follow that of AMD's APIC ID enumeration
> >> strictly. In some cases this can cause CPU topology inconsistency.
> >>
> >> When booting a guest VM, the kernel tries to validate the topology, and finds
> >> it inconsistent with the enumeration of EPYC cpu models. The more details are
> >> in the bug https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1728166&amp;data=02%7C01%7Cbabu.moger%40amd.com%7C3ddda6803d584aac171b08d7c43b0530%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637193630113242242&amp;sdata=3TkNY2O8HWBqaOrmO8QQoxlzvIv2oEdTO1P9k6VglmU%3D&amp;reserved=0.
> >>
> >> To fix the problem we need to build the topology as per the Processor
> >> Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1
> >> Processors.
> >> It is available at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F55570-B1_PUB.zip&amp;data=02%7C01%7Cbabu.moger%40amd.com%7C3ddda6803d584aac171b08d7c43b0530%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637193630113242242&amp;sdata=cPYmcthdgilh9lOiGDrwKwOt7cn%2BvBcT%2F8PhRs92x8I%3D&amp;reserved=0
> >>
> >> Here is the text from the PPR.
> >> Operating systems are expected to use Core::X86::Cpuid::SizeId[ApicIdSize], the
> >> number of least significant bits in the Initial APIC ID that indicate core ID
> >> within a processor, in constructing per-core CPUID masks.
> >> Core::X86::Cpuid::SizeId[ApicIdSize] determines the maximum number of cores
> >> (MNC) that the processor could theoretically support, not the actual number of
> >> cores that are actually implemented or enabled on the processor, as indicated
> >> by Core::X86::Cpuid::SizeId[NC].
> >> Each Core::X86::Apic::ApicId[ApicId] register is preset as follows:
> >> • ApicId[6] = Socket ID.
> >> • ApicId[5:4] = Node ID.
> >> • ApicId[3] = Logical CCX L3 complex ID
> >> • ApicId[2:0]= (SMT) ? {LogicalCoreID[1:0],ThreadId} : {1'b0,LogicalCoreID[1:0]}
> >>
> >> Signed-off-by: Babu Moger <babu.moger@amd.com>  
> > 
> > Acked-by: Igor Mammedov <imammedo@redhat.com>  
> 
> If use a boolean variable, then I dont need all these handlers in
> X86CPUDefinition. I just need to set a boolean variable here.

agreed, that would be better

> >   
> >> ---
> >>  target/i386/cpu.c |    4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >> index f33d8b77f5..f870f7c55b 100644
> >> --- a/target/i386/cpu.c
> >> +++ b/target/i386/cpu.c
> >> @@ -3884,6 +3884,10 @@ static X86CPUDefinition builtin_x86_defs[] = {
> >>          .xlevel = 0x8000001E,
> >>          .model_id = "AMD EPYC Processor",
> >>          .cache_info = &epyc_cache_info,
> >> +        .apicid_from_cpu_idx = x86_apicid_from_cpu_idx_epyc,
> >> +        .topo_ids_from_apicid = x86_topo_ids_from_apicid_epyc,
> >> +        .apicid_from_topo_ids = x86_apicid_from_topo_ids_epyc,
> >> +        .apicid_pkg_offset = apicid_pkg_offset_epyc,
> >>          .versions = (X86CPUVersionDefinition[]) {
> >>              { .version = 1 },
> >>              {
> >>
> >>  
> >   
> 



  reply	other threads:[~2020-03-10  8:26 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 [this message]
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
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=20200310092503.10e7dac2@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).