Re: [PATCH v2 2/7] qapi/qom: Define cache enumeration and properties

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Sun,  8 Sep 2024 20:59:15 +0800
Zhao Liu <zhao1.liu@intel.com> wrote:

> The x86 and ARM need to allow user to configure cache properties
> (current only topology):
>  * For x86, the default cache topology model (of max/host CPU) does not
>    always match the Host's real physical cache topology. Performance can
>    increase when the configured virtual topology is closer to the
>    physical topology than a default topology would be.
>  * For ARM, QEMU can't get the cache topology information from the CPU
>    registers, then user configuration is necessary. Additionally, the
>    cache information is also needed for MPAM emulation (for TCG) to
>    build the right PPTT.
> 
> Define smp-cache related enumeration and properties in QAPI, so that
> user could configure cache properties for SMP system through -machine in
> the subsequent patch.
> 
> Cache enumeration (CacheLevelAndType) is implemented as the combination
> of cache level (level 1/2/3) and cache type (data/instruction/unified).
> 
> Currently, separated L1 cache (L1 data cache and L1 instruction cache)
> with unified higher-level cache (e.g., unified L2 and L3 caches), is the
> most common cache architectures.
> 
> Therefore, enumerate the L1 D-cache, L1 I-cache, L2 cache and L3 cache
> with smp-cache object to add the basic cache topology support. Other
> kinds of caches (e.g., L1 unified or L2/L3 separated caches) can be
> added directly into CacheLevelAndType if necessary.
> 
> Cache properties (SmpCacheProperties) currently only contains cache
> topology information, and other cache properties can be added in it
> if necessary.
> 
> Note, define cache topology based on CPU topology level with two
> reasons:
> 
>  1. In practice, a cache will always be bound to the CPU container
>     (either private in the CPU container or shared among multiple
>     containers), and CPU container is often expressed in terms of CPU
>     topology level.
>  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 to help indicate the private

Really trivial but CPU Containers are a different ACPI concept.
For PPTT they are referred to as Processor Groups. Wonderfully they
'might match a Processor Container in the namespace' which rather implies
they might not.  In QEMU they always will because the next bit of the
spec matters. "In that case this entry will match the value of the _UID
method of the associated processor container. Where there is a match it must
be represented."

So having said all that, CPU container is probably fine as a description.

>     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.
> 
> Suggested-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Seems fine but my gut would be to combine this and next patch so we can
see how it is used (assuming no one asked for it to be separate!)

Version numbers need an update I guess.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> +##
> +# @SmpCachePropertiesWrapper:
> +#
> +# List wrapper of SmpCacheProperties.
> +#
> +# @caches: the list of SmpCacheProperties.
> +#
> +# Since 9.1

Needs updating to 9.2 I guess.

> +##
> +{ 'struct': 'SmpCachePropertiesWrapper',
> +  'data': { 'caches': ['SmpCacheProperties'] } }