On Mon, May 29, 2023 at 08:30:44PM +0800, Zhao Liu wrote: > From: Zhao Liu <zhao1....@intel.com> > > Hi list, > > This is the our v2 patch series, rebased on the master branch at the > commit ac84b57b4d74 ("Merge tag 'for-upstream' of > https://gitlab.com/bonzini/qemu into staging"). > > Comparing with v1 [1], v2 mainly reorganizes patches and does some > cleanup. > > This series add the cluster support for x86 PC machine, which allows > x86 can use smp.clusters to configure the modlue level CPU topology > of x86. > > And since the compatibility issue (see section: ## Why not share L2 > cache in cluster directly), this series also introduce a new command > to adjust the topology of the x86 L2 cache. > > Welcome your comments!
PC things: Acked-by: Michael S. Tsirkin <m...@redhat.com> > > # Backgroud > > The "clusters" parameter in "smp" is introduced by ARM [2], but x86 > hasn't supported it. > > At present, x86 defaults L2 cache is shared in one core, but this is > not enough. There're some platforms that multiple cores share the > same L2 cache, e.g., Alder Lake-P shares L2 cache for one module of > Atom cores [3], that is, every four Atom cores shares one L2 cache. > Therefore, we need the new CPU topology level (cluster/module). > > Another reason is for hybrid architecture. cluster support not only > provides another level of topology definition in x86, but would aslo > provide required code change for future our hybrid topology support. > > > # Overview > > ## Introduction of module level for x86 > > "cluster" in smp is the CPU topology level which is between "core" and > die. > > For x86, the "cluster" in smp is corresponding to the module level [4], > which is above the core level. So use the "module" other than "cluster" > in x86 code. > > And please note that x86 already has a cpu topology level also named > "cluster" [4], this level is at the upper level of the package. Here, > the cluster in x86 cpu topology is completely different from the > "clusters" as the smp parameter. After the module level is introduced, > the cluster as the smp parameter will actually refer to the module level > of x86. > > > ## Why not share L2 cache in cluster directly > > Though "clusters" was introduced to help define L2 cache topology > [2], using cluster to define x86's L2 cache topology will cause the > compatibility problem: > > Currently, x86 defaults that the L2 cache is shared in one core, which > actually implies a default setting "cores per L2 cache is 1" and > therefore implicitly defaults to having as many L2 caches as cores. > > For example (i386 PC machine): > -smp 16,sockets=2,dies=2,cores=2,threads=2,maxcpus=16 (*) > > Considering the topology of the L2 cache, this (*) implicitly means "1 > core per L2 cache" and "2 L2 caches per die". > > If we use cluster to configure L2 cache topology with the new default > setting "clusters per L2 cache is 1", the above semantics will change > to "2 cores per cluster" and "1 cluster per L2 cache", that is, "2 > cores per L2 cache". > > So the same command (*) will cause changes in the L2 cache topology, > further affecting the performance of the virtual machine. > > Therefore, x86 should only treat cluster as a cpu topology level and > avoid using it to change L2 cache by default for compatibility. > > > ## module level in CPUID > > Currently, we don't expose module level in CPUID.1FH because currently > linux (v6.2-rc6) doesn't support module level. And exposing module and > die levels at the same time in CPUID.1FH will cause linux to calculate > wrong die_id. The module level should be exposed until the real machine > has the module level in CPUID.1FH. > > We can configure CPUID.04H.02H (L2 cache topology) with module level by > a new command: > > "-cpu,x-l2-cache-topo=cluster" > > More information about this command, please see the section: "## New > property: x-l2-cache-topo". > > > ## New cache topology info in CPUCacheInfo > > Currently, by default, the cache topology is encoded as: > 1. i/d cache is shared in one core. > 2. L2 cache is shared in one core. > 3. L3 cache is shared in one die. > > This default general setting has caused a misunderstanding, that is, the > cache topology is completely equated with a specific cpu topology, such > as the connection between L2 cache and core level, and the connection > between L3 cache and die level. > > In fact, the settings of these topologies depend on the specific > platform and are not static. For example, on Alder Lake-P, every > four Atom cores share the same L2 cache [2]. > > Thus, in this patch set, we explicitly define the corresponding cache > topology for different cpu models and this has two benefits: > 1. Easy to expand to new CPU models in the future, which has different > cache topology. > 2. It can easily support custom cache topology by some command (e.g., > x-l2-cache-topo). > > > ## New property: x-l2-cache-topo > > The property l2-cache-topo will be used to change the L2 cache topology > in CPUID.04H. > > Now it allows user to set the L2 cache is shared in core level or > cluster level. > > If user passes "-cpu x-l2-cache-topo=[core|cluster]" then older L2 cache > topology will be overrided by the new topology setting. > > Since CPUID.04H is used by intel cpus, this property is available on > intel cpus as for now. > > When necessary, it can be extended to CPUID[0x8000001D] for amd cpus. > > > # Patch description > > patch 1-2 Cleanups about coding style and test name. > > patch 3-4,15 Fixes about x86 topology, intel l1 cache topology and amd > cache topology encoding. > > patch 5-6 Cleanups about topology related CPUID encoding and QEMU > topology variables. > > patch 7-12 Add the module as the new CPU topology level in x86, and it > is corresponding to the cluster level in generic code. > > patch 13,14,16 Add cache topology infomation in cache models. > > patch 17 Introduce a new command to configure L2 cache topology. > > > [1]: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg03184.html > [2]: https://patchew.org/QEMU/20211228092221.21068-1-wangyana...@huawei.com/ > [3]: > https://www.intel.com/content/www/us/en/products/platforms/details/alder-lake-p.html > [4]: SDM, vol.3, ch.9, 9.9.1 Hierarchical Mapping of Shared Resources. > > Best Regards, > Zhao > > --- > Changelog: > > Changes since v1: > * Reordered patches. (Yanan) > * Deprecated the patch to fix comment of machine_parse_smp_config(). > (Yanan) > * Rename test-x86-cpuid.c to test-x86-topo.c. (Yanan) > * Split the intel's l1 cache topology fix into a new separate patch. > (Yanan) > * Combined module_id and APIC ID for module level support into one > patch. (Yanan) > * Make cache_into_passthrough case of cpuid 0x04 leaf in > * cpu_x86_cpuid() use max_processor_ids_for_cache() and > max_core_ids_in_package() to encode CPUID[4]. (Yanan) > * Add the prefix "CPU_TOPO_LEVEL_*" for CPU topology level names. > (Yanan) > * Rename the "INVALID" level to "CPU_TOPO_LEVEL_UNKNOW". (Yanan) > > --- > Zhao Liu (10): > i386: Fix comment style in topology.h > tests: Rename test-x86-cpuid.c to test-x86-topo.c > i386/cpu: Fix i/d-cache topology to core level for Intel CPU > i386/cpu: Use APIC ID offset to encode cache topo in CPUID[4] > i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid() > i386: Add cache topology info in CPUCacheInfo > i386: Use CPUCacheInfo.share_level to encode CPUID[4] > i386: Fix NumSharingCache for CPUID[0x8000001D].EAX[bits 25:14] > i386: Use CPUCacheInfo.share_level to encode > CPUID[0x8000001D].EAX[bits 25:14] > i386: Add new property to control L2 cache topo in CPUID.04H > > Zhuocheng Ding (7): > softmmu: Fix CPUSTATE.nr_cores' calculation > i386: Introduce module-level cpu topology to CPUX86State > i386: Support modules_per_die in X86CPUTopoInfo > i386: Support module_id in X86CPUTopoIDs > i386/cpu: Introduce cluster-id to X86CPU > tests: Add test case of APIC ID for module level parsing > hw/i386/pc: Support smp.clusters for x86 PC machine > > MAINTAINERS | 2 +- > hw/i386/pc.c | 1 + > hw/i386/x86.c | 49 +++++- > include/hw/core/cpu.h | 2 +- > include/hw/i386/topology.h | 68 +++++--- > qemu-options.hx | 10 +- > softmmu/cpus.c | 2 +- > target/i386/cpu.c | 158 ++++++++++++++---- > target/i386/cpu.h | 25 +++ > tests/unit/meson.build | 4 +- > .../{test-x86-cpuid.c => test-x86-topo.c} | 58 ++++--- > 11 files changed, 280 insertions(+), 99 deletions(-) > rename tests/unit/{test-x86-cpuid.c => test-x86-topo.c} (73%) > > -- > 2.34.1