qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v23 08/20] qapi/s390x/cpu topology: set-cpu-topology qmp comm


From: Markus Armbruster
Subject: Re: [PATCH v23 08/20] qapi/s390x/cpu topology: set-cpu-topology qmp command
Date: Wed, 20 Sep 2023 13:36:13 +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>
>
> The modification of the CPU attributes are done through a monitor
> command.
>
> It allows to move the core inside the topology tree to optimize
> the cache usage in the case the host's hypervisor previously
> moved the CPU.
>
> The same command allows to modify the CPU attributes modifiers
> like polarization entitlement and the dedicated attribute to notify
> the guest if the host admin modified scheduling or dedication of a vCPU.
>
> With this knowledge the guest has the possibility to optimize the
> usage of the vCPUs.
>
> The command has a feature unstable for the moment.
>
> 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-target.json |  37 +++++++++++
>  hw/s390x/cpu-topology.c  | 132 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 169 insertions(+)
>
> diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> index 0d45a590ce..e47a252bd9 100644
> --- a/qapi/machine-target.json
> +++ b/qapi/machine-target.json
> @@ -4,6 +4,8 @@
>  # This work is licensed under the terms of the GNU GPL, version 2 or later.
>  # See the COPYING file in the top-level directory.
>  
> +{ 'include': 'machine-common.json' }
> +
>  ##
>  # @CpuModelInfo:
>  #
> @@ -375,3 +377,38 @@
>    'data': [ 'horizontal', 'vertical' ],
>      'if': 'TARGET_S390X'
>  }
> +
> +##
> +# @set-cpu-topology:

Move the overview here from [*] below.

> +#
> +# @core-id: the vCPU ID to be moved
> +# @socket-id: optional destination socket where to move the vCPU
> +# @book-id: optional destination book where to move the vCPU
> +# @drawer-id: optional destination drawer where to move the vCPU
> +# @entitlement: optional entitlement
> +# @dedicated: optional, if the vCPU is dedicated to a real CPU

Separate the members with blank lines, please.

The doc generator adds optional automatically, so this will come out
like

    "socket-id": "int" (optional)
       optional destination socket where to move the vCPU

    "book-id": "int" (optional)
       optional destination book where to move the vCPU

    "drawer-id": "int" (optional)
       optional destination drawer where to move the vCPU

    "entitlement": "CpuS390Entitlement" (optional)
       optional entitlement

    "dedicated": "boolean" (optional)
       optional, if the vCPU is dedicated to a real CPU

Drop the optional from the text.

Suggest

   # @dedicated: whether the vCPU is dedicated to a real CPU

(whatever that may mean; I'm an S390 noob)

> +#
> +# Features:

Another blank line, please.

> +# @unstable: This command may still be modified.
> +#

[*] The overview:

> +# Modifies the topology by moving the CPU inside the topology
> +# tree or by changing a modifier attribute of a CPU.
> +# Default value for optional parameter is the current value
> +# used by the CPU.

So, anything absent will not be changed.  Maybe that's a clearer way to
put it.  What do you think?

> +#
> +# Returns: Nothing on success, the reason on failure.
> +#
> +# Since: 8.2
> +##
> +{ 'command': 'set-cpu-topology',
> +  'data': {
> +      'core-id': 'uint16',
> +      '*socket-id': 'uint16',
> +      '*book-id': 'uint16',
> +      '*drawer-id': 'uint16',

CpuInstanceProperties uses 'int' for these.  Any particular reason for
the difference?

> +      '*entitlement': 'CpuS390Entitlement',
> +      '*dedicated': 'bool'
> +  },
> +  'features': [ 'unstable' ],
> +  'if': { 'all': [ 'TARGET_S390X' , 'CONFIG_KVM' ] }
> +}

[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]