From: Pierre Morel <pmorel@linux.ibm.com>
To: Nina Schoetterl-Glausch <nsg@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, berrange@redhat.com,
clg@kaod.org
Subject: Re: [PATCH v19 02/21] s390x/cpu topology: add topology entries on CPU hotplug
Date: Fri, 21 Apr 2023 12:20:30 +0200 [thread overview]
Message-ID: <4ddd3177-58a8-c9f0-a9a8-ee71baf0511b@linux.ibm.com> (raw)
In-Reply-To: <66d9ba0e9904f035326aca609a767976b94547cf.camel@linux.ibm.com>
On 4/20/23 10:59, Nina Schoetterl-Glausch wrote:
> On Mon, 2023-04-03 at 18:28 +0200, Pierre Morel wrote:
>> The topology information are attributes of the CPU and are
>> specified during the CPU device creation.
>>
>> On hot plug we:
>> - calculate the default values for the topology for drawers,
>> books and sockets in the case they are not specified.
>> - verify the CPU attributes
>> - check that we have still room on the desired socket
>>
>> The possibility to insert a CPU in a mask is dependent on the
>> number of cores allowed in a socket, a book or a drawer, the
>> checking is done during the hot plug of the CPU to have an
>> immediate answer.
>>
>> If the complete topology is not specified, the core is added
>> in the physical topology based on its core ID and it gets
>> defaults values for the modifier attributes.
>>
>> This way, starting QEMU without specifying the topology can
>> still get some advantage of the CPU topology.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>> MAINTAINERS | 1 +
>> include/hw/s390x/cpu-topology.h | 44 +++++
>> include/hw/s390x/s390-virtio-ccw.h | 1 +
>> hw/s390x/cpu-topology.c | 282 +++++++++++++++++++++++++++++
>> hw/s390x/s390-virtio-ccw.c | 22 ++-
>> hw/s390x/meson.build | 1 +
>> 6 files changed, 349 insertions(+), 2 deletions(-)
>> create mode 100644 hw/s390x/cpu-topology.c
> [...]
>
>> #endif
>> diff --git a/include/hw/s390x/s390-virtio-ccw.h b/include/hw/s390x/s390-virtio-ccw.h
>> index 9bba21a916..ea10a6c6e1 100644
>> --- a/include/hw/s390x/s390-virtio-ccw.h
>> +++ b/include/hw/s390x/s390-virtio-ccw.h
>> @@ -28,6 +28,7 @@ struct S390CcwMachineState {
>> bool dea_key_wrap;
>> bool pv;
>> uint8_t loadparm[8];
>> + bool vertical_polarization;
> Why is this here and not in s390_topology?
> This splits up the topology state somewhat.
> I don't quite recall, did you use to have s390_topology in S390CcwMachineState at some point?
> I think putting everything in S390CcwMachineState might make sense too.
Hum.
This is a left over from an abandoned try.
I put it back where it was, in s390_topology.
>
>> };
>>
>> struct S390CcwMachineClass {
>> diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
>> new file mode 100644
>> index 0000000000..96da67bd7e
>> --- /dev/null
>> +++ b/hw/s390x/cpu-topology.c
> [...]
>
>> +/**
>> + * s390_topology_cpu_default:
>> + * @cpu: pointer to a S390CPU
>> + * @errp: Error pointer
>> + *
>> + * Setup the default topology if no attributes are already set.
>> + * Passing a CPU with some, but not all, attributes set is considered
>> + * an error.
>> + *
>> + * The function calculates the (drawer_id, book_id, socket_id)
>> + * topology by filling the cores starting from the first socket
>> + * (0, 0, 0) up to the last (smp->drawers, smp->books, smp->sockets).
>> + *
>> + * CPU type and dedication have defaults values set in the
>> + * s390x_cpu_properties, entitlement must be adjust depending on the
>> + * dedication.
>> + */
>> +static void s390_topology_cpu_default(S390CPU *cpu, Error **errp)
>> +{
>> + CpuTopology *smp = s390_topology.smp;
>> + CPUS390XState *env = &cpu->env;
>> +
>> + /* All geometry topology attributes must be set or all unset */
>> + if ((env->socket_id < 0 || env->book_id < 0 || env->drawer_id < 0) &&
>> + (env->socket_id >= 0 || env->book_id >= 0 || env->drawer_id >= 0)) {
>> + error_setg(errp,
>> + "Please define all or none of the topology geometry attributes");
>> + return;
>> + }
>> +
>> + /* Check if one of the geometry topology is unset */
>> + if (env->socket_id < 0) {
>> + /* Calculate default geometry topology attributes */
>> + env->socket_id = s390_std_socket(env->core_id, smp);
>> + env->book_id = s390_std_book(env->core_id, smp);
>> + env->drawer_id = s390_std_drawer(env->core_id, smp);
>> + }
>> +
>> + /*
>> + * Even the user can specify the entitlement as horizontal on the
>> + * command line, qemu will only use env->entitlement during vertical
>> + * polarization.
>> + * Medium entitlement is chosen as the default entitlement when the CPU
>> + * is not dedicated.
>> + * A dedicated CPU always receives a high entitlement.
>> + */
>> + if (env->entitlement >= S390_CPU_ENTITLEMENT__MAX ||
>> + env->entitlement == S390_CPU_ENTITLEMENT_HORIZONTAL) {
>> + if (env->dedicated) {
>> + env->entitlement = S390_CPU_ENTITLEMENT_HIGH;
>> + } else {
>> + env->entitlement = S390_CPU_ENTITLEMENT_MEDIUM;
>> + }
>> + }
> As you know, in my opinion there should be not possibility for the user
> to set the entitlement to horizontal and dedicated && != HIGH should be
> rejected as an error.
> If you do this, you can delete this.
In the next version with entitlement being an enum it is right.
However, deleting this means that the default value for entitlement
depends on dedication.
If we have only low, medium, high and default for entitlement is medium.
If the user specifies the dedication true without specifying entitlement
we could force entitlement to high.
But we can not distinguish this from the user specifying dedication true
with a medium entitlement, which is wrong.
So three solution:
1) We ignore what the user say if dedication is specified as true
2) We specify that both dedication and entitlement must be specified if
dedication is true
3) We set an impossible default to distinguish default from medium
entitlement
For me the solution 3 is the best one, it is more flexible for the user.
Solution 1 is obviously bad.
Solution 2 forces the user to specify entitlement high and only high if
it specifies dedication true.
AFAIU, you prefer the solution 2, forcing user to specify both
dedication and entitlement to suppress a default value in the enum.
Why is it bad to have a default value in the enum that we do not use to
specify that the value must be calculated?
>
>> +}
>> +
>> +/**
>> + * s390_topology_check:
>> + * @socket_id: socket to check
>> + * @book_id: book to check
>> + * @drawer_id: drawer to check
>> + * @entitlement: entitlement to check
>> + * @dedicated: dedication to check
>> + * @errp: Error pointer
>> + *
>> + * The function checks if the topology
>> + * attributes fits inside the system topology.
> fitS
>
> The function checks the validity of the provided topology arguments,
> namely that they're in bounds and non contradictory.
OK, thanks.
>
>> + */
>> +static void s390_topology_check(uint16_t socket_id, uint16_t book_id,
> I'd prefer if you stick to one id type. There defined as int32_t in env,
> here you use uint16_t and below int.
>
> In env, you want a signed type with sufficient range, int16_t should suffice there,
> but bigger is also fine.
> You don't want the user to pass a negative id, so by using an unsigned type you
> can avoid this without extra code.
> But IMO there should be one point where a type conversion occurs.
OK
>
>> + uint16_t drawer_id, uint16_t entitlement,
>> + bool dedicated, Error **errp)
>> +{
>> + CpuTopology *smp = s390_topology.smp;
>> + ERRP_GUARD();
>> +
>> + if (socket_id >= smp->sockets) {
>> + error_setg(errp, "Unavailable socket: %d", socket_id);
>> + return;
>> + }
>> + if (book_id >= smp->books) {
>> + error_setg(errp, "Unavailable book: %d", book_id);
>> + return;
>> + }
>> + if (drawer_id >= smp->drawers) {
>> + error_setg(errp, "Unavailable drawer: %d", drawer_id);
>> + return;
>> + }
>> + if (entitlement >= S390_CPU_ENTITLEMENT__MAX) {
>> + error_setg(errp, "Unknown entitlement: %d", entitlement);
>> + return;
>> + }
> I think you can delete this, too, there is no way that entitlement is > MAX.
With entitlement being an enum in CPU properties yes.
>
>> + if (dedicated && (entitlement == S390_CPU_ENTITLEMENT_LOW ||
>> + entitlement == S390_CPU_ENTITLEMENT_MEDIUM)) {
> Without HORIZONTAL you can do != HIGH and save one line, but that is
> cosmetic only.
Right, HORIZONTAL is eliminated during s390_topology_cpu_default()
Regards,
Pierre
next prev parent reply other threads:[~2023-04-21 10:21 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 16:28 [PATCH v19 00/21] s390x: CPU Topology Pierre Morel
2023-04-03 16:28 ` [PATCH v19 01/21] s390x/cpu topology: add s390 specifics to CPU topology Pierre Morel
2023-04-04 7:03 ` Cédric Le Goater
2023-04-04 12:26 ` Pierre Morel
2023-04-04 12:35 ` Cédric Le Goater
2023-04-04 14:04 ` Pierre Morel
2023-04-11 12:27 ` Nina Schoetterl-Glausch
2023-04-17 9:15 ` Pierre Morel
2023-04-18 15:57 ` Daniel P. Berrangé
2023-04-19 9:46 ` Pierre Morel
2023-04-18 8:53 ` Nina Schoetterl-Glausch
2023-04-18 10:01 ` Pierre Morel
2023-04-18 10:15 ` Thomas Huth
2023-04-18 12:28 ` Pierre Morel
2023-04-18 12:38 ` Nina Schoetterl-Glausch
2023-04-18 13:52 ` Pierre Morel
2023-04-18 14:58 ` Nina Schoetterl-Glausch
2023-04-03 16:28 ` [PATCH v19 02/21] s390x/cpu topology: add topology entries on CPU hotplug Pierre Morel
2023-04-04 7:31 ` Cédric Le Goater
2023-04-04 11:39 ` Pierre Morel
2023-04-19 17:15 ` Nina Schoetterl-Glausch
2023-04-20 8:59 ` Nina Schoetterl-Glausch
2023-04-21 10:20 ` Pierre Morel [this message]
2023-04-24 15:32 ` Nina Schoetterl-Glausch
2023-04-25 8:45 ` Pierre Morel
2023-04-25 9:27 ` Nina Schoetterl-Glausch
2023-04-25 11:24 ` Pierre Morel
2023-04-03 16:28 ` [PATCH v19 03/21] target/s390x/cpu topology: handle STSI(15) and build the SYSIB Pierre Morel
2023-04-03 16:28 ` [PATCH v19 04/21] s390x/sclp: reporting the maximum nested topology entries Pierre Morel
2023-04-03 16:28 ` [PATCH v19 05/21] s390x/cpu topology: resetting the Topology-Change-Report Pierre Morel
2023-04-03 16:28 ` [PATCH v19 06/21] s390x/cpu topology: interception of PTF instruction Pierre Morel
2023-04-04 7:41 ` Cédric Le Goater
2023-04-04 9:07 ` Pierre Morel
2023-04-03 16:28 ` [PATCH v19 07/21] target/s390x/cpu topology: activate CPU topology Pierre Morel
2023-04-03 16:28 ` [PATCH v19 08/21] qapi/s390x/cpu topology: set-cpu-topology qmp command Pierre Morel
2023-04-03 16:28 ` [PATCH v19 09/21] machine: adding s390 topology to query-cpu-fast Pierre Morel
2023-04-03 16:28 ` [PATCH v19 10/21] machine: adding s390 topology to info hotpluggable-cpus Pierre Morel
2023-04-03 16:28 ` [PATCH v19 11/21] qapi/s390x/cpu topology: CPU_POLARIZATION_CHANGE qapi event Pierre Morel
2023-04-03 16:28 ` [PATCH v19 12/21] qapi/s390x/cpu topology: query-cpu-polarization qmp command Pierre Morel
2023-04-03 16:28 ` [PATCH v19 13/21] docs/s390x/cpu topology: document s390x cpu topology Pierre Morel
2023-04-03 17:00 ` Cédric Le Goater
2023-04-03 17:21 ` Pierre Morel
2023-04-03 16:28 ` [PATCH v19 14/21] tests/avocado: s390x cpu topology core Pierre Morel
2023-04-04 9:21 ` Cédric Le Goater
2023-04-04 12:17 ` Cédric Le Goater
2023-04-25 15:03 ` Pierre Morel
2023-04-03 16:28 ` [PATCH v19 15/21] tests/avocado: s390x cpu topology polarisation Pierre Morel
2023-04-04 9:22 ` Cédric Le Goater
2023-04-04 12:26 ` Pierre Morel
2023-04-03 16:29 ` [PATCH v19 16/21] tests/avocado: s390x cpu topology entitlement tests Pierre Morel
2023-04-03 16:29 ` [PATCH v19 17/21] tests/avocado: s390x cpu topology test dedicated CPU Pierre Morel
2023-04-04 9:19 ` Cédric Le Goater
2023-04-04 12:02 ` Pierre Morel
2023-04-03 16:29 ` [PATCH v19 18/21] tests/avocado: s390x cpu topology test socket full Pierre Morel
2023-04-03 16:29 ` [PATCH v19 19/21] tests/avocado: s390x cpu topology dedicated errors Pierre Morel
2023-04-03 16:29 ` [PATCH v19 20/21] tests/avocado: s390x cpu topology bad move Pierre Morel
2023-04-03 16:29 ` [PATCH v19 21/21] tests/avocado: s390x cpu topology query-cpu-polarization 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=4ddd3177-58a8-c9f0-a9a8-ee71baf0511b@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=berrange@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=nsg@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).