- 15 Jul, 2016 5 commits
-
-
Sebastian Ott authored
When we fetch channel path descriptors via chsc we use a suboptimal struct chsc_scpd and adjust that by casting the response to a generic chsc_response_struct. Simplify the code by improving struct chsc_scpd. Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Sebastian Ott authored
When fetching channel path descriptors we've only evaluated the rfmt parameter which could lead us to trigger the chsc even though the machine doesn't support the specific format or to not trigger the chsc and report a failure to userspace even though the machine would've supported it. Improve these checks and change the parameters of the in-kernel user to be less confusing. Signed-off-by:
-
Sebastian Ott authored
Not all machines / hypervisors support the chsc commands to fetch the fmt1 descriptor. When these commands fail the channel path would currently not be available to linux. Since users of these descriptors can already deal with invalid data make fetching it optional. The only data that is mandatory for us is the fmt0 channel path descriptor. Also make the return code for missing facilities in chsc_get_channel_measurement_chars consistent to other functions. Signed-off-by:
-
Sebastian Ott authored
Via CHSC_INFO_CU we ought to provide userspace with control unit configuration data. Due to an erroneous request code we trigger the wrong chsc command. Fix this copy and paste error. Signed-off-by:
-
Sebastian Ott authored
Fix an incorrect kernel doc comment in device_ops.c. Also provide proper function markups while at it. Signed-off-by:
-
- 14 Jul, 2016 1 commit
-
-
Sebastian Ott authored
Prior to commit 1bc6664b a call to enable_cmf for a device for which channel measurement was already enabled resulted in a reset of the measurement data. What looked like bugs at the time (a 2nd allocation was triggered but failed, reset was called regardless of previous failures, and errors have not been reported to userspace) was actually something at least one userspace tool depended on. Restore that behavior in a sane way. Fixes: 1bc6664b ("s390/cio: use device_lock during cmb activation") Cc: stable@vger.kernel.org #v4.4+ Signed-off-by:
-
- 13 Jul, 2016 2 commits
-
-
Peter Oberparleiter authored
Use the same code structure when determining preferred consoles for Linux running as KVM guest as with Linux running in LPAR and z/VM guest: - Extend the console_mode variable to cover vt220 and hvc consoles - Determine sensible console defaults in conmode_default() - Remove KVM-special handling in set_preferred_console() Ensure that the sclp line mode console is also registered when the vt220 console was selected to not change existing behavior that someone might be relying on. As an externally visible change, KVM guest users can now select the 3270 or 3215 console devices using the conmode= kernel parameter, provided that support for the corresponding driver was compiled into the kernel. Signed-off-by:
Jing Liu <liujbjl@linux.vnet.ibm.com> Reviewed-by:
-
David Hildenbrand authored
__tlb_flush_asce() should never be used if multiple asce belong to a mm. As this function changes mm logic determining if local or global tlb flushes will be neded, we might end up flushing only the gmap asce on all CPUs and a follow up mm asce flushes will only flush on the local CPU, although that asce ran on multiple CPUs. The missing tlb flushes will provoke strange faults in user space and even low address protections in user space, crashing the kernel. Fixes: 1b948d6c ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by:
Sascha Silbe <silbe@linux.vnet.ibm.com> Acked-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
- 06 Jul, 2016 1 commit
-
-
Gerald Schaefer authored
This adds support for 2GB hugetlbfs pages on s390. Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
- 04 Jul, 2016 2 commits
-
-
Heiko Carstens authored
After linking there are several symbols for the same address that the __switch_to symbol points to. E.g.: 000000000089b9c0 T __kprobes_text_start 000000000089b9c0 T __lock_text_end 000000000089b9c0 T __lock_text_start 000000000089b9c0 T __sched_text_end 000000000089b9c0 T __switch_to When disassembling with "objdump -d" this results in a missing __switch_to function. It would be named __kprobes_text_start instead. To unconfuse objdump add a nop in front of the kprobes text section. That way __switch_to appears again. Obviously this solution is sort of a hack, since it also depends on link order if this works or not. However it is the best I can come up with for now. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Expose the maximum thread id with /proc/cpuinfo. With the new line the output looks like this: vendor_id : IBM/S390 bogomips per cpu: 20325.00 max thread id : 1 With this new interface it is possible to always tell the correct number of cpu threads potentially being used by the kernel. Signed-off-by:
-
- 28 Jun, 2016 19 commits
-
-
Martin Schwidefsky authored
The bits single_step and instruction_fetch lost their meaning with git commit 5e9a2692 "[S390] ptrace cleanup". Clarify the comment for these two bits. Signed-off-by:
-
Heiko Carstens authored
Avoid using the address of a process' thread_info structure as the kernel stack address. This will break as soon as the thread_info structure will be removed from the stack, and in addition it makes the code a bit more understandable. Signed-off-by:
-
Heiko Carstens authored
Remove a leftover from the code that transferred a couple of TIF bits from the previous task to the next task. Signed-off-by:
-
Heiko Carstens authored
Now that hopefully all inline assemblies have been converted to single basic blocks we can enable kcov on s390. Note that this patch does not disable as many files on s390 like the x86 variant does. Right now I didn't see a reason to do that, however additional files or directories can be excluded at any time. The runtime overhead seems to be quite high. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
Use only simple inline assemblies which consist of a single basic block if the register asm construct is being used. Otherwise gcc would generate broken code if the compiler option --sanitize-coverage=trace-pc would be used. Signed-off-by:
-
Heiko Carstens authored
The __put_get_user_asm defines an inline assmembly which makes use of the asm register construct. The parameters passed to that define may also contain function calls. It is a gcc restriction that between register asm statements and the use of any such annotated variables function calls may clobber the register / variable contents. Or in other words: gcc would generate broken code. This can be achieved e.g. with the following code: get_user(x, func() ? a : b); where the call of func would clobber register zero which is used by the __put_get_user_asm define. To avoid this add two static inline functions which don't have these side effects. Signed-off-by: -
Heiko Carstens authored
The cpu field name within /proc/cpuinfo has a conflict with the powerpc and sparc output where it contains the cpu model name. So rename the field name to cpu number which shouldn't generate any conflicts. Signed-off-by:
-
Heiko Carstens authored
Now that the oprofile sampling code is gone there is only one user of the sampling facility left. Therefore the reserve and release functions can be removed. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Remove hardware sampler support from oprofile module. The oprofile user space utilty has been switched to use the kernel perf interface, for which we also provide hardware sampling support. In addition the hardware sampling support is also slightly broken: it supports only 16 bits for the pid and therefore would generate wrong results on machines which have a pid >64k. Also the pt_regs structure which was passed to oprofile common code cannot necessarily be used to generate sane backtraces, since the task(s) in question may run while the samples are fed to oprofile. So the result would be more or less random. However given that the only user space tools switched to the perf interface already four years ago the hardware sampler code seems to be unused code, and therefore it should be reasonable to remove it. The timer based oprofile support continues to work. Signed-off-by:
Andreas Arnez <arnez@linux.vnet.ibm.com> Acked-by:
Andreas Krebbel <krebbel@linux.vnet.ibm.com> Acked-by:
Robert Richter <rric@kernel.org> Reviewed-by:
-
- 15 Jun, 2016 4 commits
-
-
Heiko Carstens authored
The last in-kernel user is gone so we can finally remove this code. Reviewed-by:
-
Heiko Carstens authored
Implement calculation of loops_per_jiffies with fp instructions which are available on all 64 bit machines. To save and restore floating point register context use the new vx support functions. Reviewed-by:
-
Hendrik Brueckner authored
Signed-off-by:
-
Hendrik Brueckner authored
Add a crypto API module to access the vector extension based CRC-32 implementations. Users can request the optimized implementation through the shash crypto API interface. Signed-off-by:
-
- 14 Jun, 2016 3 commits
-
-
Hendrik Brueckner authored
Use vector instructions to optimize the computation of CRC-32 checksums. An optimized version is provided for CRC-32 (IEEE 802.3 Ethernet) in normal and bitreflected domain, as well as, for bitreflected CRC-32C (Castagnoli). Signed-off-by:
-
Hendrik Brueckner authored
Introduce the kernel_fpu_begin() and kernel_fpu_end() function to enclose any in-kernel use of FPU instructions and registers. In enclosed sections, you can perform floating-point or vector (SIMD) computations. The functions take care of saving and restoring FPU register contents and controls. For usage details, see the guidelines in arch/s390/include/asm/fpu/api.h Signed-off-by:
-
Heiko Carstens authored
The usual problem for code that is ifdef'ed out is that it doesn't compile after a while. That's also the case for the storage key initialisation code, if it would be used (set PAGE_DEFAULT_KEY to something not zero): ./arch/s390/include/asm/page.h: In function 'storage_key_init_range': ./arch/s390/include/asm/page.h:36:2: error: implicit declaration of function '__storage_key_init_range' Since the code itself has been useful for debugging purposes several times, remove the ifdefs and make sure the code gets compiler coverage. The cost for this is eight bytes. Signed-off-by:
-
- 13 Jun, 2016 3 commits
-
-
Heiko Carstens authored
I don't have a z10 to test this anymore, so I have no idea if the code works at all or even crashes. I can try to emulate, but it is just guess work. Nor do we know if the z10 special handling is performance wise still better than the generic handling. There have been a lot of changes to the scheduler. Therefore let's play safe and remove the special handling. Signed-off-by:
-
Heiko Carstens authored
The z13 machine added a fourth level to the cpu topology information. The new top level is called drawer. A drawer contains two books, which used to be the top level. Adding this additional scheduling domain did show performance improvements for some workloads of up to 8%, while there don't seem to be any workloads impacted in a negative way. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Heiko Carstens authored
The s390 cpu topology gained another hierarchy level. The top level is now called drawer and contains several books. A book used to be the top level. In order to expose the cpu topology to user space allow to create new sysfs attributes dependent on CONFIG_SCHED_DRAWER which an architecture may define and select. These additional attributes will be available: /sys/devices/system/cpu/cpuX/topology/drawer_id /sys/devices/system/cpu/cpuX/topology/drawer_siblings /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list Signed-off-by:
-
