diff options
| author | Heiko Carstens <heiko.carstens@de.ibm.com> | 2019-11-17 16:55:38 +0300 |
|---|---|---|
| committer | Vasily Gorbik <gor@linux.ibm.com> | 2019-11-20 14:58:13 +0300 |
| commit | 72a81ad9d6d62dcb79f7e8ad66ffd1c768b72026 (patch) | |
| tree | ee93f130ea2a3a0937309feaede1a20a458d4947 /arch/x86/mm/mem_encrypt.c | |
| parent | c2313594216b3fde9559e502bb36d14e9d601a56 (diff) | |
| download | linux-72a81ad9d6d62dcb79f7e8ad66ffd1c768b72026.tar.xz | |
s390/smp: fix physical to logical CPU map for SMT
If an SMT capable system is not IPL'ed from the first CPU the setup of
the physical to logical CPU mapping is broken: the IPL core gets CPU
number 0, but then the next core gets CPU number 1. Correct would be
that all SMT threads of CPU 0 get the subsequent logical CPU numbers.
This is important since a lot of code (like e.g. the CPU topology
code) assumes that CPU maps are setup like this. If the mapping is
broken the system will not IPL due to broken topology masks:
[ 1.716341] BUG: arch topology broken
[ 1.716342] the SMT domain not a subset of the MC domain
[ 1.716343] BUG: arch topology broken
[ 1.716344] the MC domain not a subset of the BOOK domain
This scenario can usually not happen since LPARs are always IPL'ed
from CPU 0 and also re-IPL is intiated from CPU 0. However older
kernels did initiate re-IPL on an arbitrary CPU. If therefore a re-IPL
from an old kernel into a new kernel is initiated this may lead to
crash.
Fix this by setting up the physical to logical CPU mapping correctly.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Diffstat (limited to 'arch/x86/mm/mem_encrypt.c')
0 files changed, 0 insertions, 0 deletions