linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nico Boehr <nrb@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: frankja@linux.ibm.com, thuth@redhat.com, kvm@vger.kernel.org,
	imbrenda@linux.ibm.com, david@redhat.com, nsg@linux.ibm.com
Subject: Re: [kvm-unit-tests PATCH v7 2/2] s390x: topology: Checking Configuration Topology Information
Date: Tue, 28 Mar 2023 08:25:16 +0200	[thread overview]
Message-ID: <167998471655.28355.8845167343467425829@t14-nrb> (raw)
In-Reply-To: <eed972f5-7d94-4db3-c496-60f7d37db0f3@linux.ibm.com>

Quoting Pierre Morel (2023-03-27 14:38:35)
> > [...]
> >> diff --git a/s390x/topology.c b/s390x/topology.c
> >> index ce248f1..11ce931 100644
> >> --- a/s390x/topology.c
> >> +++ b/s390x/topology.c
> > [...]
> >> +/*
> >> + * Topology level as defined by architecture, all levels exists with
> >> + * a single container unless overwritten by the QEMU -smp parameter.
> >> + */
> >> +static int arch_topo_lvl[CPU_TOPOLOGY_MAX_LEVEL]; // = {1, 1, 1, 1, 1, 1};
> > So that's what is being provided to the test on the command line, right?
> >
> > How about renaming this to expected_topo_lvl?
> >
> > What do you mean by 'defined by architecture'?
> 
> This is what is provided by the boot arguments and should correspond to 
> the physical topology.
> 
> The test checks that this is corresponding to what LPAR or QEMU shows in 
> the SYSIB.

Yep, OK. Makes sense.

> If a topology level always exist physically and if it is not specified 
> on the QEMU command line it is implicitly unique.

What do you mean by 'implicitly unique'?

> OK for expected_topo_lvl if you prefer.

Yes, please.

> > [...]
> >> +/*
> >> + * stsi_check_mag
> >> + * @info: Pointer to the stsi information
> >> + *
> >> + * MAG field should match the architecture defined containers
> >> + * when MNEST as returned by SCLP matches MNEST of the SYSIB.
> >> + */
> >> +static void stsi_check_mag(struct sysinfo_15_1_x *info)
> >> +{
> >> +       int i;
> >> +
> >> +       report_prefix_push("MAG");
> >> +
> >> +       stsi_check_maxcpus(info);
> >> +
> >> +       /* Explicitly skip the test if both mnest do not match */
> >> +       if (max_nested_lvl != info->mnest)
> >> +               goto done;
> > What does it mean if the two don't match, i.e. is this an error? Or a skip? Or is it just expected?
> 
> I have no information on the representation of the MAG fields for a 
> SYSIB with a nested level different than the maximum nested level.
> 
> There are examples in the documentation but I did not find, and did not 
> get a clear answer, on how the MAG field are calculated.
> 
> The examples seems clear for info->mnest between MNEST -1 and 3 but the 
> explication I had on info->mnest = 2 is not to be found in any 
> documentation.
> 
> Until it is specified in a documentation I skip all these tests.

Alright - then please:
- update the comment to say:
  "It is not clear how the MAG fields are calculated when mnest in the SYSIB 15.x is different from the maximum nested level in the SCLP info, so we skip here for now."
- when this is the case, do a report_skip() and show info->mnest and max_nested_lvl in the message.

  reply	other threads:[~2023-03-28  6:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  8:56 [kvm-unit-tests PATCH v7 0/2] S390x: CPU Topology Information Pierre Morel
2023-03-20  8:56 ` [kvm-unit-tests PATCH v7 1/2] s390x: topology: Check the Perform Topology Function Pierre Morel
2023-03-23 15:45   ` Claudio Imbrenda
2023-03-27 11:45     ` Pierre Morel
2023-03-24 10:11   ` Nico Boehr
2023-03-27 11:48     ` Pierre Morel
2023-03-20  8:56 ` [kvm-unit-tests PATCH v7 2/2] s390x: topology: Checking Configuration Topology Information Pierre Morel
2023-03-24 10:59   ` Nico Boehr
2023-03-27 12:38     ` Pierre Morel
2023-03-28  6:25       ` Nico Boehr [this message]
2023-03-28 11:37         ` Pierre Morel
2023-03-28 12:44           ` Nico Boehr
2023-03-27 17:02     ` 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=167998471655.28355.8845167343467425829@t14-nrb \
    --to=nrb@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=nsg@linux.ibm.com \
    --cc=pmorel@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).