All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: Pierre Morel <pmorel@linux.ibm.com>, <qemu-s390x@nongnu.org>
Cc: <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>, <berrange@redhat.com>
Subject: Re: [PATCH v13 0/7] s390x: CPU Topology
Date: Fri, 9 Dec 2022 15:45:17 +0100	[thread overview]
Message-ID: <d29c06e6-48e2-6cff-0524-297eaab0516b@kaod.org> (raw)
In-Reply-To: <20221208094432.9732-1-pmorel@linux.ibm.com>

On 12/8/22 10:44, Pierre Morel wrote:
> Hi,
> 
> Implementation discussions
> ==========================
> 
> CPU models
> ----------
> 
> Since the S390_FEAT_CONFIGURATION_TOPOLOGY is already in the CPU model
> for old QEMU we could not activate it as usual from KVM but needed
> a KVM capability: KVM_CAP_S390_CPU_TOPOLOGY.
> Checking and enabling this capability enables
> S390_FEAT_CONFIGURATION_TOPOLOGY.
> 
> Migration
> ---------
> 
> Once the S390_FEAT_CONFIGURATION_TOPOLOGY is enabled in the source
> host the STFL(11) is provided to the guest.
> Since the feature is already in the CPU model of older QEMU,
> a migration from a new QEMU enabling the topology to an old QEMU
> will keep STFL(11) enabled making the guest get an exception for
> illegal operation as soon as it uses the PTF instruction.
> 
> A VMState keeping track of the S390_FEAT_CONFIGURATION_TOPOLOGY
> allows to forbid the migration in such a case.
> 
> Note that the VMState will be used to hold information on the
> topology once we implement topology change for a running guest.
> 
> Topology
> --------
> 
> Until we introduce bookss and drawers, polarization and dedication
> the topology is kept very simple and is specified uniquely by
> the core_id of the vCPU which is also the vCPU address.
> 
> Testing
> =======
> 
> To use the QEMU patches, you will need Linux V6-rc1 or newer,
> or use the following Linux mainline patches:
> 
> f5ecfee94493 2022-07-20 KVM: s390: resetting the Topology-Change-Report
> 24fe0195bc19 2022-07-20 KVM: s390: guest support for topology function
> 0130337ec45b 2022-07-20 KVM: s390: Cleanup ipte lock access and SIIF fac..
> 
> Currently this code is for KVM only, I have no idea if it is interesting
> to provide a TCG patch. If ever it will be done in another series.
> 
> Documentation
> =============
> 
> To have a better understanding of the S390x CPU Topology and its
> implementation in QEMU you can have a look at the documentation in the
> last patch of this series.
> 
> The admin will want to match the host and the guest topology, taking
> into account that the guest does not recognize multithreading.
> Consequently, two vCPU assigned to threads of the same real CPU should
> preferably be assigned to the same socket of the guest machine.
> 
> Future developments
> ===================
> 
> Two series are actively prepared:
> - Adding drawers, book, polarization and dedication to the vCPU.
> - changing the topology with a running guest

Since we have time before the next QEMU 8.0 release, could you please
send the whole patchset ? Having the full picture would help in taking
decisions for downstream also.

I am still uncertain about the usefulness of S390Topology object because,
as for now, the state can be computed on the fly, the reset can be
handled at the machine level directly under s390_machine_reset() and so
could migration if the machine had a vmstate (not the case today but
quite easy to add). So before merging anything that could be difficult
to maintain and/or backport, I would prefer to see it all !

Thanks,

C.


> 
> Regards,
> Pierre
> 
> Pierre Morel (7):
>    s390x/cpu topology: Creating CPU topology device
>    s390x/cpu topology: reporting the CPU topology to the guest
>    s390x/cpu_topology: resetting the Topology-Change-Report
>    s390x/cpu_topology: CPU topology migration
>    s390x/cpu_topology: interception of PTF instruction
>    s390x/cpu_topology: activating CPU topology
>    docs/s390x: document s390x cpu topology
> 
>   docs/system/s390x/cpu-topology.rst |  87 ++++++++++
>   docs/system/target-s390x.rst       |   1 +
>   include/hw/s390x/cpu-topology.h    |  52 ++++++
>   include/hw/s390x/s390-virtio-ccw.h |   6 +
>   target/s390x/cpu.h                 |  78 +++++++++
>   target/s390x/kvm/kvm_s390x.h       |   1 +
>   hw/s390x/cpu-topology.c            | 261 +++++++++++++++++++++++++++++
>   hw/s390x/s390-virtio-ccw.c         |   7 +
>   target/s390x/cpu-sysemu.c          |  21 +++
>   target/s390x/cpu_models.c          |   1 +
>   target/s390x/kvm/cpu_topology.c    | 186 ++++++++++++++++++++
>   target/s390x/kvm/kvm.c             |  46 ++++-
>   hw/s390x/meson.build               |   1 +
>   target/s390x/kvm/meson.build       |   3 +-
>   14 files changed, 749 insertions(+), 2 deletions(-)
>   create mode 100644 docs/system/s390x/cpu-topology.rst
>   create mode 100644 include/hw/s390x/cpu-topology.h
>   create mode 100644 hw/s390x/cpu-topology.c
>   create mode 100644 target/s390x/kvm/cpu_topology.c
> 


  parent reply	other threads:[~2022-12-09 14:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08  9:44 [PATCH v13 0/7] s390x: CPU Topology Pierre Morel
2022-12-08  9:44 ` [PATCH v13 1/7] s390x/cpu topology: Creating CPU topology device Pierre Morel
2022-12-09 13:50   ` Thomas Huth
2022-12-12  8:52     ` Pierre Morel
2022-12-09 14:51   ` Cédric Le Goater
2022-12-08  9:44 ` [PATCH v13 2/7] s390x/cpu topology: reporting the CPU topology to the guest Pierre Morel
2022-12-09 15:43   ` Cédric Le Goater
2022-12-12  9:21     ` Pierre Morel
2022-12-08  9:44 ` [PATCH v13 3/7] s390x/cpu_topology: resetting the Topology-Change-Report Pierre Morel
2022-12-08  9:44 ` [PATCH v13 4/7] s390x/cpu_topology: CPU topology migration Pierre Morel
2022-12-09 14:56   ` Cédric Le Goater
2022-12-12  9:14     ` Pierre Morel
2022-12-11 14:55   ` Pierre Morel
2022-12-13 13:26   ` Christian Borntraeger
2022-12-13 17:40     ` Pierre Morel
2022-12-08  9:44 ` [PATCH v13 5/7] s390x/cpu_topology: interception of PTF instruction Pierre Morel
2022-12-08  9:44 ` [PATCH v13 6/7] s390x/cpu_topology: activating CPU topology Pierre Morel
2022-12-08  9:44 ` [PATCH v13 7/7] docs/s390x: document s390x cpu topology Pierre Morel
2022-12-09 13:32 ` [PATCH v13 0/7] s390x: CPU Topology Thomas Huth
2022-12-12  8:51   ` Pierre Morel
2022-12-12  9:07     ` Thomas Huth
2022-12-12 10:10       ` Pierre Morel
2022-12-12 10:17         ` Thomas Huth
2022-12-13 13:41           ` Christian Borntraeger
2022-12-13 13:57             ` Janis Schoetterl-Glausch
2022-12-13 14:00               ` Christian Borntraeger
2022-12-13 17:24             ` Pierre Morel
2022-12-14 10:39               ` Thomas Huth
2022-12-09 14:45 ` Cédric Le Goater [this message]
2022-12-12 10:01   ` Pierre Morel
2022-12-13 13:50     ` Christian Borntraeger
2022-12-13 15:12       ` Christian Borntraeger
2022-12-13 15:31         ` Janis Schoetterl-Glausch
2022-12-13 17:27           ` 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=d29c06e6-48e2-6cff-0524-297eaab0516b@kaod.org \
    --to=clg@kaod.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.