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: [v2 PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008
Date: Fri, 17 Apr 2020 16:55:13 -0500 [thread overview]
Message-ID: <20200417215345.64800.73351.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>
---
v2:
Used env->pkg_offset for bits 15:12 which is already available.
target/i386/cpu.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 90ffc5f..5e5a605 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5830,11 +5830,20 @@ 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;
+ /*
+ * Bits 15:12 is "The number of bits in the initial
+ * Core::X86::Apic::ApicId[ApicId] value that indicate
+ * thread ID within a package". This is already stored at
+ * CPUX86State::pkg_offset.
+ * Bits 7:0 is "The number of threads in the package is NC+1"
+ */
+ *ecx = (env->pkg_offset << 12) |
+ ((cs->nr_cores * cs->nr_threads) - 1);
+ } 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] [v2 PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008
Date: Fri, 17 Apr 2020 21:55:13 -0000 [thread overview]
Message-ID: <20200417215345.64800.73351.stgit@localhost.localdomain> (raw)
Message-ID: <20200417215513.l3CGlfkHza0ej3r24DZVZ-cyHoAWeVzaoiMWh2tXUdw@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>
---
v2:
Used env->pkg_offset for bits 15:12 which is already available.
target/i386/cpu.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 90ffc5f..5e5a605 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5830,11 +5830,20 @@ 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;
+ /*
+ * Bits 15:12 is "The number of bits in the initial
+ * Core::X86::Apic::ApicId[ApicId] value that indicate
+ * thread ID within a package". This is already stored at
+ * CPUX86State::pkg_offset.
+ * Bits 7:0 is "The number of threads in the package is NC+1"
+ */
+ *ecx = (env->pkg_offset << 12) |
+ ((cs->nr_cores * cs->nr_threads) - 1);
+ } else {
+ *ecx = 0;
}
+ *edx = 0;
break;
case 0x8000000A:
if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
--
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 21:57 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 ` [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008 Babu Moger
2020-04-17 15:14 ` [Bug 1871842] Re: AMD CPUID leaf 0x8000'0008 reported number of cores inconsistent with ACPI.MADT 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 ` Babu Moger [this message]
2020-04-17 21:55 ` [Bug 1871842] [v2 PATCH] " 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=20200417215345.64800.73351.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: 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).