From: Pierre Morel <pmorel@linux.ibm.com>
To: Thomas Huth <thuth@redhat.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, 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, frankja@linux.ibm.com
Subject: Re: [PATCH v8 02/12] s390x/cpu_topology: CPU topology objects and structures
Date: Tue, 23 Aug 2022 18:30:31 +0200 [thread overview]
Message-ID: <c4b9bae1-3a49-abcc-d914-538567d09ef5@linux.ibm.com> (raw)
In-Reply-To: <b6c981e0-56f5-25c3-3422-ed72c8561712@redhat.com>
On 8/23/22 15:30, Thomas Huth wrote:
> On 20/06/2022 16.03, Pierre Morel wrote:
>> We use new objects to have a dynamic administration of the CPU topology.
>> The highest level object in this implementation is the s390 book and
>> in this first implementation of CPU topology for S390 we have a single
>> book.
>> The book is built as a SYSBUS bridge during the CPU initialization.
>> Other objects, sockets and core will be built after the parsing
>> of the QEMU -smp argument.
>>
>> Every object under this single book will be build dynamically
>> immediately after a CPU has be realized if it is needed.
>> The CPU will fill the sockets once after the other, according to the
>> number of core per socket defined during the smp parsing.
>>
>> Each CPU inside a socket will be represented by a bit in a 64bit
>> unsigned long. Set on plug and clear on unplug of a CPU.
>>
>> For the S390 CPU topology, thread and cores are merged into
>> topology cores and the number of topology cores is the multiplication
>> of cores by the numbers of threads.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>> hw/s390x/cpu-topology.c | 391 ++++++++++++++++++++++++++++++++
>> hw/s390x/meson.build | 1 +
>> hw/s390x/s390-virtio-ccw.c | 6 +
>> include/hw/s390x/cpu-topology.h | 74 ++++++
>> target/s390x/cpu.h | 47 ++++
>> 5 files changed, 519 insertions(+)
>> create mode 100644 hw/s390x/cpu-topology.c
>> create mode 100644 include/hw/s390x/cpu-topology.h
> ...
>> +bool s390_topology_new_cpu(MachineState *ms, int core_id, Error **errp)
>> +{
>> + S390TopologyBook *book;
>> + S390TopologySocket *socket;
>> + S390TopologyCores *cores;
>> + int nb_cores_per_socket;
>> + int origin, bit;
>> +
>> + book = s390_get_topology();
>> +
>> + nb_cores_per_socket = ms->smp.cores * ms->smp.threads;
>> +
>> + socket = s390_get_socket(ms, book, core_id / nb_cores_per_socket,
>> errp);
>> + if (!socket) {
>> + return false;
>> + }
>> +
>> + /*
>> + * At the core level, each CPU is represented by a bit in a 64bit
>> + * unsigned long. Set on plug and clear on unplug of a CPU.
>> + * The firmware assume that all CPU in the core description have
>> the same
>> + * type, polarization and are all dedicated or shared.
>> + * In the case a socket contains CPU with different type,
>> polarization
>> + * or dedication then they will be defined in different CPU
>> containers.
>> + * Currently we assume all CPU are identical and the only reason
>> to have
>> + * several S390TopologyCores inside a socket is to have more than
>> 64 CPUs
>> + * in that case the origin field, representing the offset of the
>> first CPU
>> + * in the CPU container allows to represent up to the maximal
>> number of
>> + * CPU inside several CPU containers inside the socket container.
>> + */
>> + origin = 64 * (core_id / 64);
>
> Maybe faster:
>
> origin = core_id & ~63;
yes thanks
>
> By the way, where is this limitation to 64 coming from? Just because
> we're using a "unsigned long" for now? Or is this a limitation from the
> architecture?
>
It is a limitation from the architecture who use a 64bit field to
represent the CPUs in a CPU TLE mask.
but this patch serie is quite old now and I changed some things
according to the comments I received
I plan to send the new version before the end of the week.
>> + cores = s390_get_cores(ms, socket, origin, errp);
>> + if (!cores) {
>> + return false;
>> + }
>> +
>> + bit = 63 - (core_id - origin);
>> + set_bit(bit, &cores->mask);
>> + cores->origin = origin;
>> +
>> + return true;
>> +}
> ...
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index cc3097bfee..a586875b24 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -43,6 +43,7 @@
>> #include "sysemu/sysemu.h"
>> #include "hw/s390x/pv.h"
>> #include "migration/blocker.h"
>> +#include "hw/s390x/cpu-topology.h"
>> static Error *pv_mig_blocker;
>> @@ -89,6 +90,7 @@ static void s390_init_cpus(MachineState *machine)
>> /* initialize possible_cpus */
>> mc->possible_cpu_arch_ids(machine);
>> + s390_topology_setup(machine);
>
> Is this safe with regards to migration? Did you tried a ping-pong
> migration from an older QEMU to a QEMU with your modifications and back
> to the older one? If it does not work, we might need to wire this setup
> to the machine types...
I did not, I will add this test.
>
>> for (i = 0; i < machine->smp.cpus; i++) {
>> s390x_new_cpu(machine->cpu_type, i, &error_fatal);
>> }
>> @@ -306,6 +308,10 @@ static void s390_cpu_plug(HotplugHandler
>> *hotplug_dev,
>> g_assert(!ms->possible_cpus->cpus[cpu->env.core_id].cpu);
>> ms->possible_cpus->cpus[cpu->env.core_id].cpu = OBJECT(dev);
>> + if (!s390_topology_new_cpu(ms, cpu->env.core_id, errp)) {
>> + return;
>> + }
>> +
>> if (dev->hotplugged) {
>> raise_irq_cpu_hotplug();
>> }
>
> Thomas
>
Thanks Thomas,
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
next prev parent reply other threads:[~2022-08-23 16:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 14:03 [PATCH v8 00/12] s390x: CPU Topology Pierre Morel
2022-06-20 14:03 ` [PATCH v8 01/12] Update Linux Headers Pierre Morel
2022-06-20 14:03 ` [PATCH v8 02/12] s390x/cpu_topology: CPU topology objects and structures Pierre Morel
2022-06-27 13:31 ` Janosch Frank
2022-06-28 11:08 ` Pierre Morel
2022-06-29 15:25 ` Pierre Morel
2022-07-04 11:47 ` Janosch Frank
2022-07-04 14:51 ` Pierre Morel
2022-07-12 15:40 ` Janis Schoetterl-Glausch
2022-07-13 14:59 ` Pierre Morel
2022-07-14 10:38 ` Janis Schoetterl-Glausch
2022-07-14 11:25 ` Pierre Morel
2022-07-14 12:50 ` Janis Schoetterl-Glausch
2022-07-14 19:26 ` Pierre Morel
2022-08-23 13:30 ` Thomas Huth
2022-08-23 16:30 ` Pierre Morel [this message]
2022-08-23 17:41 ` Pierre Morel
2022-08-24 7:30 ` Thomas Huth
2022-08-24 8:41 ` Pierre Morel
2022-06-20 14:03 ` [PATCH v8 03/12] s390x/cpu_topology: implementating Store Topology System Information Pierre Morel
2022-06-27 14:26 ` Janosch Frank
2022-06-28 11:03 ` Pierre Morel
2022-07-20 19:34 ` Janis Schoetterl-Glausch
2022-07-21 11:23 ` Pierre Morel
2022-06-20 14:03 ` [PATCH v8 04/12] s390x/cpu_topology: Adding books to CPU topology Pierre Morel
2022-06-20 14:03 ` [PATCH v8 05/12] s390x/cpu_topology: Adding books to STSI Pierre Morel
2022-06-20 14:03 ` [PATCH v8 06/12] s390x/cpu_topology: Adding drawers to CPU topology Pierre Morel
2022-06-20 14:03 ` [PATCH v8 07/12] s390x/cpu_topology: Adding drawers to STSI Pierre Morel
2022-06-20 14:03 ` [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology Pierre Morel
2022-07-14 14:57 ` Janis Schoetterl-Glausch
2022-07-14 20:17 ` Pierre Morel
2022-07-15 9:11 ` Janis Schoetterl-Glausch
2022-07-15 13:07 ` Pierre Morel
2022-07-20 17:24 ` Janis Schoetterl-Glausch
2022-07-21 7:58 ` Pierre Morel
2022-07-21 8:16 ` Janis Schoetterl-Glausch
2022-07-21 11:41 ` Pierre Morel
2022-07-22 12:08 ` Janis Schoetterl-Glausch
2022-08-23 16:25 ` Pierre Morel
2022-06-20 14:03 ` [PATCH v8 09/12] target/s390x: interception of PTF instruction Pierre Morel
2022-06-20 14:03 ` [PATCH v8 10/12] s390x/cpu_topology: resetting the Topology-Change-Report Pierre Morel
2022-06-20 14:03 ` [PATCH v8 11/12] s390x/cpu_topology: CPU topology migration Pierre Morel
2022-06-20 14:03 ` [PATCH v8 12/12] s390x/cpu_topology: activating CPU topology Pierre Morel
2022-07-14 18:43 ` [PATCH v8 00/12] s390x: CPU Topology Janis Schoetterl-Glausch
2022-07-14 20:05 ` Pierre Morel
2022-07-15 9:31 ` Janis Schoetterl-Glausch
2022-07-15 13:47 ` Pierre Morel
2022-07-15 18:28 ` Janis Schoetterl-Glausch
2022-07-18 12:32 ` 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=c4b9bae1-3a49-abcc-d914-538567d09ef5@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=armbru@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=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).