- 25 May, 2022 4 commits
-
-
Nico Boehr authored
Since commit 1179f170 ("s390: fix fpu restore in entry.S"), the sie_block pointer is located at empty1[1], but in sie_block() it was taken from empty1[0]. This leads to a random pointer being dereferenced, possibly causing system crash. This problem can be observed when running a simple guest with an endless loop and recording the cpu-clock event: sudo perf kvm --guestvmlinux=<guestkernel> --guest top -e cpu-clock With this fix, the correct guest address is shown. Fixes: 1179f170 ("s390: fix fpu restore in entry.S") Cc: stable@vger.kernel.org Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Nico Boehr <nrb@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Use asm offsets method to generate register offsets into pt_regs, instead of open-coding at several places. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Due to historic reasons the base program check handler calls a configurable function. Given that there is only the early program check handler left, simplify the code by directly calling that function. The only other user was removed with commit d485235b ("s390: assume diag308 set always works"). Also rename all functions and the asm file to reflect this. Reviewed-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Jann Horn authored
The argument of scatterwalk_unmap() is supposed to be the void* that was returned by the previous scatterwalk_map() call. The s390 AES-GCM implementation was instead passing the pointer to the struct scatter_walk. This doesn't actually break anything because scatterwalk_unmap() only uses its argument under CONFIG_HIGHMEM and ARCH_HAS_FLUSH_ON_KUNMAP. Fixes: bf7fa038 ("s390/crypto: add s390 platform specific aes gcm support.") Signed-off-by:
Jann Horn <jannh@google.com> Acked-by:
Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20220517143047.3054498-1-jannh@google.comSigned-off-by:
-
- 18 May, 2022 1 commit
-
-
Heiko Carstens authored
Get rid of old 31 bit leftovers within ipl code: - convert everything to pc relative code - use 64 bit addressing mode as early as possible - use 64 bit arithmetics wherever possible This way the code doesn't look as odd as before anymore. Reviewed-by:
-
- 17 May, 2022 7 commits
-
-
Heiko Carstens authored
Before version 14.0.0 llvm's integrated assembler fails to handle some displacement variants: arch/s390/purgatory/head.S:108:10: error: invalid operand for instruction lg %r11,kernel_type-.base_crash(%r13) Instead of working around this and given that this is already fixed raise the minimum clang version from 13.0.0 to 14.0.0. Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
-
Heiko Carstens authored
Commit ee6d777d ("s390/decompressor: support extra debug flags") added extra debug flags, in particular debug info is created, depending on config options. With llvm's IAS this causes this compile warning: arch/s390/boot/head.S:38:1: warning: DWARF2 only supports one section per compilation unit .section ".head.text","ax" ^ This is a known problem and was addressed with commit b8a90923 ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1"). Just do the same for s390 to get rid of this warning. Tested-by:
-
Heiko Carstens authored
For at least the mvc and clc instructions llvm's integrated assembler can generate incorrect code. In particular this happens with decompressor boot code. The reason seems to be that relocations for the second displacement of each instruction are at incorrect locations (-/+: gas vs llvm IAS): mvc __LC_IO_NEW_PSW(16),.Lnewpsw results in 4: d2 0f 01 f0 00 00 mvc 496(16,%r0),0 - 8: R_390_12 .head.text+0x10 + 6: R_390_12 .head.text+0x10 and clc 0(3,%r4),.L_hdr results in 258: d5 02 40 00 00 00 clc 0(3,%r4),0 - 25c: R_390_12 .head.text+0x324 + 25a: R_390_12 .head.text+0x324 Workaround this by writing the code in a different way. Tested-by: -
Heiko Carstens authored
llvm's integrated assembler cannot handle immediate values which are calculated with two local labels: arch/s390/purgatory/head.S:139:11: error: invalid operand for instruction aghi %r8,-(.base_crash-purgatory_start) Workaround this by partially rewriting the code. Link: https://lore.kernel.org/r/20220511120532.2228616-6-hca@linux.ibm.comSigned-off-by:
-
Heiko Carstens authored
llvm's integrated assembler cannot handle immediate values which are calculated with two local labels: <instantiation>:3:13: error: invalid operand for instruction clgfi %r14,.Lsie_done - .Lsie_gmap Workaround this by adding clang specific code which reads the specific value from memory. Since this code is within the hot paths of the kernel and adds an additional memory reference, keep the original code, and add ifdef'ed code. Acked-by:
-
Heiko Carstens authored
clang fails to handle ".if" statements in inline assembly which are heavily used in the alternatives code. To work around this remove this code, and enforce that users of alternatives must specify original and alternative instruction sequences which have identical sizes. Add a compile time check with two ".org" statements similar to arm64. In result not only clang can handle this, but also quite a lot of code can be removed. Acked-by:
Vasily Gorbik <gor@linux.ibm.com> Tested-by:
-
Heiko Carstens authored
Explicitly provide identical sized original/alternative instruction sequences. This way there is no need for the s390 specific alternatives infrastructure to generate padding sequences. The code which generates such sequences will be removed with a follow on patch. Acked-by:
-
- 16 May, 2022 1 commit
-
-
Thomas Richter authored
Export the extended counter set counters of the IBM z16 via sysfs. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Acked-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
-
- 11 May, 2022 3 commits
-
-
Heiko Carstens authored
gcc 12 does not (always) optimize away code that should only be generated if parameters are constant and within in a certain range. This depends on various obscure kernel config options, however in particular PROFILE_ALL_BRANCHES can trigger this compile error: In function ‘__atomic_add_const’, inlined from ‘__preempt_count_add.part.0’ at ./arch/s390/include/asm/preempt.h:50:3: ./arch/s390/include/asm/atomic_ops.h:80:9: error: impossible constraint in ‘asm’ 80 | asm volatile( \ | ^~~ Workaround this by simply disabling the optimization for PROFILE_ALL_BRANCHES, since the kernel will be so slow, that this optimization won't matter at all. Reported-by: -
Sven Schnelle authored
clock_delta is declared as unsigned long in various places. However, the clock sync delta can be negative. This would add a huge positive offset in clock_sync_global where clock_delta is added to clk.eitod which is a 72 bit integer. Declare it as signed long to fix this. Cc: stable@vger.kernel.org Signed-off-by:
-
Sven Schnelle authored
The size of the TOD offset field in the stp info response is 64 bits. Signed-off-by:
Heiko Carstens <hca@de.ibm.com> Signed-off-by:
-
- 09 May, 2022 2 commits
-
-
Thomas Richter authored
PMU device driver perf_pai_crypto supports Processor Activity Instrumentation (PAI), available with IBM z16: - maps a full page to lowcore address 0x1500. - uses CR0 bit 13 to turn PAI crypto counting on and off. - creates a sample with raw data on each context switch out when at context switch some mapped counters have a value of nonzero. This device driver only supports CPU wide context, no task context is allowed. Support for counting: - one or more counters can be specified using perf stat -e pai_crypto/xxx/ where xxx stands for the counter event name. Multiple invocation of this command is possible. The counter names are listed in /sys/devices/pai_crypto/events directory. - one special counters can be specified using perf stat -e pai_crypto/CRYPTO_ALL/ which returns the sum of all incremented crypto counters. - one event pai_crypto/CRYPTO_ALL/ is reserved for sampling. No multiple invocations are possible. The event collects data at context switch out and saves them in the ring buffer. Add qpaci assembly instruction to query supported memory mapped crypto counters. It returns the number of counters (no holes allowed in that range). The PAI crypto counter events are system wide and can not be executed in parallel. Therefore some restrictions documented in function paicrypt_busy apply. In particular event CRYPTO_ALL for sampling must run exclusive. Only counting events can run in parallel. PAI crypto counter events can not be created when a CPU hot plug add is processed. This means a CPU hot plug add does not get the necessary PAI event to record PAI cryptography counter increments on the newly added CPU. CPU hot plug remove removes the event and terminates the counting of PAI counters immediately. Co-developed-by:
Juergen Christ <jchrist@linux.ibm.com> Signed-off-by:
-
Sven Schnelle authored
arch_check_user_regs() is used at the moment to verify that struct pt_regs contains valid values when entering the kernel from userspace. s390 needs a place in the generic entry code to modify a cpu data structure when switching from userspace to kernel mode. As arch_check_user_regs() is exactly this, rename it to arch_enter_from_user_mode(). When entering the kernel from userspace, arch_check_user_regs() is used to verify that struct pt_regs contains valid values. Note that the NMI codepath doesn't call this function. s390 needs a place in the generic entry code to modify a cpu data structure when switching from userspace to kernel mode. As arch_check_user_regs() is exactly this, rename it to arch_enter_from_user_mode(). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Link: https://lore.kernel.org/r/20220504062351.2954280-2-tmricht@linux.ibm.comSigned-off-by:
-
- 06 May, 2022 15 commits
-
-
Heiko Carstens authored
Remove various declarations from former s390 specific compat system calls which have been removed with commit fef747ba ("s390: use generic UID16 implementation"). While at it clean up the whole small header file. Signed-off-by:
-
Heiko Carstens authored
LLVM's integrated assembler reports the following error when compiling entry.S: <instantiation>:38:5: error: unknown token in expression tm %r8,0x0001 # coming from user space? The correct instruction would have been tmhh instead of tm. The current code is doing nothing, since (with gas) it get's translated to a tm instruction which reads from real address 8, which again contains always zero, and therefore the conditional code is never executed. Note that due to the missing displacement gas translates "%r8" into "8(%r0)". Also code inspection reveals that this conditional code is not needed. Therefore remove it. Reviewed-by:
-
Heiko Carstens authored
Convert parmarea to C, which makes it much easier to initialize it. No need to keep offsets in assembler code in sync with struct parmarea anymore. Reviewed-by:
-
Heiko Carstens authored
Convert initial lowcore to C and use proper defines and structures to initialize it. This should make the z/VM ipl procedure a bit less magic. Acked-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by:
-
Heiko Carstens authored
The short psw definitions are contained in compat header files, however short psws are not compat specific. Therefore move the definitions to ptrace header file. This also gets rid of a compat header include in kvm code. Acked-by:
-
Heiko Carstens authored
Initialize all new psws with disabled wait psws, except for the restart new psw. This way every unexpected exception, svc, machine check, or interrupt is handled properly. Reviewed-by:
-
Heiko Carstens authored
The program check handler of the kernel image points to startup_pgm_check_handler. However an early program check which happens while loading the kernel image will jump to potentially random code, since the code of the program check handler is not yet loaded; leading to a program check loop. Therefore initialize it to a disabled wait psw and let the startup code set the proper psw when everything is in memory. Reviewed-by:
-
Heiko Carstens authored
Move iplstart entry point to 0x200 again, instead of the middle of the ipl code. This way even the comment describing the ccw program is correct again. Acked-by:
-
Heiko Carstens authored
The final kernel image is created by linking decompressor object files with a startup archive. The startup archive file however does not contain only optional code and data which can be discarded if not referenced. It also contains mandatory object data like head.o which must never be discarded, even if not referenced. Move the decompresser code and linker script to the boot directory and get rid of the startup archive so everything is kept during link time. Acked-by:
-
Heiko Carstens authored
LLVM's integrated assembler does not like comments within macros: <instantiation>:3:19: error: too many positional arguments GR_NUM b2, 1 /* Base register */ ^ Remove them, since they are obvious anyway. Signed-off-by: -
Heiko Carstens authored
Use local labels in .set directives to avoid potential compile errors with LTO + clang. See commit 334865b2 ("x86/extable: Prefer local labels in .set directives") for further details. Since s390 doesn't support LTO currently this doesn't fix a real bug for now, but helps to avoid problems as soon as required pieces have been added to llvm. Signed-off-by:
-
Heiko Carstens authored
Use local labels in .set directives to avoid potential compile errors with LTO + clang. See commit 334865b2 ("x86/extable: Prefer local labels in .set directives") for further details. Since s390 doesn't support LTO currently this doesn't fix a real bug for now, but helps to avoid problems as soon as required pieces have been added to llvm. Signed-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220430191122.8667-5-Julia.Lawall@inria.frSigned-off-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
-
Guilherme G. Piccoli authored
Currently many console drivers for s390 rely on panic/reboot notifiers to invoke callbacks on these events. The panic() function disables local IRQs, secondary CPUs and preemption, so callbacks invoked on panic are effectively running in atomic context. Happens that most of these console callbacks from s390 doesn't take the proper care with regards to atomic context, like taking spinlocks that might be taken in other function/CPU and hence will cause a lockup situation. The goal for this patch is to improve the notifiers reliability, acting on 4 console drivers, as detailed below: (1) con3215: changed a regular spinlock to the trylock alternative. (2) con3270: also changed a regular spinlock to its trylock counterpart, but here we also have another problem: raw3270_activate_view() takes a different spinlock. So, we worked a helper to validate if this other lock is safe to acquire, and if so, raw3270_activate_view() should be safe. Notice though that there is a functional change here: it's now possible to continue the notifier code [reaching con3270_wait_write() and con3270_rebuild_update()] without executing raw3270_activate_view(). (3) sclp: a global lock is used heavily in the functions called from the notifier, so we added a check here - if the lock is taken already, we just bail-out, preventing the lockup. (4) sclp_vt220: same as (3), a lock validation was added to prevent the potential lockup problem. Besides (1)-(4), we also removed useless void functions, adding the code called from the notifier inside its own body, and changed the priority of such notifiers to execute late, since they are "heavyweight" for the panic environment, so we aim to reduce risks here. Changed return values to NOTIFY_DONE as well, the standard one. Signed-off-by:
Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20220427224924.592546-14-gpiccoli@igalia.comSigned-off-by:
-
- 27 Apr, 2022 1 commit
-
-
Pingfan Liu authored
As demonstrated by commit 74bdf781 ("genirq: Speedup show_interrupts()"), irq_desc can be accessed safely in RCU read section. Hence here resorting to rcu read lock to get rid of irq_lock_sparse(). Signed-off-by:
Pingfan Liu <kernelfans@gmail.com> Link: https://lore.kernel.org/r/20220422100212.22666-1-kernelfans@gmail.comSigned-off-by:
-
- 25 Apr, 2022 6 commits
-
-
Ilya Leoshkevich authored
test_barrier fails on s390 because of the missing KCSAN instrumentation for several synchronization primitives. Add it to barriers by defining __mb(), __rmb(), __wmb(), __dma_rmb() and __dma_wmb(), and letting the common code in asm-generic/barrier.h do the rest. Spinlocks require instrumentation only on the unlock path; notify KCSAN that the CPU cannot move memory accesses outside of the spin lock. In reality it also cannot move stores inside of it, but this is not important and can be omitted. Reported-by:
Tobias Huschle <huschle@linux.ibm.com> Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
-
Niklas Schnelle authored
Currently it is not detectable from within Linux when PCI instructions are retried because of a busy condition. Detecting such conditions and especially how long they lasted can however be quite useful in problem determination. This patch enables this by adding an s390dbf error log when a CC 2 is first encountered as well as after the retried instruction. Despite being unlikely it may be possible that these added debug messages drown out important other messages so allow setting the debug level in zpci_err_insn*() and set their level to 1 so they can be filtered out if need be. Reviewed-by:
Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by:
Pierre Morel <pmorel@linux.ibm.com> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
-
Niklas Schnelle authored
Currently when a PCI instruction returns a non-zero condition code it can be very hard to tell from the s390dbf logs what kind of instruction was executed. In case of PCI memory I/O (MIO) instructions it is even impossible to tell if we attempted a load, store or block store or how large the access was because only the address is logged. Improve this by adding an indicator byte for the instruction type to the error record and also store the length of the access for MIO instructions where this can not be deduced from the request. We use the following indicator values: - 'l': PCI load - 's': PCI store - 'b': PCI store block - 'L': PCI load (MIO) - 'S': PCI store (MIO) - 'B': PCI store block (MIO) - 'M': MPCIFC - 'R': RPCIT Reviewed-by:
-
Niklas Schnelle authored
Availability events are logged in s390dbf in s390dbf/pci_error/hex_ascii even though they don't indicate an error condition. They have also become redundant as commit 6526a597 ("s390/pci: add simpler s390dbf traces for events") added an s390dbf/pci_msg/sprintf log entry for availability events which contains all non reserved fields of struct zpci_ccdf_avail. On the other hand the availability entries in the error log make it easy to miss actual errors and may even overwrite error entries if the message buffer wraps. Thus simply remove the availability events from the error log thereby establishing the rule that any content in s390dbf/pci_error indicates some kind of error. Reviewed-by:
-
Niklas Schnelle authored
While the zpci_dbg() macro offers a level parameter this is currently largely unused. The only instance with higher importance than 3 is the UID checking change debug message which is not actually more important as the UID uniqueness guarantee is already exposed in sysfs so this should rather be 3 as well. On the other hand the "add ..." message which shows what devices are visible at the lowest level is essential during problem determination. By setting its level to 1, lowering the debug level can act as a filter to only show the available functions. On the error side the default level is set to 6 while all existing messages are printed at level 0. This is inconsistent and means there is no room for having messages be invisible on the default level so instead set the default level to 3 like for errors matching the default for debug messages. Reviewed-by:
-
Thomas Huth authored
The vfio_ap module tries to register for the vfio_ap bus - but that's the interface that it provides itself, so this does not make much sense, thus let's simply drop this statement now. Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Tony Krowiak <akrowiak@linux.ibm.com> Link: https://lore.kernel.org/r/20220413094416.412114-1-thuth@redhat.comSigned-off-by:
-
