From: Zhao Liu <zhao1.liu@intel.com>

Hi all,

To make review easier, I've merged my previous single SMP patch [1] and
SMP test series [2] into this series as well.

So this series includes:
 * [Patch 1] Remove deprecated "parameter=0" SMP configurations, which
   is marked as deprecated in v6.2.
 * [Patch 2] Deprecate unsupported "parameter=1" SMP configurations.
 * [Patch 3 & 4] Minor code cleanup for machine_parse_smp_config().
 * [Patch 5 ~ 14] Test case enhancements to cover more SMP API changes.

[1]: https://lore.kernel.org/qemu-devel/20240304044510.2305849-1-zhao1.liu@linux.intel.com/
[2]: https://lore.kernel.org/qemu-devel/20240118144857.2124034-1-zhao1.liu@linux.intel.com/

Thanks and Best Regards,
Zhao

---
Zhao Liu (14):
  hw/core/machine-smp: Remove deprecated "parameter=0" SMP
    configurations
  hw/core/machine-smp: Deprecate unsupported "parameter=1" SMP
    configurations
  hw/core/machine-smp: Simplify variables' initialization in
    machine_parse_smp_config()
  hw/core/machine-smp: Calculate total CPUs once in
    machine_parse_smp_config()
  tests/unit/test-smp-parse: Drop the unsupported "dies=1" case
  tests/unit/test-smp-parse: Use CPU number macros in invalid topology
    case
  tests/unit/test-smp-parse: Bump max_cpus to 4096
  tests/unit/test-smp-parse: Make test cases aware of the book/drawer
  tests/unit/test-smp-parse: Test "books" parameter in -smp
  tests/unit/test-smp-parse: Test "drawers" parameter in -smp
  tests/unit/test-smp-parse: Test "drawers" and "books" combination case
  tests/unit/test-smp-parse: Test the full 7-levels topology hierarchy
  tests/unit/test-smp-parse: Test smp_props.has_clusters
  tests/unit/test-smp-parse: Test "parameter=0" SMP configurations

 docs/about/deprecated.rst       |  30 +-
 docs/about/removed-features.rst |  15 +
 hw/core/machine-smp.c           |  94 +++--
 tests/unit/test-smp-parse.c     | 612 ++++++++++++++++++++++++++++++--
 4 files changed, 678 insertions(+), 73 deletions(-)

-- 
2.34.1

Hi,

On 6/3/24 10:53, Zhao Liu wrote:
> From: Zhao Liu <zhao1.liu@intel.com>
> 
> Hi all,
> 
> To make review easier, I've merged my previous single SMP patch [1] and
> SMP test series [2] into this series as well.
> 
> So this series includes:
>   * [Patch 1] Remove deprecated "parameter=0" SMP configurations, which
>     is marked as deprecated in v6.2.
>   * [Patch 2] Deprecate unsupported "parameter=1" SMP configurations.
>   * [Patch 3 & 4] Minor code cleanup for machine_parse_smp_config().
>   * [Patch 5 ~ 14] Test case enhancements to cover more SMP API changes.
> 
> [1]: https://lore.kernel.org/qemu-devel/20240304044510.2305849-1-zhao1.liu@linux.intel.com/
> [2]: https://lore.kernel.org/qemu-devel/20240118144857.2124034-1-zhao1.liu@linux.intel.com/
> 
> Thanks and Best Regards,
> Zhao

In a previous community call, Zhao asked us how his work will scale
in the heterogeneous context.

My first idea is CPUs must belong to a cluster. For machines without
explicit cluster, we could always create the first one. Then -smp
would become a sugar property of the first cluster. Next -smp could
also be sugar property of the next cluster.

Regards,

Phil.

Hi Philippe,

> In a previous community call, Zhao asked us how his work will scale
> in the heterogeneous context.
> 
> My first idea is CPUs must belong to a cluster.

Thank you for considering this!

At present, cluster is a arch-specific topology level used by ARM.
So maybe we need call this abstraction as another name not "cluster"?

I guess the cluster you mentioned is the cluster device used in TCG,
right? I also tried to eliminate differences between cluster devices
and the cluster level in CPU topology [1].

My previous proposal introduced a abstract topology device [2]. And all
topology specific levels are derived from the underlying topology
device, including CPU.

I feel like this topology device abstraction seems close to your idea,
am I understanding it correctly? ;-)

> For machines without
> explicit cluster, we could always create the first one. Then -smp
> would become a sugar property of the first cluster. Next -smp could
> also be sugar property of the next cluster.

Could you please explain the above ideas more?

It feels we need to split -smp for each cluster. But I'm not sure if
sugar property means defining smp-like properties for each cluster.

Or is there a command line example? ;-)

[1]: https://lore.kernel.org/qemu-devel/20231130144203.2307629-23-zhao1.liu@linux.intel.com/
[2]: https://lore.kernel.org/qemu-devel/20231130144203.2307629-9-zhao1.liu@linux.intel.com/

Thanks,
Zhao