From: Babu Moger <babu.moger@amd.com> To: pbonzini@redhat.com, ehabkost@redhat.com, rth@twiddle.net Cc: imammedo@redhat.com, qemu-devel@nongnu.org, 1871842@bugs.launchpad.net Subject: [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008 Date: Fri, 17 Apr 2020 10:14:32 -0500 [thread overview] Message-ID: <20200417151432.46867.72601.stgit@localhost.localdomain> (raw) CPUID leaf CPUID_Fn80000008_ECX provides information about the number of threads supported by the processor. It was found that the field ApicIdSize(bits 15-12) was not set correctly. ApicIdSize is defined as the number of bits required to represent all the ApicId values within a package. Valid Values: Value Description 3h-0h Reserved. 4h up to 16 threads. 5h up to 32 threads. 6h up to 64 threads. 7h up to 128 threads. Fh-8h Reserved. Fix the bit appropriately. This came up during following thread. https://lore.kernel.org/qemu-devel/158643709116.17430.15995069125716778943.malonedeb@wampee.canonical.com/#t Refer the Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1 Processors. The documentation is available from the bugzilla Link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Reported-by: Philipp Eppelt <1871842@bugs.launchpad.net> Signed-off-by: Babu Moger <babu.moger@amd.com> --- target/i386/cpu.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 90ffc5f..68210f6 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -5830,11 +5830,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, *eax = cpu->phys_bits; } *ebx = env->features[FEAT_8000_0008_EBX]; - *ecx = 0; - *edx = 0; if (cs->nr_cores * cs->nr_threads > 1) { - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; + unsigned int max_apicids, bits_required; + + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; + /* Find out the number of bits to represent all the apicids */ + bits_required = 32 - clz32(max_apicids); + *ecx = bits_required << 12 | max_apicids; + } else { + *ecx = 0; } + *edx = 0; break; case 0x8000000A: if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
WARNING: multiple messages have this Message-ID (diff)
From: Babu Moger <1871842@bugs.launchpad.net> To: qemu-devel@nongnu.org Subject: [Bug 1871842] Re: AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT Date: Fri, 17 Apr 2020 15:14:32 -0000 [thread overview] Message-ID: <20200417151432.46867.72601.stgit@localhost.localdomain> (raw) Message-ID: <20200417151432.1dl2thqKtXp43qLJBaGZjOM5bFsYvoRorouJI1MrVqQ@z> (raw) In-Reply-To: 158643709116.17430.15995069125716778943.malonedeb@wampee.canonical.com CPUID leaf CPUID_Fn80000008_ECX provides information about the number of threads supported by the processor. It was found that the field ApicIdSize(bits 15-12) was not set correctly. ApicIdSize is defined as the number of bits required to represent all the ApicId values within a package. Valid Values: Value Description 3h-0h Reserved. 4h up to 16 threads. 5h up to 32 threads. 6h up to 64 threads. 7h up to 128 threads. Fh-8h Reserved. Fix the bit appropriately. This came up during following thread. https://lore.kernel.org/qemu-devel/158643709116.17430.15995069125716778943.malonedeb@wampee.canonical.com/#t Refer the Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1 Processors. The documentation is available from the bugzilla Link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Reported-by: Philipp Eppelt <1871842@bugs.launchpad.net> Signed-off-by: Babu Moger <babu.moger@amd.com> --- target/i386/cpu.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 90ffc5f..68210f6 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -5830,11 +5830,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, *eax = cpu->phys_bits; } *ebx = env->features[FEAT_8000_0008_EBX]; - *ecx = 0; - *edx = 0; if (cs->nr_cores * cs->nr_threads > 1) { - *ecx |= (cs->nr_cores * cs->nr_threads) - 1; + unsigned int max_apicids, bits_required; + + max_apicids = (cs->nr_cores * cs->nr_threads) - 1; + /* Find out the number of bits to represent all the apicids */ + bits_required = 32 - clz32(max_apicids); + *ecx = bits_required << 12 | max_apicids; + } else { + *ecx = 0; } + *edx = 0; break; case 0x8000000A: if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) { ** Bug watch added: Linux Kernel Bug Tracker #206537 https://bugzilla.kernel.org/show_bug.cgi?id=206537 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1871842 Title: AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT Status in QEMU: New Bug description: Setup: CPU: AMD EPYC-v2 or host's EPYC cpu Linux 64-bit fedora host; Kernel version 5.5.15-200.fc31 qemu version: self build git-head: f3bac27cc1e303e1860cc55b9b6889ba39dee587 config: Configured with: '../configure' '--target-list=x86_64-softmmu,mips64el-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,i386-softmmu,aarch64-softmmu,arm-softmmu' '--prefix=/opt/qemu-master' Cmdline: qemu-system-x86_64 -kernel /home/peppelt/code/l4/internal/.build-x86_64/bin/amd64_gen/bootstrap -append "" -initrd "./fiasco/.build-x86_64/fiasco , ... " -serial stdio -nographic -monitor none -nographic -monitor none -cpu EPYC-v2 -m 4G -smp 4 Issue: We are developing an microkernel operating system called L4Re. We recently got an AMD EPYC server for testing and we couldn't execute SMP tests of our system when running Linux + qemu + VM w/ L4Re. In fact, the kernel did not recognize any APs at all. On AMD CPUs the kernel checks for the number of cores reported in CPUID leaf 0x8000_0008.ECX[NC] or [ApicIdSize]. [0][1] The physical machine reports for leaf 0x8000_0008: EAX: 0x3030 EBX: 0x18cf757 ECX: 0x703f EDX: 0x1000 The lower four bits of ECX are the [NC] field and all set. When querying inside qemu with -enable-kvm -cpu host -smp 4 (basically as replacement and addition to the above cmdline) the CPUID leaf shows: EAX: 0x3024, EBX: 0x1001000, ECX: 0x0, EDX: 0x0 Note, ECX is zero. Indicating that this is no SMP capabale CPU. I'm debugging it using my local machine and the QEMU provided EPYC-v2 CPU model and it is reproducible there as well and reports: EAX: 0x3028, EBX: 0x0, ECX: 0x0, EDX: 0x0 I checked other AMD based CPU models (phenom, opteron_g3/g5) and they behave the same. [2] shows the CPUID 0x8000'0008 handling in the QEMU source. I believe that behavior here is wrong as ECX[NC] should report the number of cores per processor, as stated in the AMD manual [2] p.584. In my understanding -smp 4 should then lead to ECX[NC] = 0x3. The following table shows my findings with the -smp option: Option | Qemu guest observed ECX value -smp 4 | 0x0 -smp 4,cores=4 | 0x3 -smp 4,cores=2,thread=2 | 0x3 -smp 4,cores=4,threads=2 | QEMU boot error: topology false. Now, I'm asking myself how the terminology of the AMD manual maps to QEMU's -smp option. Obviously, nr_cores and nr_threads correspond to the cores and threads options on the cmdline and cores * threads <= 4 (in this example), but what corresponds the X in -smp X to? Querying 0x8000'0008 on the physical processor results in different reports than quering QEMU's model as does it with -enable-kvm -cpu host. Furthermore, the ACPI.MADT shows 4 local APICs to be present while the CPU leave reports a single core processor. This leads me to the conclusion that CPUID 0x8000'0008.ECX reports the wrong number. Please let me know, if you need more information from my side. [0] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/kernel_thread-ia32.cpp#L109 [1] https://github.com/kernkonzept/fiasco/blob/522ccc5f29ab120213cf02d71328e2b879cbbd19/src/kern/ia32/cpu-ia32.cpp#L1120 [2] https://github.com/qemu/qemu/blob/f2a8261110c32c4dccd84e774d8dd7a0524e00fb/target/i386/cpu.c#L5835 [3] https://www.amd.com/system/files/TechDocs/24594.pdf To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1871842/+subscriptions
next prev reply other threads:[~2020-04-17 15:15 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-09 12:58 [Bug 1871842] [NEW] AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT Philipp Eppelt 2020-04-09 14:00 ` Igor Mammedov 2020-04-09 14:00 ` Igor 2020-04-09 18:37 ` Babu Moger 2020-04-09 18:37 ` Babu Moger 2020-04-10 0:12 ` Babu Moger 2020-04-10 0:12 ` Babu Moger 2020-04-14 8:24 ` Philipp Eppelt 2020-04-14 13:27 ` Philipp Eppelt 2020-04-15 9:25 ` Igor Mammedov 2020-04-15 9:25 ` Igor [not found] ` <c01f506c-5447-d048-15b2-3f113818844f@amd.com> 2020-04-15 18:08 ` Babu Moger 2020-04-15 18:08 ` Babu Moger 2020-04-17 15:14 ` Babu Moger [this message] 2020-04-17 15:14 ` [Bug 1871842] " Babu Moger 2020-04-17 19:15 ` [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008 Eduardo Habkost 2020-04-17 19:15 ` [Bug 1871842] " Eduardo Habkost 2020-04-17 19:44 ` Babu Moger 2020-04-17 19:44 ` [Bug 1871842] " Babu Moger 2020-04-17 21:55 ` [v2 PATCH] " Babu Moger 2020-04-17 21:55 ` [Bug 1871842] " Babu Moger 2020-04-21 11:45 ` Philipp Eppelt 2020-05-21 16:04 ` Paolo Bonzini 2021-05-06 7:59 ` [Bug 1871842] Re: AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT Thomas Huth 2021-06-18 15:58 ` Thomas Huth
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=20200417151432.46867.72601.stgit@localhost.localdomain \ --to=babu.moger@amd.com \ --cc=1871842@bugs.launchpad.net \ --cc=ehabkost@redhat.com \ --cc=imammedo@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: linkBe 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).