From: Eduardo Habkost <ehabkost@redhat.com>
To: Babu Moger <babu.moger@amd.com>
Cc: pbonzini@redhat.com, imammedo@redhat.com,
1871842@bugs.launchpad.net, qemu-devel@nongnu.org,
rth@twiddle.net
Subject: Re: [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008
Date: Fri, 17 Apr 2020 15:15:13 -0400 [thread overview]
Message-ID: <20200417191513.GD4952@habkost.net> (raw)
In-Reply-To: <20200417151432.46867.72601.stgit@localhost.localdomain>
Good catch, thanks for the patch. Comments below:
On Fri, Apr 17, 2020 at 10:14:32AM -0500, Babu Moger wrote:
> 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;
I'm not sure we want a compatibility flag to keep ABI on older
machine types, here. Strictly speaking, CPUID must never change
on older machine types, but sometimes trying hard to emulate bugs
of old QEMU versions is a pointless exercise.
> + 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);
This won't work if nr_cores > 1 and nr_threads is not a power of
2, will it?
For reference, the field is documented[1] as:
"The number of bits in the initial Core::X86::Apic::ApicId[ApicId]
value that indicate thread ID within a package"
This sounds like the value already stored at
CPUX86State::pkg_offset.
> + *ecx = bits_required << 12 | max_apicids;
Bits 7:0 are documented as "The number of threads in the package
is NC+1", with no reference to APIC IDs at all.
Using ((nr_cores * nr_threads) - 1) for bits 7:0 sounds correct,
but the variable name seems misleading.
> + } else {
> + *ecx = 0;
> }
> + *edx = 0;
> break;
> case 0x8000000A:
> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
>
>
References:
[1] Processor Programming Reference (PPR) for
AMD Family 17h Model 18h, Revision B1 Processors
55570-B1 Rev 3.14 - Sep 26, 2019
https://bugzilla.kernel.org/attachment.cgi?id=287395&action=edit
--
Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: qemu-devel@nongnu.org
Subject: [Bug 1871842] Re: [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008
Date: Fri, 17 Apr 2020 19:15:13 -0000 [thread overview]
Message-ID: <20200417191513.GD4952@habkost.net> (raw)
Message-ID: <20200417191513.1nmNbPTuMYPPS5_hQdt5epD_rn66tkH28CPZLsK32rM@z> (raw)
In-Reply-To: 20200417151432.46867.72601.stgit@localhost.localdomain
Good catch, thanks for the patch. Comments below:
On Fri, Apr 17, 2020 at 10:14:32AM -0500, Babu Moger wrote:
> 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;
I'm not sure we want a compatibility flag to keep ABI on older
machine types, here. Strictly speaking, CPUID must never change
on older machine types, but sometimes trying hard to emulate bugs
of old QEMU versions is a pointless exercise.
> + 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);
This won't work if nr_cores > 1 and nr_threads is not a power of
2, will it?
For reference, the field is documented[1] as:
"The number of bits in the initial Core::X86::Apic::ApicId[ApicId]
value that indicate thread ID within a package"
This sounds like the value already stored at
CPUX86State::pkg_offset.
> + *ecx = bits_required << 12 | max_apicids;
Bits 7:0 are documented as "The number of threads in the package
is NC+1", with no reference to APIC IDs at all.
Using ((nr_cores * nr_threads) - 1) for bits 7:0 sounds correct,
but the variable name seems misleading.
> + } else {
> + *ecx = 0;
> }
> + *edx = 0;
> break;
> case 0x8000000A:
> if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
>
>
References:
[1] Processor Programming Reference (PPR) for
AMD Family 17h Model 18h, Revision B1 Processors
55570-B1 Rev 3.14 - Sep 26, 2019
https://bugzilla.kernel.org/attachment.cgi?id=287395&action=edit
--
Eduardo
--
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 parent reply other threads:[~2020-04-17 19:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Eduardo Habkost [this message]
2020-04-17 19:15 ` [Bug 1871842] Re: [PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008 Eduardo Habkost
2020-04-17 19:44 ` Babu Moger
2020-04-17 19:44 ` [Bug 1871842] " Babu Moger
-- strict thread matches above, loose matches on Subject: below --
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 21:55 ` [v2 PATCH] target/i386: Fix the CPUID leaf CPUID_Fn80000008 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=20200417191513.GD4952@habkost.net \
--to=ehabkost@redhat.com \
--cc=1871842@bugs.launchpad.net \
--cc=babu.moger@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.