Re: [kvm-unit-tests PATCH v7 2/2] s390x: topology: Checking Configuration Topology Information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux