- 01 Mar, 2019 6 commits
-
-
Martin Schwidefsky authored
The dasd_eckd_restore_device() function calls dasd_generic_read_dev_chars with a temporary buffer on the stack. With CONFIG_VMAP_STACK=y this is a vmalloc address but dasd_generic_restore_device() uses the address of the buffer as I/O address. Circumvent this by using the already allocated cqr->data buffer for the RDC data. Signed-off-by:Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Martin Schwidefsky authored
The reset of the prefix to zero in swsusp_arch_resume uses a 4 byte stack slot. With CONFIG_VMAP_STACK=y this is now in the vmalloc area, this works only with DAT enabled. Move the DAT disable in swsusp_arch_resume after the prefix reset. Signed-off-by: -
Vasily Gorbik authored
Add a warning about removing required architecture level set facilities via "facilities=" command line option. Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
Add "facilities=" command line option which allows to override facility bits returned by stfle. The main purpose of that is debugging aids which allows to test specific kernel behaviour depending on specific facilities presence. It also affects CPU alternatives. "facilities=" command line option format is comma separated list of integer values to be additionally set or cleared (if value is starting with "!"). Values ranges are also supported. e.g.: facilities=!130-160,159,167-169 Reviewed-by:
-
Vasily Gorbik authored
Facilities list in the lowcore is initially set up by verify_facilities from als.c and later initializations are redundant, so cleaning them up. Reviewed-by:
-
Vasily Gorbik authored
Reuse __stfle call instead of in-place implementation. __stfle is using memcpy and memset functions but they are safe to use, since mem.S is built with -march=z900. Reviewed-by:
-
- 27 Feb, 2019 1 commit
-
-
Martin Schwidefsky authored
Merge tag 'vfio-ccw-20190227' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features Pull vfio-ccw from Cornelia Huck with the following changes: - Further fixes in TIC handling.
-
- 26 Feb, 2019 2 commits
-
-
Eric Farman authored
Since we have a little function to see whether a channel program address falls within a range of CCWs, let's use it in the other places of code that make these checks. (Why isn't ccw_head fully removed? Well, because this way some longs lines don't have to be reflowed.) Signed-off-by:
Eric Farman <farman@linux.ibm.com> Message-Id: <20190222183941.29596-3-farman@linux.ibm.com> Reviewed-by:
Farhan Ali <alifm@linux.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Eric Farman authored
The routine ccwchain_calc_length() is tasked with looking at a channel program, seeing how many CCWs are chained together by the presence of the Chain-Command flag, and returning a count to the caller. Previously, it also considered a Transfer-in-Channel CCW as being an appropriate mechanism for chaining. The problem at the time was that the TIC CCW will almost certainly not go to the next CCW in memory (because the CC flag would be sufficient), and so advancing to the next 8 bytes will cause us to read potentially invalid memory. So that comparison was removed, and the target of the TIC is processed as a new chain. This is fine when a TIC goes to a new chain (consider a NOP+TIC to a channel program that is being redriven), but there is another scenario where this falls apart. A TIC can be used to "rewind" a channel program, for example to find a particular record on a disk with various orientation CCWs. In this case, we DO want to consider the memory after the TIC since the TIC will be skipped once the requested criteria is met. This is due to the Status Modifier presented by the device, though software doesn't need to operate on it beyond understanding the behavior change of how the channel program is executed. So to handle this, we will re-introduce the check for a TIC CCW but limit it by examining the target of the TIC. If the TIC doesn't go back into the current chain, then current behavior applies; we should stop counting CCWs and let the target of the TIC be handled as a new chain. But, if the TIC DOES go back into the current chain, then we need to keep looking at the memory after the TIC for when the channel breaks out of the TIC loop. We can't use tic_target_chain_exists() because the chain in question hasn't been built yet, so we will redefine that comparison with some small functions to make it more readable and to permit refactoring later. Fixes: 405d566f ("vfio-ccw: Don't assume there are more ccws after a TIC") Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
-
- 22 Feb, 2019 15 commits
-
-
Pierre Morel authored
Libudev relies on having a subsystem link for non-root devices. To avoid libudev (and potentially other userspace tools) choking on the matrix device let us introduce a matrix bus and with it the matrix bus subsytem. Also make the matrix device reside within the matrix bus. Doing this we remove the forced link from the matrix device to the vfio_ap driver and the device_type we do not need anymore. Since the associated matrix driver is not the vfio_ap driver any more, we have to change the search for the devices on the vfio_ap driver in the function vfio_ap_verify_queue_reserved. Fixes: 1fde5734 ("s390: vfio-ap: base implementation of VFIO AP device driver") Cc: stable@vger.kernel.org Reported-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Pierre Morel <pmorel@linux.ibm.com> Tested-by:
Tony Krowiak <akrowiak@linux.ibm.com> Acked-by:
-
Thomas Richter authored
Rservation of the CPU Measurement Counter facility may fail if it is already in use by the cf_diag device driver. This is indicated by a non zero return code (-EBUSY). However this return code is ignored and the counter facility may be used in parallel by different device drivers. Handle the failing reservation and return an error to the caller. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
The CPU Measurement facility for counters and counter set rework adds a few new kernel messages to the system log. Add an explanation for some of these. Signed-off-by:
-
Thomas Richter authored
Introduce a PMU device named cpum_cf_diag. It extracts the values of all counters in all authorized counter sets and stores them as event raw data. This is done with the STORE CPU COUNTER MULTIPLE instruction to speed up access. All counter sets fit into one buffer. The values of each counter are taken when the event is started on the performance sub-system and when the event is stopped. This results in counter values available at the start and at the end of the measurement time frame. The difference is calculated for each counter. The differences of all counters are then saved as event raw data in the perf.data file. The counter values are accompanied by the time stamps when the counter set was started and when the counter set was stopped. This data is part of a trailer entry which describes the time frame, counter set version numbers, CPU speed, and machine type for later analysis. Signed-off-by:
Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by:
-
Hendrik Brueckner authored
Introduce the ctr_stcctm() function as wrapper function to extract counters from a particular counter set. Note that the counter set is part of the stcctm instruction opcode, few indirections are necessary to specify the counter set as variable. Signed-off-by:
-
Hendrik Brueckner authored
Move common functions of the couter facility support into a separate file. Signed-off-by:
-
Hendrik Brueckner authored
A preparation to move out common CPU-MF counter facility support functions, first introduce a function that indicates whether the support is ready to use. Signed-off-by:
-
Hendrik Brueckner authored
Remove the stcctm5() function to extract counters from the MT-diagnostic counter set with the stcctm() function. For readability, introduce an enum to map the counter sets names to respective numbers for the stcctm instruction. Signed-off-by:
-
Hendrik Brueckner authored
Add support for the STORE CPU COUNTER MULTIPLE instruction to extract a range of counters from a counter set. An assembler macro is used to create the instruction opcode because the counter set identifier is part of the instruction and, thus, cannot be easily specified as parameter. Signed-off-by:
-
Hendrik Brueckner authored
Introduce a minimal interface for doing counter measurements of small units of work within the kernel. Use the kernel_cpumcf_begin() function start a measurement session and, later, stop it with kernel_cpumcf_end(). During the measreument session, you can enable and start/stop counter sets by using ctr_set_* functions. To make these changes effective use the lcctl() function. You can then use the ecctr() function to extract counters from the different counter sets. Please note that you have to check whether the counter sets to be enabled are authorized. Note that when a measurement session is active, other users cannot perform counter measurements. In such cases, kernel_cpumcf_begin() indicates this with returning -EBUSY. If the counter facility is not available, kernel_cpumcf_begin() returns -ENODEV. Note that this interface is restricted to the current CPU and, thus, preemption must be turned off. Example: u32 state, err; u64 cycles, insn; err = kernel_cpumcf_begin(); if (err) goto out_busy; state = 0; ctr_set_enable(&state, CPUMF_CTR_SET_BASIC); ctr_set_start(&state, CPUMF_CTR_SET_BASIC); err = lcctl(state); if (err) goto ; /* ... do your work ... */ ctr_set_stop(&state, CPUMF_CTR_SET_BASIC); err = lcctl(state); if (err) goto out; cycles = insn = 0; ecctr(0, &cycles); ecctr(1, &insn); /* ... */ kernel_cpumcf_end(); out_busy: Signed-off-by:
-
Hendrik Brueckner authored
During a __kernel_cpumcf_begin()/end() session, save measurement alerts for the counter facility in the per-CPU cpu_cf_events variable. Users can obtain and, optionally, clear the alerts by calling kernel_cpumcf_alert() to specifically handle alerts. Signed-off-by:
-
Hendrik Brueckner authored
Make the struct cpu_cf_events and the respective per-CPU variable available to in-kernel users. Access to this per-CPU variable shall be done between the calls to __kernel_cpumcf_begin() and __kernel_cpumcf_end(). Signed-off-by:
-
Hendrik Brueckner authored
Rename the struct cpu_hw_events to cpu_cf_events and also the respective per-CPU variable to make its name more clear. No functional changes. Signed-off-by:
-
Hendrik Brueckner authored
Prepare the counter facility support to be used by other in-kernel users. The first step introduces the __kernel_cpumcf_begin() and __kernel_cpumcf_end() functions to reserve the counter facility for doing measurements and to release after the measurements are done. Signed-off-by:
-
Hendrik Brueckner authored
Move counter set specific controls and functions to the asm/cpu_mcf.h header file containg all counter facility support definitions. Also adapt few variable names and header file includes. No functional changes. Signed-off-by:
-
- 21 Feb, 2019 3 commits
-
-
Gerald Schaefer authored
The DCSS range is currently printed with %p, which results in hashed values instead of the actual addresses. Use %px instead, the DCSS ranges do not reveal any kernel symbol addresses. Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
All supported releases of z/VM allow 64 bit subcodes and addressing mode for diag 0x64. This patch removes a lot of code for handling 31 bit addressing mode and old subcodes. Signed-off-by:
-
Ingo Franzki authored
When the CCA master key is set twice with the same master key, then the old and the current master key are the same and thus the verification patterns are the same, too. The check to report if a secure key is currently wrapped by the old master key erroneously reports old mkvp in this case. Reviewed-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by:
-
- 20 Feb, 2019 4 commits
-
-
Sebastian Ott authored
Prior to dma unmap/free operations the ism driver tries to ensure that the memory is no longer accessed by the HW. When errors during deregistration of memory regions from the HW occur the ism driver will not unmap/free this memory. When we receive notification from the hypervisor that a PCI function has been detached we can no longer access the device and would never unmap/free these memory regions which led to complaints by the DMA debug API. Treat this kind of errors during the deregistration of memory regions from the HW as success since it is already ensured that the memory is no longer accessed by HW. Reported-by:
Karsten Graul <kgraul@linux.ibm.com> Reported-by:
Hans Wippel <hwippel@linux.ibm.com> Signed-off-by:
Sebastian Ott <sebott@linux.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
The fix to make WARN work in the early boot code created a problem on older machines without EDAT-1. The setup_lowcore_dat_on function uses the pointer from lowcore_ptr[0] to set the DAT bit in the new PSWs. That does not work if the kernel page table is set up with 4K pages as the prefix address maps to absolute zero. To make this work the PSWs need to be changed with via address 0 in form of the S390_lowcore definition. Reported-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
-
Martin Schwidefsky authored
The setup_lowcore() function creates a new prefix page for the boot CPU. The PSW mask for the system_call, external interrupt, i/o interrupt and the program check handler have the DAT bit set in this new prefix page. At the time setup_lowcore is called the system still runs without virtual address translation, the paging_init() function creates the kernel page table and loads the CR13 with the kernel ASCE. Any code between setup_lowcore() and the end of paging_init() that has a BUG or WARN statement will create a program check that can not be handled correctly as there is no kernel page table yet. To allow early WARN statements initially setup the lowcore with DAT off and set the DAT bit only after paging_init() has completed. Cc: stable@vger.kernel.org Signed-off-by: -
Ilya Leoshkevich authored
[heiko.carstens@de.ibm.com]: ----- Laura Abbott reported that the kernel doesn't build anymore with gcc 9, due to the "X" constraint. Ilya provided the gcc 9 patch "S/390: Introduce jdd constraint" which introduces the new "jdd" constraint which fixes this. ----- The support for section anchors on S/390 introduced in gcc9 has changed the behavior of "X" constraint, which can now produce register references. Since existing constraints, in particular, "i", do not fit the intended use case on S/390, the new machine-specific "jdd" constraint was introduced. This patch makes jump labels use "jdd" constraint when building with gcc9. Reported-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
-
- 13 Feb, 2019 1 commit
-
-
Harald Freudenberger authored
When an alternate driver (vfio-ap) has bound an ap queue and this binding is revised the ap queue device is in an intermittent state not bound to any driver. The internal state variable covered this with the state AP_STATE_BORKED which is also used to reflect broken devices. When now an ap bus scan runs such a device is destroyed and on the next scan reconstructed. So a stress test with high frequency switching the queue driver between the default and the vfio-ap driver hit this gap and the queue was removed until the next ap bus scan. This fix now introduces another state for the in-between condition for a queue momentary not bound to a driver and so the ap bus scan function skips this device instead of removing it. Also some very slight but maybe helpful debug feature messages come with this patch - in particular a message showing that a broken card/queue device will get removed. Signed-off-by:
-
- 07 Feb, 2019 8 commits
-
-
Martin Schwidefsky authored
Merge tag 'vfio-ccw-20190204' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features Pull vfio-ccw from Cornelia Huck with the following changes: - A fix in ccw chain processing.
-
Martin Schwidefsky authored
The z14 introduced alignment hints to increase the performance of vector loads and stores. The kernel uses an implicit alignmenet of 8 bytes for the vector registers, set the alignment hint to 3. Reviewed-by:
-
YueHaibing authored
Remove including <linux/version.h> that don't need it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Julian Wiedmann authored
There is no need to use void pointers, all drivers are in agreement about the underlying data structure of the SBAL arrays. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
-
Sebastian Ott authored
Map IOV resources such that pci common code recognizes the IOV capability of PFs. Signed-off-by:
-
Sebastian Ott authored
Improve the bar check in pci_iomap_range to cover functions for which we recognize more bars than what we can access due to AR restrictions. Signed-off-by:
-
Martin Schwidefsky authored
The s390 version of the mmap_base function is ignorant of stack_guard_gap which can lead to a placement of the stack vs. the mmap base that does not leave enough space for the stack rlimit. Add the stack_guard_gap to the calculation and while we are at it the check for gap+pad overflows as well. Reviewed-by:
-
Gerald Schaefer authored
Remove some dead code from head64.S, which was left over since commit da292bbe ("[S390] eliminate ipl_device from lowcore") removed ipl_device from lowcore. Reviewed-by:
-
