public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
	borntraeger@de.ibm.com, pasic@linux.ibm.com,
	richard.henderson@linaro.org, david@redhat.com, thuth@redhat.com,
	cohuck@redhat.com, mst@redhat.com, pbonzini@redhat.com,
	kvm@vger.kernel.org, ehabkost@redhat.com,
	marcel.apfelbaum@gmail.com, eblake@redhat.com, armbru@redhat.com,
	seiden@linux.ibm.com, nrb@linux.ibm.com, scgl@linux.ibm.com,
	frankja@linux.ibm.com, clg@kaod.org
Subject: Re: [PATCH v14 08/11] qapi/s390/cpu topology:  change-topology monitor command
Date: Thu, 12 Jan 2023 12:03:01 +0000	[thread overview]
Message-ID: <Y7/29cONlVoKukIP@redhat.com> (raw)
In-Reply-To: <20230105145313.168489-9-pmorel@linux.ibm.com>

On Thu, Jan 05, 2023 at 03:53:10PM +0100, Pierre Morel wrote:
> The modification of the CPU attributes are done through a monitor
> commands.
> 
> It allows to move the core inside the topology tree to optimise
> the cache usage in the case the host's hypervizor previously
> moved the CPU.
> 
> The same command allows to modifiy 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.
> 
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
>  qapi/machine-target.json |  29 ++++++++
>  include/monitor/hmp.h    |   1 +
>  hw/s390x/cpu-topology.c  | 141 +++++++++++++++++++++++++++++++++++++++
>  hmp-commands.hx          |  16 +++++
>  4 files changed, 187 insertions(+)
> 
> diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> index 2e267fa458..75b0aa254d 100644
> --- a/qapi/machine-target.json
> +++ b/qapi/machine-target.json
> @@ -342,3 +342,32 @@
>                     'TARGET_S390X',
>                     'TARGET_MIPS',
>                     'TARGET_LOONGARCH64' ] } }
> +
> +##
> +# @change-topology:
> +#
> +# @core: the vCPU ID to be moved
> +# @socket: the destination socket where to move the vCPU
> +# @book: the destination book where to move the vCPU
> +# @drawer: the destination drawer where to move the vCPU

This movement can be done while the guest OS is running ?
What happens to guest OS apps ? Every I know will read
topology once and assume it never changes at runtime.

What's the use case for wanting to re-arrange topology in
this manner ? It feels like its going to be a recipe for
hard to diagnose problems, as much code in libvirt and apps
above will assuming the vCPU IDs are assigned sequentially
starting from node=0,book=0,drawer=0,socket=0,core=0,
incrementing core, then incrementing socket, then
incrementing drawer, etc.

> +# @polarity: optional polarity, default is last polarity set by the guest
> +# @dedicated: optional, if the vCPU is dedicated to a real CPU
> +#
> +# Modifies the topology by moving the CPU inside the topology
> +# tree or by changing a modifier attribute of a CPU.
> +#
> +# Returns: Nothing on success, the reason on failure.
> +#
> +# Since: <next qemu stable release, eg. 1.0>
> +##
> +{ 'command': 'change-topology',

'set-cpu-topology'

> +  'data': {
> +      'core': 'int',
> +      'socket': 'int',
> +      'book': 'int',
> +      'drawer': 'int',
> +      '*polarity': 'int',
> +      '*dedicated': 'bool'
> +  },
> +  'if': { 'all': [ 'TARGET_S390X', 'CONFIG_KVM' ] }
> +}


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2023-01-12 12:09 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 14:53 [PATCH v14 00/11] s390x: CPU Topology Pierre Morel
2023-01-05 14:53 ` [PATCH v14 01/11] s390x/cpu topology: adding s390 specificities to CPU topology Pierre Morel
2023-01-10 11:37   ` Thomas Huth
2023-01-16 16:32     ` Pierre Morel
2023-01-17  7:25       ` Thomas Huth
2023-01-13 16:58   ` Nina Schoetterl-Glausch
2023-01-16 17:28     ` Pierre Morel
2023-01-16 20:34       ` Nina Schoetterl-Glausch
2023-01-17  9:49         ` Pierre Morel
2023-01-17  7:22       ` Thomas Huth
2023-01-05 14:53 ` [PATCH v14 02/11] s390x/cpu topology: add topology entries on CPU hotplug Pierre Morel
2023-01-10 13:00   ` Thomas Huth
2023-01-11  9:23     ` Nina Schoetterl-Glausch
2023-01-16 18:24     ` Pierre Morel
2023-01-13 18:15   ` Nina Schoetterl-Glausch
2023-01-17 13:55     ` Pierre Morel
2023-01-17 16:48       ` Nina Schoetterl-Glausch
2023-01-19 13:34         ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 03/11] target/s390x/cpu topology: handle STSI(15) and build the SYSIB Pierre Morel
2023-01-10 14:29   ` Thomas Huth
2023-01-11  9:16     ` Thomas Huth
2023-01-11 17:14     ` Nina Schoetterl-Glausch
2023-01-17 16:58       ` Pierre Morel
2023-01-17 16:56     ` Pierre Morel
2023-01-18 10:26       ` Thomas Huth
2023-01-18 11:54         ` Nina Schoetterl-Glausch
2023-01-19 13:12           ` Pierre Morel
2023-01-16 13:11   ` Nina Schoetterl-Glausch
2023-01-16 15:39     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 04/11] s390x/sclp: reporting the maximum nested topology entries Pierre Morel
2023-01-11  8:57   ` Thomas Huth
2023-01-17 17:36     ` Pierre Morel
2023-01-17 19:58       ` Nina Schoetterl-Glausch
2023-01-19 13:08         ` Pierre Morel
2023-01-11 17:52   ` Nina Schoetterl-Glausch
2023-01-17 17:44     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 05/11] s390x/cpu topology: resetting the Topology-Change-Report Pierre Morel
2023-01-11  9:00   ` Thomas Huth
2023-01-17 17:57     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 06/11] s390x/cpu topology: interception of PTF instruction Pierre Morel
2023-01-16 18:24   ` Nina Schoetterl-Glausch
2023-01-18  9:54     ` Pierre Morel
2023-01-20 14:32     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 07/11] target/s390x/cpu topology: activating CPU topology Pierre Morel
2023-01-11 10:04   ` Thomas Huth
2023-01-18 10:01     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 08/11] qapi/s390/cpu topology: change-topology monitor command Pierre Morel
2023-01-11 10:09   ` Thomas Huth
2023-01-12  8:00     ` Thomas Huth
2023-01-18 14:23     ` Pierre Morel
2023-01-12 12:03   ` Daniel P. Berrangé [this message]
2023-01-18 13:17     ` Pierre Morel
2023-01-16 21:09   ` Nina Schoetterl-Glausch
2023-01-17  7:30     ` Thomas Huth
2023-01-17 13:31       ` Nina Schoetterl-Glausch
2023-01-18 10:53         ` Thomas Huth
2023-01-18 14:09           ` Pierre Morel
2023-01-18 15:17           ` Kevin Wolf
2023-01-18 15:48             ` Pierre Morel
2023-01-18 14:06     ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 09/11] qapi/s390/cpu topology: monitor query topology information Pierre Morel
2023-01-12 11:48   ` Thomas Huth
2023-01-18 15:59     ` Pierre Morel
2023-01-12 12:10   ` Daniel P. Berrangé
2023-01-12 17:27     ` Nina Schoetterl-Glausch
2023-01-12 17:30       ` Daniel P. Berrangé
2023-01-18 15:58     ` Pierre Morel
2023-01-18 16:08       ` Daniel P. Berrangé
2023-01-18 16:57         ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 10/11] qapi/s390/cpu topology: POLARITY_CHANGE qapi event Pierre Morel
2023-01-12 11:52   ` Thomas Huth
2023-01-18 17:09     ` Pierre Morel
2023-01-20 11:56       ` Thomas Huth
2023-01-20 14:22         ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 11/11] docs/s390x/cpu topology: document s390x cpu topology Pierre Morel
2023-01-12 11:46   ` Thomas Huth
2023-01-19 14:48     ` Pierre Morel
2023-01-12 11:58   ` Daniel P. Berrangé
2023-01-18 17:10     ` Pierre Morel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7/29cONlVoKukIP@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=clg@kaod.org \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=nrb@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=scgl@linux.ibm.com \
    --cc=seiden@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox