+Igor
On 20/2/24 10:24, Zhao Liu wrote:
From: Zhao Liu <zhao1.liu@xxxxxxxxx>
Hi list,
This's our proposal for supporting (SMP) cache topology in -smp as
the following example:
-smp 32,sockets=2,dies=2,modules=2,cores=2,threads=2,maxcpus=32,\
l1d-cache=core,l1i-cache=core,l2-cache=core,l3-cache=die
With the new cache topology options ("l1d-cache", "l1i-cache",
"l2-cache" and "l3-cache"), we could adjust the cache topology via -smp.
This patch set is rebased on our i386 module series:
https://lore.kernel.org/qemu-devel/20240131101350.109512-1-zhao1.liu@xxxxxxxxxxxxxxx/
Since the ARM [1] and RISC-V [2] folks have similar needs for the cache
topology, I also cc'd the ARM and RISC-V folks and lists.
Welcome your feedback!
Introduction
============
Background
----------
Intel client platforms (ADL/RPL/MTL) and E core server platforms (SRF)
share the L2 cache domain among multiple E cores (in the same module).
Thus we need a way to adjust the cache topology so that users could
create the cache topology for Guest that is nearly identical to Host.
This is necessary in cases where there are bound vCPUs, especially
considering that Guest scheduling often takes into account the cache
topology as well (e.g. Linux cluster aware scheduling, i.e. L2 cache
scheduling).
Previously, we introduced a x86 specific option to adjust the cache
topology:
-cpu x-l2-cache-topo=[core|module] [3]
However, considering the needs of other arches, we re-implemented the
generic cache topology (aslo in response to Michael's [4] and Daniel's
comment [5]) in this series.
Cache Topology Representation
-----------------------------
We consider to define the cache topology based on CPU topology level for
two reasons:
1. In practice, a cache will always be bound to the CPU container -
"CPU container" indicates to a set of CPUs that refer to a certain
level of CPU topology - where the cache is either private in that
CPU container or shared among multiple containers.
2. The x86's cache-related CPUIDs encode cache topology based on APIC
ID's CPU topology layout. And the ACPI PPTT table that ARM/RISCV
relies on also requires CPU containers (CPU topology) to help
indicate the private shared hierarchy of the cache.
Therefore, for SMP systems, it is natural to use the CPU topology
hierarchy directly in QEMU to define the cache topology.
And currently, separated L1 cache (L1 data cache and L1 instruction
cache) with unified higher-level caches (e.g., unified L2 and L3
caches), is the most common cache architectures.
Thus, we define the topology for L1 D-cache, L1 I-cache, L2 cache and L3
cache in MachineState as the basic cache topology support:
typedef struct CacheTopology {
CPUTopoLevel l1d;
CPUTopoLevel l1i;
CPUTopoLevel l2;
CPUTopoLevel l3;
} CacheTopology;
Machines may also only support a subset of the cache topology
to be configured in -smp by setting the SMP property of MachineClass:
typedef struct {
...
bool l1_separated_cache_supported;
bool l2_unified_cache_supported;
bool l3_unified_cache_supported;
} SMPCompatProps;
Cache Topology Configuration in -smp
------------------------------------
Further, we add new parameters to -smp:
* l1d-cache=level
* l1i-cache=level
* l2-cache=level
* l3-cache=level
These cache topology parameters accept the strings of CPU topology
levels (such as "drawer", "book", "socket", "die", "cluster", "module",
"core" or "thread"). Exactly which topology level strings could be
accepted as the parameter depends on the machine's support for the
corresponding CPU topology level.
Unsupported cache topology parameters will be omitted, and
correspondingly, the target CPU's cache topology will use the its
default cache topology setting.
In this series, we add the cache topology support in -smp for x86 PC
machine.
The following example defines a 3-level cache topology hierarchy (L1
D-cache per core, L1 I-cache per core, L2 cache per core and L3 cache per
die) for PC machine.
-smp 32,sockets=2,dies=2,modules=2,cores=2,threads=2,maxcpus=32,\
l1d-cache=core,l1i-cache=core,l2-cache=core,l3-cache=die
Reference
---------
[1]: [ARM] Jonathan's proposal to adjust cache topology:
https://lore.kernel.org/qemu-devel/20230808115713.2613-2-Jonathan.Cameron@xxxxxxxxxx/
[2]: [RISC-V] Discussion between JeeHeng and Jonathan about cache
topology:
https://lore.kernel.org/qemu-devel/20240131155336.000068d1@xxxxxxxxxx/
[3]: Previous x86 specific cache topology option:
https://lore.kernel.org/qemu-devel/20230914072159.1177582-22-zhao1.liu@xxxxxxxxxxxxxxx/
[4]: Michael's comment about generic cache topology support:
https://lore.kernel.org/qemu-devel/20231003085516-mutt-send-email-mst@xxxxxxxxxx/
[5]: Daniel's question about how x86 support L2 cache domain (cluster)
configuration:
https://lore.kernel.org/qemu-devel/ZcUG0Uc8KylEQhUW@xxxxxxxxxx/
Thanks and Best Regards,
Zhao
---
Zhao Liu (8):
hw/core: Rename CpuTopology to CPUTopology
hw/core: Move CPU topology enumeration into arch-agnostic file
hw/core: Define cache topology for machine
hw/core: Add cache topology options in -smp
i386/cpu: Support thread and module level cache topology
i386/cpu: Update cache topology with machine's configuration
i386/pc: Support cache topology in -smp for PC machine
qemu-options: Add the cache topology description of -smp
MAINTAINERS | 2 +
hw/core/cpu-topology.c | 56 ++++++++++++++
hw/core/machine-smp.c | 128 ++++++++++++++++++++++++++++++++
hw/core/machine.c | 9 +++
hw/core/meson.build | 1 +
hw/i386/pc.c | 3 +
hw/s390x/cpu-topology.c | 6 +-
include/hw/boards.h | 33 +++++++-
include/hw/core/cpu-topology.h | 40 ++++++++++
include/hw/i386/topology.h | 18 +----
include/hw/s390x/cpu-topology.h | 6 +-
qapi/machine.json | 14 +++-
qemu-options.hx | 54 ++++++++++++--
system/vl.c | 15 ++++
target/i386/cpu.c | 55 ++++++++++----
target/i386/cpu.h | 2 +-
tests/unit/meson.build | 3 +-
tests/unit/test-smp-parse.c | 14 ++--
18 files changed, 399 insertions(+), 60 deletions(-)
create mode 100644 hw/core/cpu-topology.c
create mode 100644 include/hw/core/cpu-topology.h
