public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>,
	Thomas Huth <thuth@redhat.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, 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 04/11] s390x/sclp: reporting the maximum nested topology entries
Date: Tue, 17 Jan 2023 20:58:15 +0100	[thread overview]
Message-ID: <0103e627a835013e00a9c55d46348e76b94366e9.camel@linux.ibm.com> (raw)
In-Reply-To: <22aff83d-4379-e4f0-9826-33f986ddeec7@linux.ibm.com>

On Tue, 2023-01-17 at 18:36 +0100, Pierre Morel wrote:
> 
> On 1/11/23 09:57, Thomas Huth wrote:
> > On 05/01/2023 15.53, Pierre Morel wrote:
> > > The maximum nested topology entries is used by the guest to know
> > > how many nested topology are available on the machine.
> > > 
> > > Currently, SCLP READ SCP INFO reports MNEST = 0, which is the
> > > equivalent of reporting the default value of 2.
> > > Let's use the default SCLP value of 2 and increase this value in the
> > > future patches implementing higher levels.
> > 
> > I'm confused ... so does a SCLP value of 2 mean a MNEST level of 4 ?
> 
> Sorry, I forgot to change this.
> MNEST = 0 means no MNEST support and only socket is supported so it is 
> like MNEST = 2.
> MNEST != 0 set the maximum nested level and correct values may be 2,3 or 4.
> But this setting to 4 should already have been done in previous patch 
> where we introduced the books and drawers.

I think setting it to 4 here is fine/preferable, since 2 is the default unless
you tell the guest that more are available, which you do in this patch.
It's only the commit description that is confusing.

> 
> I change the commit message with:
> ---
> s390x/sclp: reporting the maximum nested topology entries
> 
> The maximum nested topology entries is used by the guest to know
> how many nested topology are available on the machine.
> 
> Let's return this information to the guest.
> ---
> 
> > 
> > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > > ---
> > >   include/hw/s390x/sclp.h | 5 +++--
> > >   hw/s390x/sclp.c         | 4 ++++
> > >   2 files changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
> > > index 712fd68123..4ce852473c 100644
> > > --- a/include/hw/s390x/sclp.h
> > > +++ b/include/hw/s390x/sclp.h
> > > @@ -112,12 +112,13 @@ typedef struct CPUEntry {
> > >   } QEMU_PACKED CPUEntry;
> > >   #define SCLP_READ_SCP_INFO_FIXED_CPU_OFFSET     128
> > > -#define SCLP_READ_SCP_INFO_MNEST                2
> > > +#define SCLP_READ_SCP_INFO_MNEST                4
> > 
> > ... since you update it to 4 here.
> 
> Yes, in fact this should be set in the previous patch already to 4.
> So I will do that.
> 
> > 
> > >   typedef struct ReadInfo {
> > >       SCCBHeader h;
> > >       uint16_t rnmax;
> > >       uint8_t rnsize;
> > > -    uint8_t  _reserved1[16 - 11];       /* 11-15 */
> > > +    uint8_t  _reserved1[15 - 11];       /* 11-14 */
> > > +    uint8_t  stsi_parm;                 /* 15-16 */
> > >       uint16_t entries_cpu;               /* 16-17 */
> > >       uint16_t offset_cpu;                /* 18-19 */
> > >       uint8_t  _reserved2[24 - 20];       /* 20-23 */
> > > diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
> > > index eff74479f4..07e3cb4cac 100644
> > > --- a/hw/s390x/sclp.c
> > > +++ b/hw/s390x/sclp.c
> > > @@ -20,6 +20,7 @@
> > >   #include "hw/s390x/event-facility.h"
> > >   #include "hw/s390x/s390-pci-bus.h"
> > >   #include "hw/s390x/ipl.h"
> > > +#include "hw/s390x/cpu-topology.h"
> > >   static inline SCLPDevice *get_sclp_device(void)
> > >   {
> > > @@ -125,6 +126,9 @@ static void read_SCP_info(SCLPDevice *sclp, SCCB 
> > > *sccb)
> > >       /* CPU information */
> > >       prepare_cpu_entries(machine, entries_start, &cpu_count);
> > > +    if (s390_has_topology()) {
> > > +        read_info->stsi_parm = SCLP_READ_SCP_INFO_MNEST;
> > 
> > This seems to be in contradiction to what you've said in the commit 
> > description - you set it to 4 and not to 2.
> 
> Yes, I change the commit message.
> 
> Thanks.
> 
> Regards,
> Pierre
> 


  reply	other threads:[~2023-01-17 21:38 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
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 [this message]
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=0103e627a835013e00a9c55d46348e76b94366e9.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