From: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
Eduardo Habkost <eduardo@habkost.net>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
Richard Henderson <richard.henderson@linaro.org>,
David Hildenbrand <david@redhat.com>,
Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Michael Roth <michael.roth@amd.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Ilya Leoshkevich" <iii@linux.ibm.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Pierre Morel" <pmorel@linux.ibm.com>
Subject: Re: [PATCH v22 03/20] target/s390x/cpu topology: handle STSI(15) and build the SYSIB
Date: Wed, 06 Sep 2023 14:12:03 +0200 [thread overview]
Message-ID: <f2c78c58b5eb7ce4f4e93534d09b9ef1f1889da5.camel@linux.ibm.com> (raw)
In-Reply-To: <eb7a0ed0-250e-c4cd-f862-5f5dd3c7fc13@redhat.com>
On Wed, 2023-09-06 at 10:21 +0200, Thomas Huth wrote:
> On 05/09/2023 17.25, Nina Schoetterl-Glausch wrote:
> > On Tue, 2023-09-05 at 15:26 +0200, Thomas Huth wrote:
> > > On 01/09/2023 17.57, Nina Schoetterl-Glausch wrote:
> > > > From: Pierre Morel <pmorel@linux.ibm.com>
> > > >
> > > > On interception of STSI(15.1.x) the System Information Block
> > > > (SYSIB) is built from the list of pre-ordered topology entries.
> > > >
> > > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > > > Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> > > > Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> > > > ---
> ...
> > > > +/**
> > > > + * s390_topology_fill_list_sorted:
> > > > + *
> > > > + * Loop over all CPU and insert it at the right place
> > > > + * inside the TLE entry list.
> > > > + * Fill the S390Topology list with entries according to the order
> > > > + * specified by the PoP.
> > > > + */
> > > > +static void s390_topology_fill_list_sorted(S390TopologyList *topology_list)
> > > > +{
> > > > + CPUState *cs;
> > > > + S390TopologyEntry sentinel;
> > > > +
> > > > + QTAILQ_INIT(topology_list);
> > > > +
> > > > + sentinel.id.id = cpu_to_be64(UINT64_MAX);
>
> Since you don't do swapping for entry->id.id below, why do you do it here?
Because an integer in cpu endianess is converted to the big endian
storage format. So then there is a cpu -> big -> cpu round trip with
the comparison below and the value is the max.
Of course this is entirely cosmetic, since UINT64_MAX is all ones.
> > > > + QTAILQ_INSERT_HEAD(topology_list, &sentinel, next);
> > > > +
> > > > + CPU_FOREACH(cs) {
> > > > + s390_topology_id id = s390_topology_from_cpu(S390_CPU(cs));
> > > > + S390TopologyEntry *entry, *tmp;
> > > > +
> > > > + QTAILQ_FOREACH(tmp, topology_list, next) {
> > > > + if (id.id == tmp->id.id) {
> > > > + entry = tmp;
> > > > + break;
> >
> > I think I'll add a comment here.
> >
> > /*
> > * Earlier bytes have higher order -> big endian.
> > * E.g. an entry with higher drawer number should be later in the list,
> > * no matter the later fields (book, socket, etc)
> > */
>
> Ugh, so this swapping is not due to real endianness issues, but just due to
Yeah.
> ordering? ... that's very ugly! I'd prefer to be more verbose and compare
I kinda didn't like the verbosity of it, since I then need to copy
paste the whole thing because I also need an equality check.
I considered implementing <=, then a == b as a <= b && b <= a, which
seems fine on second thought, so I'll do that.
And maybe help the compiler by putting __attribute__((pure)) on there.
> book by book, drawer by drawer, etc. instread. Or is this function that
> performance critical that we must save every possible CPU cycle here?
No.
>
> Thomas
>
>
> >
> > > > + } else if (be64_to_cpu(id.id) < be64_to_cpu(tmp->id.id)) {
> > > > + entry = g_malloc0(sizeof(*entry));
> > >
> > > Maybe nicer to use g_new0 here instead?
> >
> > I don't think it makes much of a difference.
> >
> > >
> > > > + entry->id.id = id.id;
> > >
> > > Should this get a cpu_to_be64() ?
> >
> > No, there is no interpretation of the value here, just a copy.
> > >
> > > > + QTAILQ_INSERT_BEFORE(tmp, entry, next);
> > > > + break;
> > > > + }
> > > > + }
> > > > + s390_topology_add_cpu_to_entry(entry, S390_CPU(cs));
> > > > + }
> > > > +
> > > > + QTAILQ_REMOVE(topology_list, &sentinel, next);
> > > > +}
> > >
> > > Thomas
> > >
> > >
> >
>
next prev parent reply other threads:[~2023-09-06 12:13 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 15:57 [PATCH v22 00/20] s390x: CPU Topology Nina Schoetterl-Glausch
2023-09-01 15:57 ` [PATCH v22 01/20] CPU topology: extend with s390 specifics Nina Schoetterl-Glausch
2023-09-05 9:01 ` Thomas Huth
2023-09-01 15:57 ` [PATCH v22 02/20] s390x/cpu topology: add topology entries on CPU hotplug Nina Schoetterl-Glausch
2023-09-05 12:28 ` Thomas Huth
2023-09-01 15:57 ` [PATCH v22 03/20] target/s390x/cpu topology: handle STSI(15) and build the SYSIB Nina Schoetterl-Glausch
2023-09-04 18:23 ` Nina Schoetterl-Glausch
2023-09-05 13:26 ` Thomas Huth
2023-09-05 15:25 ` Nina Schoetterl-Glausch
2023-09-06 8:21 ` Thomas Huth
2023-09-06 12:12 ` Nina Schoetterl-Glausch [this message]
2023-09-06 14:53 ` Cédric Le Goater
2023-09-01 15:57 ` [PATCH v22 04/20] s390x/sclp: reporting the maximum nested topology entries Nina Schoetterl-Glausch
2023-09-01 15:57 ` [PATCH v22 05/20] s390x/cpu topology: resetting the Topology-Change-Report Nina Schoetterl-Glausch
2023-09-01 15:57 ` [PATCH v22 06/20] s390x/cpu topology: interception of PTF instruction Nina Schoetterl-Glausch
2023-09-01 15:57 ` [PATCH v22 07/20] target/s390x/cpu topology: activate CPU topology Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 08/20] qapi/s390x/cpu topology: set-cpu-topology qmp command Nina Schoetterl-Glausch
2023-09-06 8:56 ` Thomas Huth
2023-09-01 15:58 ` [PATCH v22 09/20] machine: adding s390 topology to query-cpu-fast Nina Schoetterl-Glausch
2023-09-06 9:10 ` Thomas Huth
2023-09-01 15:58 ` [PATCH v22 10/20] machine: adding s390 topology to info hotpluggable-cpus Nina Schoetterl-Glausch
2023-09-06 9:14 ` Thomas Huth
2023-09-01 15:58 ` [PATCH v22 11/20] qapi/s390x/cpu topology: CPU_POLARIZATION_CHANGE qapi event Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 12/20] qapi/s390x/cpu topology: query-cpu-polarization qmp command Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 13/20] docs/s390x/cpu topology: document s390x cpu topology Nina Schoetterl-Glausch
2023-09-07 8:15 ` Thomas Huth
2023-09-01 15:58 ` [PATCH v22 14/20] tests/avocado: s390x cpu topology core Nina Schoetterl-Glausch
2023-09-04 18:44 ` Nina Schoetterl-Glausch
2023-09-07 8:27 ` Thomas Huth
2023-09-08 14:27 ` Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 15/20] tests/avocado: s390x cpu topology polarization Nina Schoetterl-Glausch
2023-09-04 19:43 ` Nina Schoetterl-Glausch
2023-09-07 9:02 ` Thomas Huth
2023-09-08 14:47 ` Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 16/20] tests/avocado: s390x cpu topology entitlement tests Nina Schoetterl-Glausch
2023-09-04 19:51 ` Nina Schoetterl-Glausch
2023-09-07 9:05 ` Thomas Huth
2023-09-08 18:30 ` Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 17/20] tests/avocado: s390x cpu topology test dedicated CPU Nina Schoetterl-Glausch
2023-09-04 19:54 ` Nina Schoetterl-Glausch
2023-09-07 10:08 ` Thomas Huth
2023-09-01 15:58 ` [PATCH v22 18/20] tests/avocado: s390x cpu topology test socket full Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 19/20] tests/avocado: s390x cpu topology dedicated errors Nina Schoetterl-Glausch
2023-09-01 15:58 ` [PATCH v22 20/20] tests/avocado: s390x cpu topology bad move Nina Schoetterl-Glausch
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=f2c78c58b5eb7ce4f4e93534d09b9ef1f1889da5.camel@linux.ibm.com \
--to=nsg@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=bleal@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=crosa@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=michael.roth@amd.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=wangyanan55@huawei.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).