From: Nina Schoetterl-Glausch <nsg@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, berrange@redhat.com,
clg@kaod.org
Subject: Re: [PATCH v14 02/11] s390x/cpu topology: add topology entries on CPU hotplug
Date: Tue, 17 Jan 2023 17:48:52 +0100 [thread overview]
Message-ID: <13ad4df8bc83f552ae1c9aad4f1a44d18963e7a8.camel@linux.ibm.com> (raw)
In-Reply-To: <8063592a-971a-d029-e8ac-0fb6286199d5@linux.ibm.com>
On Tue, 2023-01-17 at 14:55 +0100, Pierre Morel wrote:
>
> On 1/13/23 19:15, Nina Schoetterl-Glausch wrote:
> >
[...]
> > > +/**
> > > + * s390_topology_set_entry:
> > > + * @entry: Topology entry to setup
> > > + * @id: topology id to use for the setup
> > > + *
> > > + * Set the core bit inside the topology mask and
> > > + * increments the number of cores for the socket.
> > > + */
> > > +static void s390_topology_set_entry(S390TopologyEntry *entry,
> >
> > Not sure if I like the name, what it does is to add a cpu to the entry.
>
> s390_topology_add_cpu_to_entry() ?
Yeah, that's better.
[...]
>
> > > +/**
> > > + * s390_topology_set_cpu:
> > > + * @ms: MachineState used to initialize the topology structure on
> > > + * first call.
> > > + * @cpu: the new S390CPU to insert in the topology structure
> > > + * @errp: the error pointer
> > > + *
> > > + * Called from CPU Hotplug to check and setup the CPU attributes
> > > + * before to insert the CPU in the topology.
> > > + */
> > > +void s390_topology_set_cpu(MachineState *ms, S390CPU *cpu, Error **errp)
> > > +{
> > > + Error *local_error = NULL;
> >
> > Can't you just use ERRP_GUARD ?
>
> I do not think it is necessary and I find it obfuscating.
> So, should I?
/*
* Propagate error object (if any) from @local_err to @dst_errp.
[...]
* Please use ERRP_GUARD() instead when possible.
* Please don't error_propagate(&error_fatal, ...), use
* error_report_err() and exit(), because that's more obvious.
*/
void error_propagate(Error **dst_errp, Error *local_err);
So I'd say yes.
>
> >
> > > + s390_topology_id id;
> > > +
> > > + /*
> > > + * We do not want to initialize the topology if the cpu model
> > > + * does not support topology consequently, we have to wait for
> >
> > ", consequently," I think. Could you do the initialization some where else,
> > after you know what the cpu model is? Not that I object to doing it this way.
> >
>
> I did not find a better place, it must be done after the CPU model is
> initialize and before the first CPU is created.
> The cpu model is initialized during the early creation of the first cpu.
>
> Any idea?
>
> Thanks.
>
> Regards,
> Pierre
>
next prev parent reply other threads:[~2023-01-17 16:49 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 14:53 [PATCH v14 00/11] s390x: CPU Topology Pierre Morel
2023-01-05 14:53 ` [PATCH v14 01/11] s390x/cpu topology: adding s390 specificities to CPU topology Pierre Morel
2023-01-10 11:37 ` Thomas Huth
2023-01-16 16:32 ` Pierre Morel
2023-01-17 7:25 ` Thomas Huth
2023-01-13 16:58 ` Nina Schoetterl-Glausch
2023-01-16 17:28 ` Pierre Morel
2023-01-16 20:34 ` Nina Schoetterl-Glausch
2023-01-17 9:49 ` Pierre Morel
2023-01-17 7:22 ` Thomas Huth
2023-01-05 14:53 ` [PATCH v14 02/11] s390x/cpu topology: add topology entries on CPU hotplug Pierre Morel
2023-01-10 13:00 ` Thomas Huth
2023-01-11 9:23 ` Nina Schoetterl-Glausch
2023-01-16 18:24 ` Pierre Morel
2023-01-13 18:15 ` Nina Schoetterl-Glausch
2023-01-17 13:55 ` Pierre Morel
2023-01-17 16:48 ` Nina Schoetterl-Glausch [this message]
2023-01-19 13:34 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 03/11] target/s390x/cpu topology: handle STSI(15) and build the SYSIB Pierre Morel
2023-01-10 14:29 ` Thomas Huth
2023-01-11 9:16 ` Thomas Huth
2023-01-11 17:14 ` Nina Schoetterl-Glausch
2023-01-17 16:58 ` Pierre Morel
2023-01-17 16:56 ` Pierre Morel
2023-01-18 10:26 ` Thomas Huth
2023-01-18 11:54 ` Nina Schoetterl-Glausch
2023-01-19 13:12 ` Pierre Morel
2023-01-16 13:11 ` Nina Schoetterl-Glausch
2023-01-16 15:39 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 04/11] s390x/sclp: reporting the maximum nested topology entries Pierre Morel
2023-01-11 8:57 ` Thomas Huth
2023-01-17 17:36 ` Pierre Morel
2023-01-17 19:58 ` Nina Schoetterl-Glausch
2023-01-19 13:08 ` Pierre Morel
2023-01-11 17:52 ` Nina Schoetterl-Glausch
2023-01-17 17:44 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 05/11] s390x/cpu topology: resetting the Topology-Change-Report Pierre Morel
2023-01-11 9:00 ` Thomas Huth
2023-01-17 17:57 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 06/11] s390x/cpu topology: interception of PTF instruction Pierre Morel
2023-01-16 18:24 ` Nina Schoetterl-Glausch
2023-01-18 9:54 ` Pierre Morel
2023-01-20 14:32 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 07/11] target/s390x/cpu topology: activating CPU topology Pierre Morel
2023-01-11 10:04 ` Thomas Huth
2023-01-18 10:01 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 08/11] qapi/s390/cpu topology: change-topology monitor command Pierre Morel
2023-01-11 10:09 ` Thomas Huth
2023-01-12 8:00 ` Thomas Huth
2023-01-18 14:23 ` Pierre Morel
2023-01-12 12:03 ` Daniel P. Berrangé
2023-01-18 13:17 ` Pierre Morel
2023-01-16 21:09 ` Nina Schoetterl-Glausch
2023-01-17 7:30 ` Thomas Huth
2023-01-17 13:31 ` Nina Schoetterl-Glausch
2023-01-18 10:53 ` Thomas Huth
2023-01-18 14:09 ` Pierre Morel
2023-01-18 15:17 ` Kevin Wolf
2023-01-18 15:48 ` Pierre Morel
2023-01-18 14:06 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 09/11] qapi/s390/cpu topology: monitor query topology information Pierre Morel
2023-01-12 11:48 ` Thomas Huth
2023-01-18 15:59 ` Pierre Morel
2023-01-12 12:10 ` Daniel P. Berrangé
2023-01-12 17:27 ` Nina Schoetterl-Glausch
2023-01-12 17:30 ` Daniel P. Berrangé
2023-01-18 15:58 ` Pierre Morel
2023-01-18 16:08 ` Daniel P. Berrangé
2023-01-18 16:57 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 10/11] qapi/s390/cpu topology: POLARITY_CHANGE qapi event Pierre Morel
2023-01-12 11:52 ` Thomas Huth
2023-01-18 17:09 ` Pierre Morel
2023-01-20 11:56 ` Thomas Huth
2023-01-20 14:22 ` Pierre Morel
2023-01-05 14:53 ` [PATCH v14 11/11] docs/s390x/cpu topology: document s390x cpu topology Pierre Morel
2023-01-12 11:46 ` Thomas Huth
2023-01-19 14:48 ` Pierre Morel
2023-01-12 11:58 ` Daniel P. Berrangé
2023-01-18 17:10 ` 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=13ad4df8bc83f552ae1c9aad4f1a44d18963e7a8.camel@linux.ibm.com \
--to=nsg@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=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).