On Thu, 3 Feb 2022 09:45:56 +0100 Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > On 1/28/22 19:54, Claudio Imbrenda wrote: > > On s390x there are no guarantees about the CPU addresses, except that > > they shall be unique. This means that in some environments, it's > > possible that there is no match between the CPU address and its > > position (index) in the list of available CPUs returned by the system. > > While I support this patch set I've yet to find an environment where > this gave me headaches. > > > > > This series fixes a small bug in the SMP initialization code, adds a > > guarantee that the boot CPU will always have index 0, and introduces > > some functions to allow tests to use CPU indexes instead of using > > hardcoded CPU addresses. This will allow the tests to run successfully > > in more environments (e.g. z/VM, LPAR). > > I'm wondering if we should do it the other way round and make the smp_* > functions take a idx instead of a cpu addr. The only instance where this > gets a bit ugly is the sigp calls which we would also need to convert. yes, in fact this is something I was already planning to do :) for sigp, we can either convert, or add a wrapper with idx. > > > Some existing tests are adapted to take advantage of the new > > functionalities. > > > > Claudio Imbrenda (5): > > lib: s390x: smp: add functions to work with CPU indexes > > lib: s390x: smp: guarantee that boot CPU has index 0 > > s390x: smp: avoid hardcoded CPU addresses > > s390x: firq: avoid hardcoded CPU addresses > > s390x: skrf: avoid hardcoded CPU addresses > > > > lib/s390x/smp.h | 2 ++ > > lib/s390x/smp.c | 28 ++++++++++++----- > > s390x/firq.c | 17 +++++----- > > s390x/skrf.c | 8 +++-- > > s390x/smp.c | 83 ++++++++++++++++++++++++++----------------------- > > 5 files changed, 79 insertions(+), 59 deletions(-) > > >
