@@ -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;
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.liu@intel.com> --- target/i386/cpu.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)