[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics |
Date: |
Tue, 19 Sep 2023 14:47:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Nina Schoetterl-Glausch <nsg@linux.ibm.com> writes:
> From: Pierre Morel <pmorel@linux.ibm.com>
>
> S390 adds two new SMP levels, drawers and books to the CPU
> topology.
> S390 CPUs have specific topology features like dedication and
> entitlement. These indicate to the guest information on host
> vCPU scheduling and help the guest make better scheduling decisions.
>
> Let us provide the SMP properties with books and drawers levels
> and S390 CPU with dedication and entitlement,
>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> ---
> qapi/machine-common.json | 21 +++++++++++++
> qapi/machine.json | 19 ++++++++++--
> include/hw/boards.h | 10 +++++-
> include/hw/qdev-properties-system.h | 4 +++
> target/s390x/cpu.h | 6 ++++
> hw/core/machine-smp.c | 48 ++++++++++++++++++++++++-----
> hw/core/machine.c | 4 +++
> hw/core/qdev-properties-system.c | 13 ++++++++
> hw/s390x/s390-virtio-ccw.c | 4 +++
> softmmu/vl.c | 6 ++++
> target/s390x/cpu.c | 7 +++++
> qapi/meson.build | 1 +
> qemu-options.hx | 7 +++--
> 13 files changed, 137 insertions(+), 13 deletions(-)
> create mode 100644 qapi/machine-common.json
>
> diff --git a/qapi/machine-common.json b/qapi/machine-common.json
> new file mode 100644
> index 0000000000..e40421bb37
> --- /dev/null
> +++ b/qapi/machine-common.json
Why do you need a separate QAPI sub-module?
> @@ -0,0 +1,21 @@
> +# -*- Mode: Python -*-
> +# vim: filetype=python
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
> +# See the COPYING file in the top-level directory.
> +
> +##
> +# = Machines S390 data types
> +##
> +
> +##
> +# @CpuS390Entitlement:
> +#
> +# An enumeration of cpu entitlements that can be assumed by a virtual
> +# S390 CPU
> +#
> +# Since: 8.2
> +##
> +{ 'enum': 'CpuS390Entitlement',
> + 'prefix': 'S390_CPU_ENTITLEMENT',
> + 'data': [ 'auto', 'low', 'medium', 'high' ] }
> diff --git a/qapi/machine.json b/qapi/machine.json
> index a08b6576ca..a63cb951d2 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -9,6 +9,7 @@
##
# = Machines
> ##
>
> { 'include': 'common.json' }
> +{ 'include': 'machine-common.json' }
Section structure is borked :)
Existing section "Machine" now ends at the new "Machines S390 data
types" you pull in here. The contents of below moves from "Machines" to
"Machines S390 data types".
Before I explain how to avoid this, I'd like to understand why we need a
new sub-module.
>
> ##
> # @SysEmuTarget:
> @@ -71,7 +72,7 @@
##
# @CpuInfoFast:
#
# Information about a virtual CPU
#
# @cpu-index: index of the virtual CPU
#
# @qom-path: path to the CPU object in the QOM tree
> #
> # @thread-id: ID of the underlying host thread
> #
> -# @props: properties describing to which node/socket/core/thread
> +# @props: properties describing to which node/drawer/book/socket/core/thread
> # virtual CPU belongs to, provided if supported by board
Is this description accurate?
@props is of type CpuInstanceProperties, shown below. Its documentation
describes it as "properties to be used for hotplugging a CPU instance,
it should be passed by management with device_add command when a CPU is
being hotplugged." Hmm.
I figure details ("node/drawer/book/socket/core/thread") are better left
to CpuInstanceProperties.
The "provided if supported by board" part makes no sense to me. If
@props is there, it lists the properties we need to provide with
device_add. What if it's not there? Same as empty list, i.e. we don't
need to provide properties with device_add?
Not your patch's fault, but let's get this in shape if we can.
> #
> # @target: the QEMU system emulation target, which determines which
> @@ -901,7 +902,11 @@
> #
> # @node-id: NUMA node ID the CPU belongs to
> #
> -# @socket-id: socket number within node/board the CPU belongs to
> +# @drawer-id: drawer number within node/board the CPU belongs to (since 8.2)
> +#
> +# @book-id: book number within drawer/node/board the CPU belongs to (since
> 8.2)
Long lines, please wrap:
# @drawer-id: drawer number within node/board the CPU belongs to
# (since 8.2)
#
# @book-id: book number within drawer/node/board the CPU belongs to
# (since 8.2)
> +#
> +# @socket-id: socket number within book/node/board the CPU belongs to
> #
> # @die-id: die number within socket the CPU belongs to (since 4.1)
> #
> @@ -912,7 +917,7 @@
##
# @CpuInstanceProperties:
#
# List of properties to be used for hotplugging a CPU instance, it
# should be passed by management with device_add command when a CPU is
# being hotplugged.
#
# @node-id: NUMA node ID the CPU belongs to
#
# @socket-id: socket number within node/board the CPU belongs to
#
# @die-id: die number within socket the CPU belongs to (since 4.1)
#
# @cluster-id: cluster number within die the CPU belongs to (since
# 7.1)
#
# @core-id: core number within cluster the CPU belongs to
> #
> # @thread-id: thread number within core the CPU belongs to
> #
> -# Note: currently there are 6 properties that could be present but
> +# Note: currently there are 8 properties that could be present but
> # management should be prepared to pass through other properties
> # with device_add command to allow for future interface extension.
> # This also requires the filed names to be kept in sync with the
# properties passed to -device/device_add.
The last sentence is for developers, not for users, which means it
doesn't belong here. Suggest to move it to a non-doc comment, and
rephrase the note like
# Note: management should be prepared to pass through additional
# properties with device_add.
> @@ -922,6 +927,8 @@
> ##
> { 'struct': 'CpuInstanceProperties',
Non-doc comment could go here:
# Keep these in sync with the properties device_add accepts
Again, not your patch's fault, but your help improving this stuff would
be appreciated.
> 'data': { '*node-id': 'int',
> + '*drawer-id': 'int',
> + '*book-id': 'int',
> '*socket-id': 'int',
> '*die-id': 'int',
> '*cluster-id': 'int',
'*core-id': 'int',
'*thread-id': 'int'
}
}
> @@ -1480,6 +1487,10 @@
> #
> # @cpus: number of virtual CPUs in the virtual machine
> #
> +# @drawers: number of drawers in the CPU topology (since 8.2)
> +#
> +# @books: number of books in the CPU topology (since 8.2)
> +#
> # @sockets: number of sockets in the CPU topology
> #
> # @dies: number of dies per socket in the CPU topology
> @@ -1498,6 +1509,8 @@
> ##
> { 'struct': 'SMPConfiguration', 'data': {
> '*cpus': 'int',
> + '*drawers': 'int',
> + '*books': 'int',
> '*sockets': 'int',
> '*dies': 'int',
> '*clusters': 'int',
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 6c67af196a..6dcfc879eb 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -134,12 +134,16 @@ typedef struct {
> * @clusters_supported - whether clusters are supported by the machine
> * @has_clusters - whether clusters are explicitly specified in the user
> * provided SMP configuration
> + * @books_supported - whether books are supported by the machine
> + * @drawers_supported - whether drawers are supported by the machine
> */
> typedef struct {
> bool prefer_sockets;
> bool dies_supported;
> bool clusters_supported;
> bool has_clusters;
> + bool books_supported;
> + bool drawers_supported;
> } SMPCompatProps;
>
> /**
> @@ -310,7 +314,9 @@ typedef struct DeviceMemoryState {
> /**
> * CpuTopology:
> * @cpus: the number of present logical processors on the machine
> - * @sockets: the number of sockets on the machine
> + * @drawers: the number of drawers on the machine
> + * @books: the number of books in one drawer
> + * @sockets: the number of sockets in one book
> * @dies: the number of dies in one socket
> * @clusters: the number of clusters in one die
> * @cores: the number of cores in one cluster
> @@ -319,6 +325,8 @@ typedef struct DeviceMemoryState {
> */
> typedef struct CpuTopology {
> unsigned int cpus;
> + unsigned int drawers;
> + unsigned int books;
> unsigned int sockets;
> unsigned int dies;
> unsigned int clusters;
[...]
> diff --git a/qapi/meson.build b/qapi/meson.build
> index 60a668b343..f81a37565c 100644
> --- a/qapi/meson.build
> +++ b/qapi/meson.build
> @@ -36,6 +36,7 @@ qapi_all_modules = [
> 'error',
> 'introspect',
> 'job',
> + 'machine-common',
> 'machine',
> 'machine-target',
> 'migration',
[...]
- Re: [PATCH v23 12/20] qapi/s390x/cpu topology: query-cpu-polarization qmp command, (continued)
- [PATCH v23 18/20] tests/avocado: s390x cpu topology test socket full, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 06/20] s390x/cpu topology: interception of PTF instruction, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 09/20] machine: adding s390 topology to query-cpu-fast, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 05/20] s390x/cpu topology: resetting the Topology-Change-Report, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 14/20] tests/avocado: s390x cpu topology core, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 17/20] tests/avocado: s390x cpu topology test dedicated CPU, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 15/20] tests/avocado: s390x cpu topology polarization, Nina Schoetterl-Glausch, 2023/09/14
- [PATCH v23 01/20] CPU topology: extend with s390 specifics, Nina Schoetterl-Glausch, 2023/09/14
- Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics,
Markus Armbruster <=
- Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics, Nina Schoetterl-Glausch, 2023/09/25
- Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics, Markus Armbruster, 2023/09/25
Re: [PATCH v23 01/20] CPU topology: extend with s390 specifics, Markus Armbruster, 2023/09/20
[PATCH v23 20/20] tests/avocado: s390x cpu topology bad move, Nina Schoetterl-Glausch, 2023/09/14