From: Igor Mammedov <imammedo@redhat.com>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, richard.henderson@linaro.org,
f4bug@amsat.org, yang.zhong@intel.com
Subject: [PATCH 2/2] x86: cpu: fixup number of addressable IDs for logical processors sharing cache
Date: Tue, 24 May 2022 11:10:20 -0400 [thread overview]
Message-ID: <20220524151020.2541698-3-imammedo@redhat.com> (raw)
In-Reply-To: <20220524151020.2541698-1-imammedo@redhat.com>
When QEMU is started with '-cpu host,host-cache-info=on', it will
passthrough host's number of logical processors sharing cache and
number of processor cores in the physical package. QEMU already
fixes up the later to correctly reflect number of configured cores
for VM, however number of logical processors sharing cache is still
comes from host CPU, which confuses guest started with:
-machine q35,accel=kvm \
-cpu host,host-cache-info=on,l3-cache=off \
-smp 20,sockets=2,dies=1,cores=10,threads=1 \
-numa node,nodeid=0,memdev=ram-node0 \
-numa node,nodeid=1,memdev=ram-node1 \
-numa cpu,socket-id=0,node-id=0 \
-numa cpu,socket-id=1,node-id=1
on 2 socket Xeon 4210R host with 10 cores per socket
with CPUID[04H]:
...
--- cache 3 ---
cache type = unified cache (3)
cache level = 0x3 (3)
self-initializing cache level = true
fully associative cache = false
maximum IDs for CPUs sharing cache = 0x1f (31)
maximum IDs for cores in pkg = 0xf (15)
...
that doesn't match number of logical processors VM was
configured with and as result RHEL 9.0 guest complains:
sched: CPU #10's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
WARNING: CPU: 10 PID: 0 at arch/x86/kernel/smpboot.c:421 topology_sane.isra.0+0x67/0x80
...
Call Trace:
set_cpu_sibling_map+0x176/0x590
start_secondary+0x5b/0x150
secondary_startup_64_no_verify+0xc2/0xcb
Fix it by capping max number of logical processors to vcpus/socket
as it was configured, which fixes the issue.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2088311
---
PS:
capping to logical cpus/socket was arbitrarily chosen (maybe
it should be per die or something else but don't see that in spec)
---
target/i386/cpu.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index bbe37dce2e..ffb274dcf6 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5276,10 +5276,22 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
/* cache info: needed for Core compatibility */
if (cpu->cache_info_passthrough) {
x86_cpu_get_cache_cpuid(index, count, eax, ebx, ecx, edx);
- /* QEMU gives out its own APIC IDs, never pass down bits 31..26. */
- *eax &= ~0xFC000000;
- if ((*eax & 31) && cs->nr_cores > 1) {
- *eax |= (pow2ceil(cs->nr_cores) - 1) << 26;
+ /*
+ * QEMU has its own number of cores/logical cpus,
+ * set 24..14, 31..26 bit to configured values
+ */
+ if (*eax & 31) {
+ int host_vcpus_per_cache = 1 + ((*eax & 0x3FFC000) >> 14);
+ int vcpus_per_socket = env->nr_dies * cs->nr_cores *
+ cs->nr_threads;
+ if (cs->nr_cores > 1) {
+ *eax &= ~0xFC000000;
+ *eax |= (pow2ceil(cs->nr_cores) - 1) << 26;
+ }
+ if (host_vcpus_per_cache > vcpus_per_socket) {
+ *eax &= ~0x3FFC000;
+ *eax |= (pow2ceil(vcpus_per_socket) - 1) << 14;
+ }
}
} else if (cpu->vendor_cpuid_only && IS_AMD_CPU(env)) {
*eax = *ebx = *ecx = *edx = 0;
--
2.31.1
next prev parent reply other threads:[~2022-05-24 15:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 15:10 [PATCH 0/2] i386: fixup number of logical CPUs when host-cache-info=on Igor Mammedov
2022-05-24 15:10 ` [PATCH 1/2] x86: cpu: make sure number of addressable IDs for processor cores meets the spec Igor Mammedov
2022-05-24 15:10 ` Igor Mammedov [this message]
2022-05-24 15:19 ` [PATCH 0/2] i386: fixup number of logical CPUs when host-cache-info=on Igor Mammedov
2022-05-24 19:48 ` Moger, Babu
2022-05-24 23:23 ` Alejandro Jimenez
2022-05-25 19:56 ` Moger, Babu
2022-05-25 21:20 ` Alejandro Jimenez
2022-05-25 7:05 ` Igor Mammedov
2022-05-25 20:04 ` Moger, Babu
2022-05-31 12:44 ` Igor Mammedov
2022-06-01 10:02 ` Paolo Bonzini
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=20220524151020.2541698-3-imammedo@redhat.com \
--to=imammedo@redhat.com \
--cc=f4bug@amsat.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=yang.zhong@intel.com \
/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.