- 09 Oct, 2017 4 commits
-
-
Martin Schwidefsky authored
Add the store-hypervisor-information code into features using a tip branch for parallel merging into the KVM tree.
-
QingFeng Hao authored
Add a syscall of s390_sthyi to implement STHYI instruction in LPAR which reuses the implementation for KVM by Janosch Frank - commit 95ca2cb5 ("KVM: s390: Add sthyi emulation"). STHYI(Store Hypervisor Information) is an emulated z/VM instruction that provides a guest with basic information about the layers it is running on. This includes information about the cpu configuration of both the machine and the lpar, as well as their names, machine model and machine type. This information enables an application to determine the maximum capacity of CPs and IFLs available to software. For the arguments of s390_sthyi, code shall be 0 and flags is reserved for future use, info is the output argument to store the required hypervisor info. Signed-off-by:
QingFeng Hao <haoqf@linux.vnet.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
QingFeng Hao authored
STHYI requires extensive locking in the higher hypervisors and is very computational/memory expensive. Therefore we cache the retrieved hypervisor info whose valid period is 1s with mutex to allow concurrent access. rw semaphore can't benefit here due to cache line bounce. Signed-off-by:
-
QingFeng Hao authored
As we need to support sthyi instruction on LPAR too, move the common code to kernel part and kvm related code to intercept.c for better reuse. Signed-off-by:
-
- 04 Oct, 2017 1 commit
-
-
Heiko Carstens authored
We never optimized our rwsem inline assemblies to make use of the new atomic instructions. The generic rwsem implementation implicitly makes use of the new instructions, since it implements the required rwsem primitives with atomic operations, which we did optimize. However even when compiling for old architectures the generic variant still generates better code. So it's time to simply remove our old code and switch to the generic implementation. Signed-off-by:
-
- 29 Sep, 2017 11 commits
-
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
This instruction came with a z/VM extension and not with a specific machine generation. Signed-off-by:
-
Heiko Carstens authored
Remove a couple of instructions that are listed twice. Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
The e7 opcode table does not have an end marker. Hence when trying to find an unknown e7 instruction the code will access memory behind the table until it finds something that matches the opcode, or the kernel crashes, whatever comes first. This affects not only the in-kernel disassembler but also uprobes and kprobes which refuse to set a probe on unknown instructions, and therefore search the opcode tables to figure out if instructions are known or not. Cc: <stable@vger.kernel.org> # v3.18+ Fixes: 3585cb02 ("s390/disassembler: add vector instructions") Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Thomas Huth authored
There is no recent user space application available anymore which still supports this old virtio transport. Additionally, commit 3b2fbb3f ("virtio/s390: deprecate old transport") introduced a deprecation message in the driver, and apparently nobody complained so far that it is still required. So let's simply remove it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Acked-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
When grouping devices, the ccwgroup core only checks whether all of the devices are bound to the same ccw_driver. It has no means of checking if the requesting ccwgroup driver actually supports this device type. qeth implements its own device matching in qeth_core_probe_device(), while ctcm and lcs currently have no sanity-checking at all. Enable ccwgroup drivers to optionally defer the device type checking to the ccwgroup core, by specifying their supported ccw_driver. This allows us drop the device type matching from qeth, and improves the robustness of ctcm and lcs. Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Acked-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
-
Harald Freudenberger authored
This patch introduces gcm(aes) support into the aes_s390 kernel module. Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
-
Patrick Steuer authored
Signed-off-by:
-
- 28 Sep, 2017 24 commits
-
-
Martin Schwidefsky authored
Like the common queued rwlock code the s390 implementation uses the queued spinlock code on a spinlock_t embedded in the rwlock_t to achieve the queueing. The encoding of the rwlock_t differs though, the counter field in the rwlock_t is split into two parts. The upper two bytes hold the write bit and the write wait counter, the lower two bytes hold the read counter. The arch_read_lock operation works exactly like the common qrwlock but the enqueue operation for a writer follows a diffent logic. After the failed inline try to get the rwlock in write, the writer first increases the write wait counter, acquires the wait spin_lock for the queueing, and then loops until there are no readers and the write bit is zero. Without the write wait counter a CPU that just released the rwlock could immediately reacquire the lock in the inline code, bypassing all outstanding read and write waiters. For s390 this would cause massive imbalances in favour of writers in case of a contended rwlock. Signed-off-by: -
Martin Schwidefsky authored
The queued spinlock code for s390 follows the principles of the common code qspinlock implementation but with a few notable differences. The format of the spinlock_t locking word differs, s390 needs to store the logical CPU number of the lock holder in the spinlock_t to be able to use the diagnose 9c directed yield hypervisor call. The inline code sequences for spin_lock and spin_unlock are nice and short. The inline portion of a spin_lock now typically looks like this: lhi %r0,0 # 0 indicates an empty lock l %r1,0x3a0 # CPU number + 1 from lowcore cs %r0,%r1,<some_lock> # lock operation jnz call_wait # on failure call wait function locked: ... call_wait: la %r2,<some_lock> brasl %r14,arch_spin_lock_wait j locked A spin_unlock is as simple as before: lhi %r0,0 sth %r0,2(%r2) # unlock operation After a CPU has queued itself it may not enable interrupts again for the arch_spin_lock_flags() variant. The arch_spin_lock_wait_flags wait function is removed. To improve performance the code implements opportunistic lock stealing. If the wait function finds a spinlock_t that indicates that the lock is free but there are queued waiters, the CPU may steal the lock up to three times without queueing itself. The lock stealing update the steal counter in the lock word to prevent more than 3 steals. The counter is reset at the time the CPU next in the queue successfully takes the lock. While the queued spinlocks improve performance in a system with dedicated CPUs, in a virtualized environment with continuously overcommitted CPUs the queued spinlocks can have a negative effect on performance. This is due to the fact that a queued CPU that is preempted by the hypervisor will block the queue at some point even without holding the lock. With the classic spinlock it does not matter if a CPU is preempted that waits for the lock. Therefore use the queued spinlock code only if the system runs with dedicated CPUs and fall back to classic spinlocks when running with shared CPUs. Signed-off-by: -
Martin Schwidefsky authored
The queued spinlock code will come out simpler if the encoding of the CPU that holds the spinlock is (cpu+1) instead of (~cpu). Signed-off-by: -
Martin Schwidefsky authored
The topology information returned by STSI 15.x.x contains a flag if the CPUs of a topology-list are dedicated or shared. Make this information available if the machine provides topology information. Signed-off-by: -
Himanshu Jha authored
Use setup_timer and mod_timer API instead of structure assignments. This is done using Coccinelle and semantic patch used for this as follows: @@ expression x,y,z,a,b; @@ -init_timer (&x); +setup_timer (&x, y, z); +mod_timer (&a, b); -x.function = y; -x.data = z; -x.expires = b; -add_timer(&a); Signed-off-by:
Himanshu Jha <himanshujha199640@gmail.com> Signed-off-by:
-
Heiko Carstens authored
Paul Burton reported that the nr_cpumask_bits check within cpumsf_pmu_event_init() is not necessary. Actually there is already a prior check within perf_event_alloc(). Therefore remove the check. Reported-by:
Paul Burton <paul.burton@imgtec.com> Signed-off-by:
-
Harald Freudenberger authored
The function to prepare MEX type 50 ap messages did not explicitly check for the data length in case of data > 512 bytes. Instead the function assumes the boundary check done in the ioctl function will always reject requests with invalid data length values. However, screening just the function code may give the illusion, that there may be a gap which could be exploited by userspace for buffer overwrite attacks. Signed-off-by:
-
Sebastian Ott authored
Instead of open coding tod clock to ns conversions use the timex helper. Signed-off-by:
-
Sebastian Ott authored
All (but one) cmf related sysfs attributes have been converted to read directly from the measurement block using cmf_read. This is not possible for the avg_utilization attribute since this is an aggregation of several values for which cmf_read only returns average values. Move the computation of the utilization value to the cmf_read interface such that it can use the raw data. Signed-off-by:
-
Sebastian Ott authored
To ensure data consistency when reading from the channel measurement block we wait for the subchannel to become idle and copy the whole block. This is unnecessary when all we do is export the individual values via sysfs. Read the values for sysfs export directly from the measurement block. Signed-off-by:
-
Sebastian Ott authored
cmf_copy_block tries to ensure data consistency by copying the channel measurement block twice and comparing the data. This was needed on very old machines only. Nowadays we guarantee consistency by copying the data when the channel is idle. Signed-off-by:
-
Sebastian Ott authored
No need for refcounting - the data can be on stack. Also change the locking in this function to only use spin_lock_irq (the function waits, thus it's never called from IRQ context). Signed-off-by:
-
Sebastian Ott authored
No need for refcounting - the data can be on stack. Signed-off-by:
-
Sebastian Ott authored
When enabling channel measurement fails with a busy condition we wait for the next interrupt to arrive before we retry the operation. For devices which usually don't create interrupts we wait forever. Although the waiting is done interruptible that behavior is not expected and confused some users. Abort the operation after a 10s timeout. Signed-off-by:
-
Jean Delvare authored
Function cdev_add does set cdev->dev, so there is no point in setting it prior to calling this function. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Johannes Thumshirn authored
Add info prints in sample kprobe handlers for S/390 Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Alice Frosi authored
Add runtime instrumention register get and set which allows to read and modify the runtime instrumention control block. Signed-off-by:
Alice Frosi <alice@linux.vnet.ibm.com> Signed-off-by:
-
Alice Frosi authored
Update runtime_instr_cb structure to be consistent with the runtime instrumentation documentation. Signed-off-by:
-
Heiko Carstens authored
This is the quite trivial backend for s390 which is required to enable FORTIFY_SOURCE support. See commit 6974f0c4 ("include/linux/string.h: add the option of fortified string.h functions") for more details. Signed-off-by:
-
Heiko Carstens authored
exit_thread() is empty now. Therefore remove it and get rid of a pointless branch. Signed-off-by:
-
Heiko Carstens authored
Free data structures required for guarded storage from arch_release_task_struct(). This allows to simplify the code a bit, and also makes the semantics a bit easier: arch_release_task_struct() is never called from the task that is being removed. In addition this allows to get rid of exit_thread() in a later patch. Signed-off-by:
-
Heiko Carstens authored
If the guarded storage regset for current is supposed to be changed, the regset from user space is copied directly into the guarded storage control block. If then the process gets scheduled away while the control block is being copied and before the new control block has been loaded, the result is random: the process can be scheduled away due to a page fault or preemption. If that happens the already copied parts will be overwritten by save_gs_cb(), called from switch_to(). Avoid this by copying the data to a temporary buffer on the stack and do the actual update with preemption disabled. Fixes: f5bbd721 ("s390/ptrace: guarded storage regset for the current task") Signed-off-by:
-
Heiko Carstens authored
For PREEMPT enabled kernels the guarded storage (GS) code contains a possible use-after-free bug. If a task that makes use of GS exits, it will execute do_exit() while still enabled for preemption. That function will call exit_thread_runtime_instr() via exit_thread(). If exit_thread_gs() gets preempted after the GS control block of the task has been freed but before the pointer to it is set to NULL, then save_gs_cb(), called from switch_to(), will write to already freed memory. Avoid this and simply disable preemption while freeing the control block and setting the pointer to NULL. Fixes: 916cda1a ("s390: add a system call for guarded storage") Cc: <stable@vger.kernel.org> # v4.12+ Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Free data structures required for runtime instrumentation from arch_release_task_struct(). This allows to simplify the code a bit, and also makes the semantics a bit easier: arch_release_task_struct() is never called from the task that is being removed. In addition this allows to get rid of exit_thread() in a later patch. Signed-off-by:
-
