The host-cache-info needs the check to ensure the valid maximum
addressable thread IDs.
We don't need to adjust the information in this one field for all cache
topology cases by default, even though Host's cache topology may not
correspond to Guest's CPU topology level.
For example, when a Geust (3 threads per core) runs on a Host with 1
threads per core, the L2 cache topo (L2 per core on Host) obtained by
Guest does not correspond to the Guest's core level. So for the case
where the topology of Guest and Host are very inconsistent, it is not
possible to do a perfect job, so we try to let the Guest have similar
cache topo info as Host, at least in the case of an even distribution
of vCPUs, which can benefit the Guest internal scheduling.
To this end, add a comment to explain why we need to care for this check
and why we don't need to adjust the topology for all cache cases.
Signed-off-by: Zhao Liu <zhao1....@intel.com>
---
target/i386/cpu.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c20ff69b7b65..71300ac6d197 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6463,7 +6463,15 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
guest_thread_ids_per_pkg =
max_thread_ids_for_cache(&topo_info,
CPU_TOPO_LEVEL_PACKAGE);
-
+ /*
+ * We handle this case because it causes sharing threads to
+ * overflow out of the package scope. In other cases, there
+ * is no need to adjust the cache topology info for the Guest,
+ * as the Host's maximum addressable thread IDs are not out of
+ * bounds in the Guest's APIC ID scope, and are always valid,
+ * even though Host's cache topology may not correspond to
+ * Guest's CPU topology level.
+ */
if (host_thread_ids_per_cache > guest_thread_ids_per_pkg) {
*eax &= ~0x3FFC000;
--
2.34.1
