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 v15 05/11] s390x/cpu topology: resetting the Topology-Change-Report
Date: Tue, 07 Feb 2023 11:50:43 +0100 [thread overview]
Message-ID: <669fea20042a31d009b5f3d9371bcf88f32d5d49.camel@linux.ibm.com> (raw)
In-Reply-To: <f4732cd4-67bb-a2a3-0048-3a2118b52fc1@linux.ibm.com>
On Tue, 2023-02-07 at 10:24 +0100, Pierre Morel wrote:
>
> On 2/6/23 18:52, Nina Schoetterl-Glausch wrote:
> > On Wed, 2023-02-01 at 14:20 +0100, Pierre Morel wrote:
> > > During a subsystem reset the Topology-Change-Report is cleared
> > > by the machine.
> > > Let's ask KVM to clear the Modified Topology Change Report (MTCR)
> > > bit of the SCA in the case of a subsystem reset.
> > >
> > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > > ---
> > > include/hw/s390x/cpu-topology.h | 1 +
> > > target/s390x/cpu.h | 1 +
> > > target/s390x/kvm/kvm_s390x.h | 1 +
> > > hw/s390x/cpu-topology.c | 12 ++++++++++++
> > > hw/s390x/s390-virtio-ccw.c | 3 +++
> > > target/s390x/cpu-sysemu.c | 13 +++++++++++++
> > > target/s390x/kvm/kvm.c | 17 +++++++++++++++++
> > > 7 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/hw/s390x/cpu-topology.h b/include/hw/s390x/cpu-topology.h
> > > index 1ae7e7c5e3..60e0b9fbfa 100644
> > > --- a/include/hw/s390x/cpu-topology.h
> > > +++ b/include/hw/s390x/cpu-topology.h
> > > @@ -66,5 +66,6 @@ static inline void s390_topology_set_cpu(MachineState *ms,
> > >
> > > extern S390Topology s390_topology;
> > > int s390_socket_nb(S390CPU *cpu);
> > > +void s390_topology_reset(void);
> > >
> > > #endif
> > > diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
> > > index e1f6925856..848314d2a9 100644
> > > --- a/target/s390x/cpu.h
> > > +++ b/target/s390x/cpu.h
> > > @@ -641,6 +641,7 @@ typedef struct SysIBTl_cpu {
> > > QEMU_BUILD_BUG_ON(sizeof(SysIBTl_cpu) != 16);
> > >
> > > void insert_stsi_15_1_x(S390CPU *cpu, int sel2, __u64 addr, uint8_t ar);
> > > +void s390_cpu_topology_reset(void);
> >
> > How about you call this s390_cpu_topology_reset_modified, so it's symmetric
> > with the function you define in the next patch. You could also drop the "cpu"
> > from the name.
>
> I am not sure about this, Thomas already gave his R-B on this patch so I
> prefer to stay on the original name, unless he says it is a good idea to
> change.
> Also in cpu-sysemu.c most of the function are tagged with _cpu_
IMO, renaming a function would be a small enough change to keep an R-b.
>
> >
> > Or maybe even better, you only define a function for setting the modified state,
> > but make it take a bool argument. This way you also get rid of some code duplication
> > and it wouldn't harm readability IMO.
>
> There is already a single function kvm_s390_topology_set_mtcr(attr) to
> set the "modified state"
Yes, but that is for KVM only and doesn't do error handling.
So you need at least one function on top of that. What I'm suggesting is to
only have one function instead of two because it gets rid of some code.
>
> >
> > >
> > > /* MMU defines */
> > > #define ASCE_ORIGIN (~0xfffULL) /* segment table origin */
> > > diff --git a/target/s390x/kvm/kvm_s390x.h b/target/s390x/kvm/kvm_s390x.h
> > > index f9785564d0..649dae5948 100644
> > > --- a/target/s390x/kvm/kvm_s390x.h
> > > +++ b/target/s390x/kvm/kvm_s390x.h
> > > @@ -47,5 +47,6 @@ void kvm_s390_crypto_reset(void);
> > > void kvm_s390_restart_interrupt(S390CPU *cpu);
> > > void kvm_s390_stop_interrupt(S390CPU *cpu);
> > > void kvm_s390_set_diag318(CPUState *cs, uint64_t diag318_info);
> > > +int kvm_s390_topology_set_mtcr(uint64_t attr);
> > >
> > > #endif /* KVM_S390X_H */
> > > diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
> > > index a80a1ebf22..cf63f3dd01 100644
> > > --- a/hw/s390x/cpu-topology.c
> > > +++ b/hw/s390x/cpu-topology.c
> > > @@ -85,6 +85,18 @@ static void s390_topology_init(MachineState *ms)
> > > QTAILQ_INSERT_HEAD(&s390_topology.list, entry, next);
> > > }
> > >
> > > +/**
> > > + * s390_topology_reset:
> > > + *
> > > + * Generic reset for CPU topology, calls s390_topology_reset()
> > > + * s390_topology_reset() to reset the kernel Modified Topology
> > > + * change record.
> > > + */
> > > +void s390_topology_reset(void)
> > > +{
> >
> > I'm wondering if you shouldn't move the reset changes you do in the next patch
> > into this one. I don't see what they have to do with PTF emulation.
>
> Here in this patch we do not intercept PTF and we have only an
> horizontal polarity.
> So we do not need to reset the polarity for all the vCPUs, we only need
> it when we have vertical polarity.
Well, with the PTF patch you don't get vertical polarity either, because you
only enable the topology with patch 7.
And since it's about resetting, it fits better in this patch IMO.
>
> Regards,
> Pierre
>
next prev parent reply other threads:[~2023-02-07 10:52 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 13:20 [PATCH v15 00/11] s390x: CPU Topology Pierre Morel
2023-02-01 13:20 ` [PATCH v15 01/11] s390x/cpu topology: adding s390 specificities to CPU topology Pierre Morel
2023-02-02 10:44 ` Thomas Huth
2023-02-02 13:15 ` Pierre Morel
2023-02-02 16:05 ` Nina Schoetterl-Glausch
2023-02-03 9:39 ` Pierre Morel
2023-02-03 11:21 ` Thomas Huth
2023-02-08 17:50 ` Nina Schoetterl-Glausch
2023-02-10 14:19 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 02/11] s390x/cpu topology: add topology entries on CPU hotplug Pierre Morel
2023-02-02 16:42 ` Nina Schoetterl-Glausch
2023-02-03 9:21 ` Pierre Morel
2023-02-03 13:22 ` Nina Schoetterl-Glausch
2023-02-03 14:40 ` Pierre Morel
2023-02-03 15:38 ` Nina Schoetterl-Glausch
2023-02-01 13:20 ` [PATCH v15 03/11] target/s390x/cpu topology: handle STSI(15) and build the SYSIB Pierre Morel
2023-02-03 17:36 ` Nina Schoetterl-Glausch
2023-02-06 10:06 ` Pierre Morel
2023-02-06 10:32 ` Nina Schoetterl-Glausch
2023-02-06 11:24 ` Thomas Huth
2023-02-06 12:57 ` Pierre Morel
2023-02-09 16:39 ` Nina Schoetterl-Glausch
2023-02-10 14:16 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 04/11] s390x/sclp: reporting the maximum nested topology entries Pierre Morel
2023-02-06 10:13 ` Thomas Huth
2023-02-06 10:19 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 05/11] s390x/cpu topology: resetting the Topology-Change-Report Pierre Morel
2023-02-06 11:05 ` Thomas Huth
2023-02-06 12:50 ` Pierre Morel
2023-02-06 17:52 ` Nina Schoetterl-Glausch
2023-02-07 9:24 ` Pierre Morel
2023-02-07 10:50 ` Nina Schoetterl-Glausch [this message]
2023-02-07 12:19 ` Pierre Morel
2023-02-07 13:37 ` Nina Schoetterl-Glausch
2023-02-07 14:08 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 06/11] s390x/cpu topology: interception of PTF instruction Pierre Morel
2023-02-06 11:38 ` Thomas Huth
2023-02-06 13:02 ` Pierre Morel
2023-02-06 18:34 ` Nina Schoetterl-Glausch
2023-02-07 9:59 ` Pierre Morel
2023-02-07 11:27 ` Nina Schoetterl-Glausch
2023-02-07 13:03 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 07/11] target/s390x/cpu topology: activating CPU topology Pierre Morel
2023-02-06 11:57 ` Thomas Huth
2023-02-06 13:19 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 08/11] qapi/s390x/cpu topology: x-set-cpu-topology monitor command Pierre Morel
2023-02-06 12:21 ` Thomas Huth
2023-02-06 14:03 ` Pierre Morel
2023-02-07 14:59 ` Pierre Morel
2023-02-08 18:40 ` Nina Schoetterl-Glausch
2023-02-09 13:14 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 09/11] machine: adding s390 topology to query-cpu-fast Pierre Morel
2023-02-06 12:38 ` Thomas Huth
2023-02-06 14:12 ` Pierre Morel
2023-02-06 12:41 ` Thomas Huth
2023-02-06 12:49 ` Daniel P. Berrangé
2023-02-06 13:09 ` Thomas Huth
2023-02-06 14:50 ` Daniel P. Berrangé
2023-02-07 10:10 ` Thomas Huth
2023-02-06 14:16 ` Pierre Morel
2023-02-07 18:26 ` Nina Schoetterl-Glausch
2023-02-08 9:11 ` Pierre Morel
2023-02-01 13:20 ` [PATCH v15 10/11] qapi/s390x/cpu topology: CPU_POLARITY_CHANGE qapi event Pierre Morel
2023-02-08 17:35 ` Nina Schoetterl-Glausch
2023-02-09 10:04 ` Daniel P. Berrangé
2023-02-09 11:01 ` Markus Armbruster
2023-02-09 12:12 ` Nina Schoetterl-Glausch
2023-02-09 12:15 ` Daniel P. Berrangé
[not found] ` <87y1p8q7v6.fsf@pond.sub.org>
2023-02-09 12:28 ` Nina Schoetterl-Glausch
2023-02-09 13:00 ` Pierre Morel
2023-02-09 14:50 ` Nina Schoetterl-Glausch
2023-02-01 13:20 ` [PATCH v15 11/11] docs/s390x/cpu topology: document s390x cpu topology Pierre Morel
2023-02-08 16:22 ` Nina Schoetterl-Glausch
2023-02-09 17:14 ` [PATCH v15 00/11] s390x: CPU Topology Nina Schoetterl-Glausch
2023-02-10 13:23 ` 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=669fea20042a31d009b5f3d9371bcf88f32d5d49.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).