From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
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, frankja@linux.ibm.com
Subject: Re: [PATCH v9 02/10] s390x/cpu topology: core_id sets s390x CPU topology
Date: Mon, 05 Sep 2022 20:11:47 +0200 [thread overview]
Message-ID: <bac31c028a713c32130b397189552f17b43a9485.camel@linux.ibm.com> (raw)
In-Reply-To: <20220902075531.188916-3-pmorel@linux.ibm.com>
On Fri, 2022-09-02 at 09:55 +0200, Pierre Morel wrote:
> In the S390x CPU topology the core_id specifies the CPU address
> and the position of the core withing the topology.
>
> Let's build the topology based on the core_id.
>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
> hw/s390x/cpu-topology.c | 135 ++++++++++++++++++++++++++++++++
> hw/s390x/meson.build | 1 +
> hw/s390x/s390-virtio-ccw.c | 10 +++
> include/hw/s390x/cpu-topology.h | 42 ++++++++++
> 4 files changed, 188 insertions(+)
> create mode 100644 hw/s390x/cpu-topology.c
> create mode 100644 include/hw/s390x/cpu-topology.h
>
> diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
>
[...]
> +/**
> + * s390_topology_realize:
> + * @dev: the device state
> + * @errp: the error pointer (not used)
> + *
> + * During realize the machine CPU topology is initialized with the
> + * QEMU -smp parameters.
> + * The maximum count of CPU TLE in the all Topology can not be greater
> + * than the maximum CPUs.
> + */
> +static void s390_topology_realize(DeviceState *dev, Error **errp)
> +{
> + MachineState *ms = MACHINE(qdev_get_machine());
> + S390Topology *topo = S390_CPU_TOPOLOGY(dev);
> + int n;
> +
> + topo->sockets = ms->smp.sockets;
> + topo->cores = ms->smp.cores;
> + topo->tles = ms->smp.max_cpus;
> +
> + n = topo->sockets;
> + topo->socket = g_malloc0(n * sizeof(S390TopoContainer));
> + topo->tle = g_malloc0(topo->tles * sizeof(S390TopoTLE));
Seems like a good use case for g_new0.
[...]
>
> diff --git a/include/hw/s390x/cpu-topology.h b/include/hw/s390x/cpu-topology.h
> new file mode 100644
> index 0000000000..6911f975f4
> --- /dev/null
> +++ b/include/hw/s390x/cpu-topology.h
> @@ -0,0 +1,42 @@
> +/*
> + * CPU Topology
> + *
> + * Copyright 2022 IBM Corp.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
> + * your option) any later version. See the COPYING file in the top-level
> + * directory.
> + */
> +#ifndef HW_S390X_CPU_TOPOLOGY_H
> +#define HW_S390X_CPU_TOPOLOGY_H
Is there a reason this is before the includes?
> +
> +typedef struct S390TopoContainer {
> + int active_count;
> +} S390TopoContainer;
> +
> +#define S390_TOPOLOGY_MAX_ORIGIN (1 + S390_MAX_CPUS / 64)
This is correct because cpu_id == core_id for s390, right?
So the cpu limit also applies to the core id.
You could do ((S390_MAX_CPUS + 63) / 64) instead.
But if you chose this for simplicity's sake, I'm fine with it.
> +typedef struct S390TopoTLE {
> + int active_count;
Do you use (read) this field somewhere?
Is this in anticipation of there being multiple TLE arrays, for
different polarizations, etc? If so I would defer this for later.
> + uint64_t mask[S390_TOPOLOGY_MAX_ORIGIN];
> +} S390TopoTLE;
> +
> +#include "hw/qdev-core.h"
> +#include "qom/object.h"
> +
> +struct S390Topology {
> + SysBusDevice parent_obj;
> + int sockets;
> + int cores;
These are just cached values from machine_state.smp, right?
Not sure if I like the redundancy, it doesn't aid in comprehension.
> + int tles;
> + S390TopoContainer *socket;
> + S390TopoTLE *tle;
> +};
> +typedef struct S390Topology S390Topology;
The DECLARE macro takes care of this typedef.
> +
> +#define TYPE_S390_CPU_TOPOLOGY "s390-topology"
> +OBJECT_DECLARE_SIMPLE_TYPE(S390Topology, S390_CPU_TOPOLOGY)
> +
> +S390Topology *s390_get_topology(void);
> +void s390_topology_new_cpu(int core_id);
> +
> +#endif
next prev parent reply other threads:[~2022-09-05 18:14 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-02 7:55 [PATCH v9 00/10] s390x: CPU Topology Pierre Morel
2022-09-02 7:55 ` [PATCH v9 01/10] s390x/cpus: Make absence of multithreading clear Pierre Morel
2022-09-05 11:32 ` Nico Boehr
2022-09-05 15:10 ` Pierre Morel
2022-09-05 15:23 ` Janis Schoetterl-Glausch
2022-09-05 15:42 ` Pierre Morel
2022-09-27 9:44 ` Cédric Le Goater
2022-09-28 13:21 ` Pierre Morel
2022-09-28 16:16 ` Pierre Morel
2022-09-28 16:28 ` Cédric Le Goater
2022-10-11 7:21 ` Pierre Morel
2022-10-11 7:28 ` Cédric Le Goater
2022-09-28 18:11 ` Daniel P. Berrangé
2022-10-10 17:20 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 02/10] s390x/cpu topology: core_id sets s390x CPU topology Pierre Morel
2022-09-05 18:11 ` Janis Schoetterl-Glausch [this message]
2022-09-12 15:34 ` Pierre Morel
2022-09-06 5:58 ` Nico Boehr
2022-09-12 15:40 ` Pierre Morel
2022-09-27 12:03 ` Cédric Le Goater
2022-09-28 13:15 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 03/10] s390x/cpu topology: reporting the CPU topology to the guest Pierre Morel
2022-09-06 8:17 ` Nico Boehr
2022-09-28 10:03 ` Pierre Morel
2022-09-06 11:49 ` Janis Schoetterl-Glausch
2022-09-28 10:01 ` Pierre Morel
2022-09-07 10:26 ` Janis Schoetterl-Glausch
2022-09-28 9:07 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 04/10] hw/core: introducing drawer and books for s390x Pierre Morel
2022-09-06 8:59 ` Markus Armbruster
2022-09-28 9:04 ` Pierre Morel
2022-09-28 9:06 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 05/10] s390x/cpu: reporting drawers and books topology to the guest Pierre Morel
2022-09-07 10:36 ` Janis Schoetterl-Glausch
2022-09-28 8:55 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 06/10] s390x/cpu_topology: resetting the Topology-Change-Report Pierre Morel
2022-09-06 8:27 ` Nico Boehr
2022-09-28 8:35 ` Pierre Morel
2022-09-08 7:57 ` Janis Schoetterl-Glausch
2022-09-28 8:46 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 07/10] s390x/cpu_topology: CPU topology migration Pierre Morel
2022-09-08 18:04 ` Janis Schoetterl-Glausch
2022-09-28 8:34 ` Pierre Morel
2022-09-29 17:30 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 08/10] target/s390x: interception of PTF instruction Pierre Morel
2022-09-09 16:50 ` Janis Schoetterl-Glausch
2022-09-28 13:34 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 09/10] s390x/cpu_topology: activating CPU topology Pierre Morel
2022-09-05 15:29 ` Pierre Morel
2022-09-27 14:41 ` Cédric Le Goater
2022-09-28 8:15 ` Pierre Morel
2022-09-02 7:55 ` [PATCH v9 10/10] docs/s390x: document s390x cpu topology Pierre Morel
2022-09-12 13:41 ` Janis Schoetterl-Glausch
2022-09-28 8:19 ` Pierre Morel
2022-09-12 13:48 ` Janis Schoetterl-Glausch
2022-09-12 14:38 ` [PATCH v9 00/10] s390x: CPU Topology Janis Schoetterl-Glausch
2022-09-28 8:28 ` Pierre Morel
2022-11-16 16:51 ` Christian Borntraeger
2022-11-17 9:31 ` Pierre Morel
2022-11-17 16:38 ` Pierre Morel
2022-11-24 9:25 ` Pierre Morel
2022-11-27 10:50 ` 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=bac31c028a713c32130b397189552f17b43a9485.camel@linux.ibm.com \
--to=scgl@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=pmorel@linux.ibm.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).