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: Fri, 24 Mar 2023 11:59:11 +0100 [thread overview]
Message-ID: <167965555147.41638.10047922188597254104@t14-nrb> (raw)
In-Reply-To: <20230320085642.12251-3-pmorel@linux.ibm.com>
Quoting Pierre Morel (2023-03-20 09:56:42)
> STSI with function code 15 is used to store the CPU configuration
> topology.
>
> We retrieve the maximum nested level with SCLP and use the
> topology tree provided by the drawers, books, sockets, cores
> arguments.
>
> We check :
> - if the topology stored is coherent between the QEMU -smp
> parameters and kernel parameters.
> - the number of CPUs
> - the maximum number of CPUs
> - the number of containers of each levels for every STSI(15.1.x)
> instruction allowed by the machine.
[...]
> diff --git a/lib/s390x/sclp.c b/lib/s390x/sclp.c
> index 390fde7..9679332 100644
> --- a/lib/s390x/sclp.c
> +++ b/lib/s390x/sclp.c
> @@ -238,3 +238,8 @@ uint64_t get_max_ram_size(void)
> {
> return max_ram_size;
> }
> +
> +uint64_t sclp_get_stsi_mnest(void)
> +{
maybe add:
assert(read_info);
[...]
> 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'?
[...]
> +/*
> + * 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?
[...]
> +/**
> + * check_tle:
> + * @tc: pointer to first TLE
> + *
> + * Recursively check the containers TLEs until we
> + * find a CPU TLE.
> + */
> +static uint8_t *check_tle(void *tc)
> +{
[...]
> + report(!cpus->d || (cpus->pp == 3 || cpus->pp == 0),
> + "Dedication versus entitlement");
Maybe skip here if the CPU is not dedicated? With shared CPUs we really can't check much here.
[...]
> +/*
> + * The Maximum Nested level is given by SCLP READ_SCP_INFO if the MNEST facility
> + * is available.
> + * If the MNEST facility is not available, sclp_get_stsi_mnest returns 0 and the
> + * Maximum Nested level is 2
> + */
> +#define S390_DEFAULT_MNEST 2
> +static int sclp_get_mnest(void)
> +{
> + return sclp_get_stsi_mnest() ?: S390_DEFAULT_MNEST;
> +}
> +
> +static int arch_max_cpus(void)
If arch_topo_lvl is renamed, also rename this function accordingly.
> static struct {
> const char *name;
> void (*func)(void);
> } tests[] = {
> { "PTF", test_ptf},
> + { "STSI", test_stsi},
missing space ^
next prev parent reply other threads:[~2023-03-24 10:59 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 [this message]
2023-03-27 12:38 ` Pierre Morel
2023-03-28 6:25 ` Nico Boehr
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=167965555147.41638.10047922188597254104@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).