All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Nina Schoetterl-Glausch <nsg@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: Thu, 19 Jan 2023 14:08:19 +0100	[thread overview]
Message-ID: <e4527b0e-fd4e-7caa-f4ce-9b254b1e2801@linux.ibm.com> (raw)
In-Reply-To: <0103e627a835013e00a9c55d46348e76b94366e9.camel@linux.ibm.com>



On 1/17/23 20:58, Nina Schoetterl-Glausch wrote:
> 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.

Yes.
Only the commit message is confusing, it is to be set on 4 in this patch.

I change the commit message to:

---
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 change the MNEST value from 2 to 4 in the SCLP READ INFO
structure now that we support books and drawers.
---

is it OK ?

Regards,
Pierre

> 
>>
>> 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
>>
> 

-- 
Pierre Morel
IBM Lab Boeblingen

  reply	other threads:[~2023-01-19 13:10 UTC|newest]

Thread overview: 80+ 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
2023-01-19 13:08         ` Pierre Morel [this message]
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-05 14:53   ` 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=e4527b0e-fd4e-7caa-f4ce-9b254b1e2801@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.