- 12 Sep, 2024 5 commits
-
-
Finn Callies authored
Displays the query (fc=0) and query authentication information (fc=127) as binary in sysfs per CPACF instruction. Files are located in /sys/devices/system/cpu/cpacf/. These information can be fetched via asm already except for PCKMO because this instruction is privileged. To offer a unified interface all CPACF instructions will have this information displayed in sysfs in files <instruction>_query_raw and <instruction>_query_auth_info_raw. A new tool introduced into s390-tools called cpacfinfo will use this information to convert and display in human readable form. Suggested-by:
Harald Freudenberger <freude@linux.ibm.com> Reviewed-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Finn Callies <fcallies@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Finn Callies authored
Introduce functions __cpacf_qai() and wrapper cpacf_qai() to the respective existing functions __cpacf_query() and cpacf_query() are introduced to support the Query Authentication Information feature of MSA 13. Suggested-by:
-
Finn Callies authored
Rework of the __cpacf_query_rre() and __cpacf_query_rrf() functions to support additional function codes. A function code is passed as a new parameter to specify which subfunction of the supplied Instruction is to be called. Suggested-by:
-
Finn Callies authored
Add the function code definitions for using the KDSA function to the CPACF header file. Suggested-by:
-
Jens Remus authored
Instruction format RSY_RDRU is a duplicate of RSY_RURD2. Use the latter, as it follows the s390-specific conventions for instruction format naming used in binutils. Reviewed-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
-
- 07 Sep, 2024 9 commits
-
-
Heiko Carstens authored
Keep the printk code separate from the program check code and move boot_printk() and helper functions to own printk.c file. Reviewed-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Consistently use boot_printk() everywhere instead of sclp_early_printk() at some places. For some places it was required (e.g. als.c), in order to stay in code compiled for the same architecture level, for other places it is not obvious why sclp_early_printk() was used instead of decompressor_printk(). Given that the whole decompressor code is compiled for the same architecture level, there is no requirement left to use different printk functions. Reviewed-by:
-
Heiko Carstens authored
Rename decompressor_printk() to boot_printk() just to have a shorter function name, which also makes the code more readable. Reviewed-by:
-
Heiko Carstens authored
Only a couple of files of the decompressor are compiled with the minimum architecture level. This is problematic for potential function calls between compile units, especially if a target function is within a compile until compiled for a higher architecture level, since that may lead to an unexpected operation exception. Therefore compile all files of the decompressor for the same (minimum) architecture level. Reviewed-by:
-
Heiko Carstens authored
Replace CONFIG_HAVE_MARCH_*_FEATURES with MARCH_HAS_*_FEATURES everywhere so code gets compiled correctly depending on if the target is the kernel or the decompressor. Reviewed-by:
-
Heiko Carstens authored
Provide MARCH_HAS_*_FEATURES defines which are supposed to be used everywhere instead of the CONFIG_HAVE_MARCH_*_FEATURES defines. Various header files contain code which depend on the CONFIG_HAVE_MARCH_*_FEATURES defines, allowing for compile time optimizations. If such code is used within the decompressor wrong code may be generated (the compiler may generate instructions which are not available for the minimum architecture level of the decompressor). Therefore provide a new header file with MARCH_HAS_*_FEATURES defines, which are only available if __DECOMPRESSOR is not defined. This way code generation for the kernel image is still optimized depending on CONFIG_HAVE_MARCH_*_FEATURES, while code generated for the decompressor is compiled for the minimum architecture level. Reviewed-by:
-
Heiko Carstens authored
Disable compile time optimizations of test_facility() for the decompressor. The decompressor should not contain any optimized code depending on the architecture level set the kernel image is compiled for to avoid unexpected operation exceptions. Add a __DECOMPRESSOR check to test_facility() to enforce that facilities are always checked during runtime for the decompressor. Reviewed-by:
-
Heiko Carstens authored
The decompressor code is partially compiled with march=z900 so it is possible to print an error message in case a kernel is booted on a machine which misses facilities to execute the kernel. Given that the decompressor code also includes header files from the core kernel this causes problems for inline assemblies and other code where the minimum assumed architecture level is set to z10 in the meantime. If such code is also used in the decompressor (e.g. inline functions) z900 support must be implemented again. In order to avoid this and to keep things simple just raise the minimum architecture level to z10 for the decompressor just like for the kernel. Reviewed-by:
-
Heiko Carstens authored
The bss section of the decompressor is part of the compressed kernel image since commit 980d5f9a ("s390/boot: enable .bss section for compressed kernel"). Remove a now incorrect comment that states that the bss section must not be accessed. Reviewed-by:
-
- 05 Sep, 2024 6 commits
-
-
Ingo Franzki authored
Since commit "s390/sha3: Support sha3 performance enhancements" the selftests of the sha3_256_s390 and sha3_512_s390 kernel digests sometimes fail with: alg: shash: sha3-256-s390 test failed (wrong result) on test vector 3, cfg="import/export" alg: self-tests for sha3-256 using sha3-256-s390 failed (rc=-22) or with alg: ahash: sha3-256-s390 test failed (wrong result) on test vector 3, cfg="digest misaligned splits crossing pages" alg: self-tests for sha3-256 using sha3-256-s390 failed (rc=-22) The first failure is because the newly introduced context field 'first_message_part' is not copied during export and import operations. Because of that the value of 'first_message_part' is more or less random after an import into a newly allocated context and may or may not fit to the state of the imported SHA3 operation, causing an invalid hash when it does not fit. Save the 'first_message_part' field in the currently unused field 'partial' of struct sha3_state, even though the meaning of 'partial' is not exactly the same as 'first_message_part'. For the caller the returned state blob is opaque and it must only be ensured that the state can be imported later on by the module that exported it. The second failure is when on entry of s390_sha_update() the flag 'first_message_part' is on, and kimd is called in the first 'if (index)' block as well as in the second 'if (len >= bsize)' block. In this case, the 'first_message_part' is turned off after the first kimd, but the function code incorrectly retains the NIP flag. Reset the NIP flag after the first kimd unconditionally besides turning 'first_message_part' off. Reported-by:Marc Hartmayer <mhartmay@linux.ibm.com> Fixes: 88c02b3f ("s390/sha3: Support sha3 performance enhancements") Reviewed-by:
Holger Dengler <dengler@linux.ibm.com> Reviewed-by:
Joerg Schmidbauer <jschmidb@de.ibm.com> Signed-off-by:
Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by:
-
Harald Freudenberger authored
Add support for deriving protected keys from clear key token for AES xts and HMAC keys via PCKMO instruction. Add support for protected key generation and unwrap of protected key tokens for these key types. Furthermore 4 new sysfs attributes are introduced: - /sys/devices/virtual/misc/pkey/protkey/protkey_aes_xts_128 - /sys/devices/virtual/misc/pkey/protkey/protkey_aes_xts_256 - /sys/devices/virtual/misc/pkey/protkey/protkey_hmac_512 - /sys/devices/virtual/misc/pkey/protkey/protkey_hmac_1024 Signed-off-by:
-
Harald Freudenberger authored
Add the defines for the new PCKMO functions covering MSA 10 (AES XTS "double" keys) and MSA 11 (HMAC keys) support. Signed-off-by:
-
Gerald Schaefer authored
Adding/removing large amount of pages at once to/from the CMM balloon can result in rcu_sched stalls or workqueue lockups, because of busy looping w/o cond_resched(). Prevent this by adding a cond_resched(). cmm_free_pages() holds a spin_lock while looping, so it cannot be added directly to the existing loop. Instead, introduce a wrapper function that operates on maximum 256 pages at once, and add it there. Signed-off-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Reviewed-by:
-
Thomas Richter authored
Update the internal array of PAI extension 1 NNPA counter string table to support specialized processor instrumentation assist instructions. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Acked-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
Update the internal array of PAI crypto counter string table with new counters supported with Message Security Assist extension (MSA) 10 and MSA 11. Signed-off-by:
-
- 29 Aug, 2024 20 commits
-
-
Mete Durlu authored
Add three counters to follow and understand hiperdispatch behavior; * adjustment_count (amount of capacity adjustments triggered) * greedy_time_ms (time spent while all cpus are on high capacity) * conservative_time_ms (time spent while only entitled cpus are on high capacity) These counters can be found under /sys/kernel/debug/s390/hiperdispatch/ Time counters are in <msec> format and only cover the time spent when hiperdispatch is active. Acked-by:
Mete Durlu <meted@linux.ibm.com> Signed-off-by:
-
Mete Durlu authored
Add two attributes for debug purposes. They can be found under; /sys/devices/system/cpu/hiperdispatch/ * hd_stime_threshold : allows user to adjust steal time threshold * hd_delay_factor : allows user to adjust delay factor of hiperdispatch work (after topology updates, delayed work is always delayed extra by this factor) hd_stime_threshold can have values between 0-100 as it represents a percentage value. hd_delay_factor can have values greater than 1. It is multiplied with the default delay to achieve a longer interval, pushing back the next hiperdispatch adjustment after a topology update. Ex: if delay interval is 250ms and the delay factor is 4; delayed interval is now 1000ms(1sec). After each capacity adjustment or topology change, work has a delayed interval of 1 sec for one interval. Acked-by: -
Mete Durlu authored
Expose hiperdispatch controls via sysctl. The user can now toggle hiperdispatch via assigning 0 or 1 to s390.hiperdispatch attribute. When hiperdipatch is toggled on, it tries to adjust CPU capacities, while system is in vertical polarization to gain performance benefits from different CPU polarizations. Disabling hiperdispatch reverts the CPU capacities to their default (HIGH_CAPACITY) and stops the dynamic adjustments. Introduce a kconfig option HIPERDISPATCH_ON which allows users to use hiperdispatch by default on vertical polarization. Using the sysctl attribute s390.hiperdispatch would overwrite this behavior. Acked-by:
-
Mete Durlu authored
Add trace events to debug hiperdispatch behavior and track domain rebuilding. Two events provide information about the decision making of hiperdispatch and the adjustments made. Acked-by:
Tobias Huschle <huschle@linux.ibm.com> Signed-off-by:
-
Mete Durlu authored
The measurements done by hiperdispatch can have sudden spikes and dips during run time. To prevent these outliers effecting the decision making process and causing adjustment overhead, use weighted average of the steal time. Acked-by:
-
Mete Durlu authored
When LPAR is in vertical polarization, CPUs get different polarization values, namely vertical high, vertical medium and vertical low. These values represent the likelyhood of the CPU getting physical runtime. Vertical high CPUs will always get runtime and others get varying runtime depending on the load the CEC is under. Vertical high and vertical medium CPUs are considered the CPUs which the current LPAR has the entitlement to run on. The vertical lows are on the other hand are borrowed CPUs which would only be given to the LPAR by hipervisor when the other LPARs are not utilizing them. Using the CPU capacities, hint linux scheduler when it should prioritise vertical high and vertical medium CPUs over vertical low CPUs. By tracking various system statistics hiperdispatch determines when to adjust cpu capacities. After each adjustment, rebuilding of scheduler domains is necessary to notify the scheduler about capacity changes but since this operation is costly it should be done as sparsely as possible. Acked-by:
-
Mete Durlu authored
Linux scheduler allows architectures to assign capacity values to individual CPUs. This hints scheduler the performance difference between CPUs and allows more efficient task distribution them. Implement helper methods to set and get CPU capacities for s390. This is particularly helpful in vertical polarization configurations of LPARs. On vertical polarization an LPARs CPUs can get different polarization values depending on the CEC configuration. CPUs with different polarization values can perform different from each other, using CPU capacities this can be reflected to linux scheduler. Acked-by:
-
Tobias Huschle authored
By default, all systems on s390 start in horizontal cpu polarization. Selecting the new config option SCHED_TOPOLOGY_VERTICAL allows to build a kernel that switches to vertical polarization during boot. Acked-by:
-
Tobias Huschle authored
Provide an additional path to set the polarization of the system, such that a user no longer relies on the sysfs interface only and is able configure the polarization for every reboot via sysctl control files. The new sysctl can be set as follows: - s390.polarization=0 for horizontal polarization - s390.polarization=1 for vertical polarization Acked-by:
-
Tobias Huschle authored
Introduce a new debug file which allows to determine how many warning track grace periods were missed on each CPU. The new file can be found as /sys/kernel/debug/s390/wti It is formatted as: CPU0 CPU1 [...] CPUx xyz xyz [...] xyz Acked-by: -
Tobias Huschle authored
A virtual CPU that has received a warning-track interrupt may fail to acknowledge the interrupt within the warning-track grace period. While this is usually not a problem, it will become necessary to investigate if there is a large number of such missed warning-track interrupts. Therefore, it is necessary to track these events. The information is tracked through the s390 debug facility and can be found under /sys/kernel/debug/s390dbf/wti/. The hex_ascii output is formatted as: <pid> <symbol> The values pid and current psw are collected when a warning track interrupt is received. Symbol is either the kernel symbol matching the collected psw or redacted to <user> when running in user space. Each line represents the currently executing process when a warning track interrupt was received which was then not acknowledged within its grace period. Acked-by:
-
Tobias Huschle authored
When a warning track interrupt is received, the kernel has only a very limited amount of time to make sure, that the CPU can be yielded as gracefully as possible before being pre-empted by the hypervisor. The interrupt handler for the wti therefore unparks a kernel thread which has being created on boot re-using the CPU hotplug kernel thread infrastructure. These threads exist per CPU and are assigned the highest possible real-time priority. This makes sure, that said threads will execute as soon as possible as the scheduler should pre-empt any other running user tasks to run the real-time thread. Furthermore, the interrupt handler disables all I/O interrupts to prevent additional interrupt processing on the soon-preempted CPU. Interrupt handlers are likely to take kernel locks, which in the worst case, will be kept while the interrupt handler is pre-empted from itself underlying physical CPU. In that case, all tasks or interrupt handlers on other CPUs would have to wait for the pre-empted CPU being dispatched again. By preventing further interrupt processing, this risk is minimized. Once the CPU gets dispatched again, the real-time kernel thread regains control, reenables interrupts and parks itself again. Acked-by:
-
Tobias Huschle authored
The warning-track interrupt (wti) provides a notification that the receiving CPU will be pre-empted from its physical CPU within a short time frame. This time frame is called grace period and depends on the machine type. Giving up the CPU on time may prevent a task to get stuck while holding a resource. Reviewed-by:
-
Gaosheng Cui authored
The hypfs_dbfs_exit() have been removed since commit 3325b4d8 ("s390/hypfs: factor out filesystem code"), and now it is useless, so remove it. Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Acked-by:
-
Vasily Gorbik authored
The only context where ftrace_enable_ftrace_graph_caller() or ftrace_disable_ftrace_graph_caller() is called also calls ftrace_arch_code_modify_post_process(), which already performs text_poke_sync_lock(). ftrace_run_update_code() arch_ftrace_update_code() ftrace_modify_all_code() ftrace_enable_ftrace_graph_caller()/ftrace_disable_ftrace_graph_caller() ftrace_arch_code_modify_post_process() text_poke_sync_lock() Remove the redundant serialization. Reviewed-by:
-
Vasily Gorbik authored
Use get/copy_from_kernel_nofault to access the kernel text consistently. Replace memcmp() in ftrace_init_nop() to ensure that in case of inconsistencies in the 'mcount' table, the kernel reports a failure instead of potentially crashing. Reviewed-by:
-
Vasily Gorbik authored
When a sequential instruction fetching facility is present, it is safe to patch ftrace NOPs in function prologues. All of them are 8-byte aligned. Reviewed-by:
-
Vasily Gorbik authored
Avoid stop machine on kprobes arm/disarm when sequential instruction fetching is present. Reviewed-by:
-
Vasily Gorbik authored
When sequential instruction fetching facility is present, certain guarantees are provided for code patching. In particular, atomic overwrites within 8 aligned bytes is safe from an instruction-fetching point of view. Reviewed-by:
-
Sven Schnelle authored
In the past two save areas existed because interrupt handlers and system call / program check handlers where entered with interrupts enabled. To prevent a handler from overwriting the save areas from the previous handler, interrupts used the async save area, while system call and program check handler used the sync save area. Since the removal of critical section cleanup from entry.S, handlers are entered with interrupts disabled. When the interrupts are re-enabled, the save area is no longer need. Therefore merge both save areas into one. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
