summaryrefslogtreecommitdiff
path: root/arch/s390
AgeCommit message (Collapse)AuthorFilesLines
2021-08-26s390/smp: do not use nodat_stack for secondary CPU startAlexander Gordeev1-15/+10
The secondary CPU start C routine uses nodat_stack as a interim stack before finally switching to kernel_stack. Such scheme is superfluous, since the assembler restart interrupt handler (that secondary CPU starter is called from) does not need to use any stack for switching into DAT mode. Once DAT is on, any stack including virtually- mapped one could be used. Avoid the use of nodat_stack and smp_start_secondary() helper. Instead, initiate kernel_stack directly from the restart interrupt handler. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-26s390/smp: enable DAT before CPU restart callback is calledAlexander Gordeev8-19/+42
The restart interrupt is triggered whenever a secondary CPU is brought online, a remote function call dispatched from another CPU or a manual PSW restart is initiated and causes the system to kdump. The handling routine is always called with DAT turned off. It then initializes the stack frame and invokes a callback. The existing callbacks handle DAT as follows: * __do_restart() and __machine_kexec() turn in on upon entry; * __ipl_run(), __reipl_run() and __dump_run() do not turn it right away, but all of them call diag308() - which turns DAT on, but only if kasan is enabled; In addition to the described complexity all callbacks (and the functions they call) should avoid kasan instrumentation while DAT is off. This update enables DAT in the assembler restart handler and relieves any callbacks (which are mostly C functions) from dealing with DAT altogether. There are four types of CPU restart that initialize control registers in different ways: 1. Start of secondary CPU on boot - control registers are inherited from the IPL CPU; 2. Restart of online CPU - control registers of the CPU being restarted are kept; 3. Hotplug of offline CPU - control registers are inherited from the starting CPU; 4. Start of offline CPU triggered by manual PSW restart - the control registers are read from the absolute lowcore and contain the boot time IPL CPU values updated with all follow-up calls of smp_ctl_set_bit() and smp_ctl_clear_bit() routines; In first three cases contents of the control registers is the most recent. In the latter case control registers are good enough to facilitate successful completion of kdump operation. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-26s390: update defconfigsHeiko Carstens1-1/+1
Ingo Franzki reported that our defconfig and debug_config went out of sync with respect to DM_INTEGRITY. Fix it. Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25KVM: s390: generate kvm hypercall functionsHeiko Carstens1-156/+73
Generate kvm hypercall functions with a macro instead of duplicating the more or less identical code seven times. This also reduces number of lines of code. However the main purpose is to get rid of as many as possible open coded error prone register asm constructs in s390 architecture code. For the only user of kvm_hypercall identical code is created before/after this patch (drivers/s390/virtio/virtio_ccw.c). Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20210713145713.2815167-1-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/sclp: add tracing of SCLP interactionsPeter Oberparleiter1-7/+9
Add tracing of interactions between the SCLP base driver, firmware and other drivers to support problem determination in case of SCLP-related issues. For that purpose this patch introduces two new s390dbf debug areas: - sclp: An abbreviated log of all common interactions - sclp_err: A full log of failed or abnormal interactions Tracing of full SCCB contents can be enabled for the sclp area by setting its debug level to maximum (6). Overview of added trace events: * Firmware interaction: - SRV1: Service call about to be issued - SRV2: Service call was issued - INT: Interrupt received * Driver interaction: - RQAD: Request was added - RQOK: Request success - RQAB: Request aborted - RQTM: Request timed out - REG: Event listener registered - UREG: Event listener unregistered - EVNT: Event callback - STCG: State-change callback * Abnormal events: - TMO: A timeout occurred - UNEX: Unexpected SCCB completion * Other (not traced at default level): - SYN1: Synchronous wait start - SYN2: Synchronous wait end Since the SCLP interface is used by console drivers this patch also moves s390dbf printks outside the critical section protected by debug area locks to prevent a potential deadlock that would otherwise be introduced between console_owner --> sclp_lock --> sclp_debug.lock. Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/debug: add early tracing supportPeter Oberparleiter2-0/+151
Debug areas can currently only be used after s390dbf initialization which occurs as a postcore_initcall. This is too late for tracing earlier code such as that related to console_init(). This patch introduces a macro for defining a statically initialized debug area that can be used to trace very early code. The macro is made available for built-in code only because modules are never running during early boot. Example usage: 1. Define static debug area: DEFINE_STATIC_DEBUG_INFO(my_debug, "my_debug", 4, 1, 16, &debug_hex_ascii_view); 2. Add trace entry: debug_event(&my_debug, 0, "DATA", 4); Note: The debug area is automatically registered in debugfs during boot. A driver must not call any of the debug_register()/_unregister() functions on a static debug_info_t! Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/debug: fix debug area life cyclePeter Oberparleiter1-46/+56
Currently allocation and registration of s390dbf debug areas are tied together. As a result, a debug area cannot be unregistered and re-registered while any process has an associated debugfs file open. Fix this by splitting alloc/release from register/unregister. Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/debug: keep debug data on resizePeter Oberparleiter1-21/+53
Any previously recorded s390dbf debug data is reset when a debug area is resized using the 'pages' sysfs attribute. This can make live-debugging unnecessarily complex. Fix this by copying existing debug data to the newly allocated debug area when resizing. Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/diag: make restart_part2 a local labelHeiko Carstens1-2/+2
Avoid that the "restart_part2" label, which is in the middle of a function, appears in /proc/kallsyms. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/mm,pageattr: fix walk_pte_level() early exitHeiko Carstens1-1/+1
In case of splitting to 4k mapping the early exit in walk_pte_level() must only be taken iff flags is equal to SET_MEMORY_4K. Currently the early exit is taken if the flag is set, and also others might be set. This may lead to the situation that a mapping is split but other changes are not done, like e.g. setting pages to R/W. There is currently no such caller, but there might be in the future. Fixes: b3e1a00c8fa4 ("s390/mm: implement set_memory_4k()") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390: fix typo in linker scriptHeiko Carstens1-1/+1
Rename amod31 to amode31 like it was supposed to be. Fixes: c78d0c7484f0 ("s390: rename dma section to amode31") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390: remove do_signal() prototype and do_notify_resume() functionSven Schnelle2-8/+0
Both are no longer used since the conversion to generic entry, therefore remove them. Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: improve DMA translation init and exitNiklas Schnelle7-38/+63
Currently zpci_dma_init_device()/zpci_dma_exit_device() is called as part of zpci_enable_device()/zpci_disable_device() and errors for zpci_dma_exit_device() are always ignored even if we could abort. Improve upon this by moving zpci_dma_exit_device() out of zpci_disable_device() and check for errors whenever we have a way to abort the current operation. Note that for example in zpci_event_hard_deconfigured() the device is expected to be gone so we really can't abort and proceed even in case of error. Similarly move the cc == 3 special case out of zpci_unregister_ioat() and into the callers allowing to abort when finding an already disabled devices precludes proceeding with the operation. While we are at it log IOAT register/unregister errors in the s390 debugfs log, Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: simplify CLP List PCI handlingNiklas Schnelle3-87/+102
Currently clp_get_state() and clp_refresh_fh() awkwardly use the clp_list_pci() callback mechanism to find the entry for a specific FID and update its zdev, respectively return its state. This is both needlessly complex and means we are always going through the entire PCI function list even if the FID has already been found. Instead lets introduce a clp_find_pci() function to find a specific entry and share the CLP List PCI request handling code with clp_list_pci(). With that in place we can also easily make the function handle a simple out parameter instead of directly altering the zdev allowing easier access to the updated function handle by the caller. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: handle FH state mismatch only on disableNiklas Schnelle3-6/+16
Instead of always treating CLP_RC_SETPCIFN_ALRDY as success and blindly updating the function handle restrict this special handling to the disable case by moving it into zpci_disable_device() and still treating it as an error while also updating the function handle such that a subsequent zpci_disable_device() succeeds or the caller can ignore the error when aborting is not an option such as for zPCI event 0x304. Also print this occurrence to the log such that an admin can tell why a disable operation returned an error. A mismatch between the state of the underlying device and our view of it can naturally happen when the device suddenly enters the error state but we haven't gotten the error notification yet, it must not happen on enable though. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: fix misleading rc in clp_set_pci_fn()Niklas Schnelle2-20/+20
Currently clp_set_pci_fn() always returns 0 as long as the CLP request itself succeeds even if the operation itself returns a response code other than CLP_RC_OK or CLP_RC_SETPCIFN_ALRDY. This is highly misleading because calling code assumes that a zero rc means that the operation was successful. Fix this by returning the response code or cc on failure with the exception of the special handling for CLP_RC_SETPCIFN_ALRDY. Also let's not assume that the returned function handle for CLP_RC_SETPCIFN_ALRDY is 0, we don't need it anyway. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/boot: factor out offset_vmlinux_info() functionAlexander Gordeev1-8/+12
Move offsetting all of vmlinux_info fields to a separate function for better readability. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/kasan: fix large PMD pages address alignment checkAlexander Gordeev1-21/+20
It is currently possible to initialize a large PMD page when the address is not aligned on page boundary. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: reset zdev->zbus on registration failureNiklas Schnelle1-1/+2
On failure to register a struct zpci_dev with a struct zpci_bus we left a dangling pointer in zdev->zbus. As zpci_create_device() bails if zpci_bus_device_register() fails this is of no consequence but still bad practice. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-25s390/pci: cleanup resources only if necessaryNiklas Schnelle1-1/+2
It's currently safe to call zpci_cleanup_bus_resources() even if the resources were never created but it makes no sense so check zdev->has_resources before we call zpci_cleanup_bus_resources() in zpci_release_device(). Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-18s390/sclp: reserve memory occupied by sclp early bufferAlexander Egorenkov2-0/+3
The memory block occupied by the SCLP early buffer that is allocated by the decompressor and then handed over to the decompressed kernel, must be reserved to prevent it from being reused for other purposes. This is necessary because the SCLP early buffer is still in use during kernel initialization. Fixes: f1d3c5323772 ("s390/boot: move sclp early buffer from fixed address in asm to C") Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/mm: remove unused cmma functionsDavid Hildenbrand2-46/+0
The last user of arch_set_page_states(), arch_set_page_nodat() and arch_test_page_nodat() was removed in commit 394216275c7d ("s390: remove broken hibernate / power management support"), let's remove these functions. Signed-off-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20210806075430.6103-1-david@redhat.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: remove unused support for SLIB parametersJulian Wiedmann1-4/+0
Neither of the two drivers provides any SLIB parameter data, so get rid of the dead code. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-05s390: rename dma section to amode31Heiko Carstens17-132/+135
The dma section name is confusing, since the code which resides within that section has nothing to do with direct memory access. Instead the limitation is that the code has to run in 31 bit addressing mode, and therefore has to reside below 2GB. So the name was chosen since ZONE_DMA is the same region. To reduce confusion rename the section to amode31, which hopefully describes better what this is about. Note: this will also change vmcoreinfo strings - SDMA=... gets renamed to SAMODE31=... - EDMA=... gets renamed to EAMODE31=... Acked-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-05s390/mm: use page_to_virt() in __kernel_map_pages()Heiko Carstens1-1/+1
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-05s390: replace deprecated CPU-hotplug functionsSebastian Andrzej Siewior8-21/+21
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock(). Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20210803141621.780504-5-bigeasy@linutronix.de Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-08-03s390/ftrace: implement hotpatchingIlya Leoshkevich7-57/+313
s390 allows hotpatching the mask of a conditional jump instruction. Make use of this feature in order to avoid the expensive stop_machine() call. The new trampolines are split in 3 stages: - A first stage is a 6-byte relative conditional long branch located at each function's entry point. Its offset always points to the second stage for the corresponding function, and its mask is either all 0s (ftrace off) or all 1s (ftrace on). The code for flipping the mask is borrowed from ftrace_{enable,disable}_ftrace_graph_caller. After flipping, ftrace_arch_code_modify_post_process() syncs with all the other CPUs by sending SIGPs. - Second stages for vmlinux are stored in a separate part of the .text section reserved by the linker script, and in dynamically allocated memory for modules. This prevents the icache pollution. The total size of second stages is about 1.5% of that of the kernel image. Putting second stages in the .bss section is possible and decreases the size of the non-compressed vmlinux, but splits the kernel 1:1 mapping, which is a bad tradeoff. Each second stage contains a call to the third stage, a pointer to the part of the intercepted function right after the first stage, and a pointer to an interceptor function (e.g. ftrace_caller). Second stages are 8-byte aligned for the future direct calls implementation. - There are only two copies of the third stage: in the .text section for vmlinux and in dynamically allocated memory for modules. It can be an expoline, which is relatively large, so inlining it into each second stage is prohibitively expensive. As a result of this organization, phoronix-test-suite with ftrace off does not show any performance degradation. Suggested-by: Sven Schnelle <svens@linux.ibm.com> Suggested-by: Vasily Gorbik <gor@linux.ibm.com> Co-developed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20210728212546.128248-3-iii@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-30s390: move the install rule to arch/s390/MakefileMasahiro Yamada2-5/+2
Currently, the install target in arch/s390/Makefile descends into arch/s390/boot/Makefile to invoke the shell script, but there is no good reason to do so. arch/s390/Makefile can run the shell script directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210729142338.446002-1-masahiroy@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-30s390: enable KCSANIlya Leoshkevich6-0/+6
s390x GCC and SystemZ Clang have ThreadSanitizer support now [1] [2], so enable KCSAN for s390. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ea22954e7c58 [2] https://reviews.llvm.org/D105629 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-30s390: add kfence region to pagetable dumperSven Schnelle1-0/+16
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Link: https://lore.kernel.org/r/20210728190254.3921642-5-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-30s390: add support for KFENCESven Schnelle5-4/+54
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> [hca@linux.ibm.com: simplify/rework code] Link: https://lore.kernel.org/r/20210728190254.3921642-4-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-30s390/mm: implement set_memory_4k()Heiko Carstens2-2/+18
Implement set_memory_4k() which will split any present large or huge mapping in the given range to a 4k mapping. Link: https://lore.kernel.org/r/20210728190254.3921642-2-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/delay: get rid of not needed header includesHeiko Carstens1-9/+2
After all the changes to delay.c there are many includes which are not needed anymore. Get rid of them. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/boot: get rid of arithmetics on function pointersHeiko Carstens1-1/+1
sparse warning: CHECK arch/s390/boot/startup.c arch/s390/boot/startup.c:283:39: error: arithmetics on pointers to functions Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/headers: fix code style in module.hIlya Leoshkevich1-4/+2
struct brace should be on the same line. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: make sie capability regular hwcapHeiko Carstens2-22/+4
Commit 7f16d7e787b7 ("s390: show virtualization support in /proc/cpuinfo") introduced special handling for sie capability, saying this should not be exposed via hwcaps, without giving a reason. However this leads to an inconsistent /proc/cpuinfo features line where all features except the sie capability are also present in hwcaps. I really don't see a reason to not add that to hwcaps - it might be quite pointless, but at least this way it is possible to get rid of some special handling. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: remove hwcap stfle checkHeiko Carstens1-1/+1
Remove the not so obvious "(elf_hwcap & (1UL << 2)" which only checks if stfle is available. This used to be required for old code before test_facility() was introduced. test_facility() will do the right thing, regardless if stfle is available or not. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: remove z/Architecture mode active checkHeiko Carstens1-2/+1
Remove a leftover from the common 31/64 bit code. z/Architecture mode is now always active, there is no need to check. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: use consistent coding style / remove commentsHeiko Carstens1-54/+13
Use a consistent coding style within setup_hwcaps() and remove obvious and outdated comments. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: open code initialization of first six hwcap bitsHeiko Carstens1-6/+24
The first six hwcap bits are initialized in a rather odd way: an array contains the stfl(e) bits which need to be set, so that the corresponding bit position (= array index) within hwcaps are set. Better open code it like it is done for all other bits, making it obvious which bit is set when. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: split setup_hwcaps()Heiko Carstens1-9/+15
setup_hwcaps() is a quite large function. Make it smaller by moving the elf platform setup code into an independent setup function. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: move setup_hwcaps()Heiko Carstens2-158/+160
Move setup_hwcaps() to processor.c for two reasons: - make setup.c a bit smaller - have allmost all of the hwcap code in one file Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: add sanity checksHeiko Carstens2-0/+4
Add BUILD_BUG_ON() sanity checks to make sure the hwcap string array contains a string for each hwcap. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: use named initializers for hwcap string arraysHeiko Carstens1-4/+23
Use named initializers to make it obvious which hwcap string array element belongs to which hwcap. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: introduce HWCAP bit numbersHeiko Carstens1-23/+52
Introduce HWCAP bit numbers, making it easier to tell at which bit number we currently are. Also use these bits with the BIT macro to define the real HWCAP masks. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/hwcaps: shorten HWCAP definesHeiko Carstens3-49/+49
Remove s390 part of all HWCAP defines, just to make them shorter and easier to handle. The namespace is anyway per architecture. This is similar to what arm64 has. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390: add HWCAP_S390_PCI_MIO to ELF hwcapsNiklas Schnelle3-1/+4
In order to support the use of enhanced PCI instructions in both kernel- and userspace we need both hardware support and proper setup in the kernel. The latter can be toggled off with the pci=nomio command line option. Thus availability of this feature in userspace depends on all of kernel configuration (CONFIG_PCI), hardware support and the current kernel command line and can thus not rely solely on a facility bit. Instead let's introduce a new ELF hardware capability bit HWCAP_S390_PCI_MIO to tell userspace whether these PCI instructions can be used. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390: make PCI mio support a machine flagNiklas Schnelle3-3/+8
Kernel support for the newer PCI mio instructions can be toggled off with the pci=nomio command line option which needs to integrate with common code PCI option parsing. However this option then toggles static branches which can't be toggled yet in an early_param() call. Thus commit 9964f396f1d0 ("s390: fix setting of mio addressing control") moved toggling the static branches to the PCI init routine. With this setup however we can't check for mio support outside the PCI code during early boot, i.e. before switching the static branches, which we need to be able to export this as an ELF HWCAP. Improve on this by turning mio availability into a machine flag that gets initially set based on CONFIG_PCI and the facility bit and gets toggled off if pci=nomio is found during PCI option parsing allowing simple access to this machine flag after early init. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/disassembler: add instructionsHeiko Carstens2-0/+20
Add more instructions to the kernel disassembler. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390: report more CPU capabilitiesHeiko Carstens3-1/+7
Add hardware capability bits and feature tags to /proc/cpuinfo for NNPA and Vector-Packed-Decimal-Enhancement Facility 2. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>