- 27 Apr, 2017 1 commit
-
-
Martin Schwidefsky authored
Merge branch 's390forkvm' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into features Pull cpacf changes for KVM from Jason Herne: Add query support for the KMA instruction.
-
- 26 Apr, 2017 8 commits
-
-
Harald Freudenberger authored
For automatic module loading (e.g. as it is used with cryptsetup) an alias "paes" for the paes_s390 kernel module is needed. Correct the paes_s390 module alias from "aes-all" to "paes". Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Jason J. Herne authored
Provide a kma instruction definition for use by callers of __cpacf_query. Signed-off-by:
Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Jason J. Herne authored
The new KMA instruction requires unique parameters. Update __cpacf_query to generate a compatible assembler instruction. Signed-off-by:
-
Harald Freudenberger authored
This patch introduces a new device driver s390-trng for the s390 platform which exploits the new PRNO TRNG cpacf subfunction. The true-random-number-generator is accessible from userspace, by default visible as /dev/trng. The driver also registers at the kernel build-in hwrng API to feed the hwrng with fresh entropy data. This generic device driver for hardware random data is visible from userspace as /dev/hwrng. Signed-off-by:
-
Harald Freudenberger authored
This patch introduces s390 specific arch random functionality. There exists a generic kernel API for arch specific random number implementation (see include/linux/random.h). Here comes the header file and a very small static code part implementing the arch_random_* API based on the TRNG subfunction coming with the reworked PRNG instruction. The arch random implementation hooks into the kernel initialization and checks for availability of the TRNG function. In accordance to the arch random API all functions return false if the TRNG is not available. Otherwise the new high quality entropy source provides fresh random on each invocation. The s390 arch random feature build is controlled via CONFIG_ARCH_RANDOM. This config option located in arch/s390/Kconfig is enabled by default and appears as entry "s390 architectural random number generation API" in the submenu "Processor type and features" for s390 builds. Signed-off-by:
-
Harald Freudenberger authored
There is a new TRNG extension in the subcodes for the cpacf PRNO function. This patch introduces new defines and a new cpacf_trng inline function to provide these new features for other kernel code parts. Signed-off-by:
-
Harald Freudenberger authored
The PPNO (Perform Pseudorandom Number Operation) instruction has been renamed to PRNO (Perform Random Number Operation). To avoid confusion and conflicts with future extensions with this instruction (like e.g. provide a true random number generator) this patch renames all occurences in cpacf.h and adjusts the only exploiter code which is the prng device driver and one line in the s390 kvm feature check. Signed-off-by:
-
Heiko Carstens authored
The kernel page table splitting code will split page tables even for features the CPU does not support. E.g. a CPU may not support the NX feature. In order to avoid this, remove those bits from the flags parameter that correlate with unsupported CPU features within __set_memory(). In addition add an early exit if the flags parameter does not have any bits set afterwards. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
- 25 Apr, 2017 2 commits
-
-
Martin Schwidefsky authored
With TASK_SIZE now reflecting the maximum size of the address space for a process the code for arch_get_unmapped_area[_topdown] can be simplified. Just let the logic pick a suitable address and deal with the page table upgrade after the address has been selected. Signed-off-by: -
Martin Schwidefsky authored
The TASK_SIZE for a process should be maximum possible size of the address space, 2GB for a 31-bit process and 8PB for a 64-bit process. The number of page table levels required for a given memory layout is a consequence of the mapped memory areas and their location. Signed-off-by:
-
- 24 Apr, 2017 1 commit
-
-
Martin Schwidefsky authored
Merge tag 'vfio-ccw-20170413' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features Pull vfio-ccw fixes from Cornelia Huck: Two fixes for the new vfio-ccw support.
-
- 21 Apr, 2017 1 commit
-
-
Martin Schwidefsky authored
The guarded storage interface allows to register a control block for each thread that is activated with the guarded storage broadcast event. To retrieve the complete state of a process from the kernel a register set for the stored broadcast control block is required. Signed-off-by:
-
- 20 Apr, 2017 2 commits
-
-
Claudio Imbrenda authored
Add use_cmma field to mm_context_t, like we do for storage keys. Signed-off-by:
Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Acked-by:
Janosch Frank <frankja@de.ibm.com> Reviewed-by:
-
Claudio Imbrenda authored
Add PGSTE manipulation functions: * set_pgste_bits sets specific bits in a PGSTE * get_pgste returns the whole PGSTE * pgste_perform_essa manipulates a PGSTE to set specific storage states * ESSA_[SG]ET_* macros used to indicate the action for manipulate_pgste Signed-off-by:
-
- 12 Apr, 2017 4 commits
-
-
Dong Jia Shi authored
When vfio_ccw_mdev_reset fails during the remove process of the mdev, the current implementation simply returns. The failure indicates that the subchannel device is in a NOT_OPER state, thus the right thing to do should be removing the mdev. While we are at here, reverse the condition check to make the code more concise and readable. Signed-off-by:
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170412090816.79108-3-bjsdjshi@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com>
-
Dong Jia Shi authored
Remove several unnecessary checks for the @private pointer, since it can never be NULL in these places. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Martin Schwidefsky authored
The CAD instruction never worked quite as expected for the spinlock code. It has been disabled by default with git commit 61b0b016, if the "cad" kernel parameter is specified it is enabled for both user space and the spinlock code. Leave the option to enable the instruction for user space but remove it from the spinlock code. Signed-off-by:
-
Martin Schwidefsky authored
Add a couple more __atomic_xxx function to atomic_ops.h and use them to replace the compare-and-swap inlines in the spinlock code. This changes the type of the lock value from unsigned int to int. Signed-off-by:
-
- 05 Apr, 2017 7 commits
-
-
Martin Schwidefsky authored
There are three different code levels in regard to the identification of guest samples. They differ in the way the LPP instruction is used. 1) Old kernels without the LPP instruction. The guest program parameter is always zero. 2) Newer kernels load the process pid into the program parameter with LPP. The guest program parameter is non-zero if the guest executes in a process != idle. 3) The latest kernels load ((1UL << 31) | pid) with LPP to make the value non-zero even for the idle task. The guest program parameter is non-zero if the guest is running. All kernels load the process pid to CR4 on context switch. The CPU sampling code uses the value in CR4 to decide between guest and host samples in case the guest program parameter is zero. The three cases: 1) CR4==pid, gpp==0 2) CR4==pid, gpp==pid 3) CR4==pid, gpp==((1UL << 31) | pid) The load-control instruction to load the pid into CR4 is expensive and the goal is to remove it. To distinguish the host CR4 from the guest pid for the idle process the maximum value 0xffff for the PASN is used. This adds a fourth case for a guest OS with an updated kernel: 4) CR4==0xffff, gpp=((1UL << 31) | pid) The host kernel will have CR4==0xffff and will use (gpp!=0 || CR4!==0xffff) to identify guest samples. This works nicely with all 4 cases, the only possible issue would be a guest with an old kernel (gpp==0) and a process pid of 0xffff. Well, don't do that.. Suggested-by:
-
Sebastian Ott authored
Move a struct definition to get rid of a forward declaration. Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
-
Sebastian Ott authored
Users complained that they are hitting the limit of 64 functions (some physical functions can spawn lots of virtual functions). Double the default limit. With the latest savings in static data usage this increases the image size by only 520 bytes. Signed-off-by:
-
Sebastian Ott authored
Commit c506fff3 ("s390/pci: resize iomap") reduced the iomap to NR_FUNCTIONS * PCI_BAR_COUNT elements. Since we only support functions with 64bit BARs we can cut that number in half. Signed-off-by:
-
Sebastian Ott authored
Address space identifiers are already defined in <asm/pci_insn.h>. Signed-off-by:
-
Sebastian Ott authored
barsize was never used. Get rid of it. Signed-off-by:
-
Martin Schwidefsky authored
The 32-bit lctl instruction is quite a bit slower than the 64-bit counter part lctlg. Use the faster instruction. Signed-off-by:
-
- 31 Mar, 2017 14 commits
-
-
Martin Schwidefsky authored
Merge branch 'vfio-ccw-for-martin' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features Pull vfio-ccw branch to add the basic channel I/O passthrough intrastructure based on vfio. The focus is on supporting dasd-eckd(cu_type/dev_type = 0x3990/0x3390) as the target device. Signed-off-by:
-
Dong Jia Shi authored
Add Cornelia Huck and myself as the vfio-ccw driver maintainers. Signed-off-by:
-
Dong Jia Shi authored
Although Linux does not use format-0 channel command words (CCW0) these are a non-optional part of the platform spec, and for the sake of platform compliance, and possibly some non-Linux guests, we have to support CCW0. Making the kernel execute a format 0 channel program is too much hassle because we would need to allocate and use memory which can be addressed by 24 bit physical addresses (because of CCW0.cda). So we implement CCW0 support by translating the channel program into an equivalent CCW1 program instead. Based upon an orginal patch by Kai Yue Wang. Signed-off-by:
-
Dong Jia Shi authored
Add file Documentation/s390/vfio-ccw.txt that includes details of vfio-ccw. Acked-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by:
-
Dong Jia Shi authored
The current implementation doesn't check if the subchannel is in a proper device state when handling an event. Let's introduce a finite state machine to manage the state/event change. Signed-off-by:
-
Dong Jia Shi authored
Introduce a singlethreaded workqueue to handle the I/O interrupts. With the work added to this queue, we store the I/O results to the io_region of the subchannel, then signal the userspace program to handle the results. Signed-off-by:
-
Dong Jia Shi authored
Realize VFIO_DEVICE_GET_IRQ_INFO ioctl to retrieve VFIO_CCW_IO_IRQ information. Realize VFIO_DEVICE_SET_IRQS ioctl to set an eventfd fd for VFIO_CCW_IO_IRQ. Once a write operation to the ccw_io_region was performed, trigger a signal on this fd. Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Message-Id: <20170317031743.40128-12-bjsdjshi@linux.vnet.ibm.com> Signed-off-by:
-
Dong Jia Shi authored
Introduce VFIO_DEVICE_RESET ioctl for vfio-ccw to make it possible to hot-reset the device. We try to achieve a reset by first disabling the subchannel and then enabling it again: this should clear all state at the subchannel. Signed-off-by:
-
Dong Jia Shi authored
Introduce device information about vfio-ccw: VFIO_DEVICE_FLAGS_CCW. Realize VFIO_DEVICE_GET_REGION_INFO ioctl for vfio-ccw. Reviewed-by:
-
Dong Jia Shi authored
We implement the basic ccw command handling infrastructure here: 1. Translate the ccw commands. 2. Issue the translated ccw commands to the device. 3. Once we get the execution result, update the guest SCSW with it. Acked-by:
-
Dong Jia Shi authored
To provide user-space a set of interfaces to: 1. pass in a ccw program to perform an I/O operation. 2. read back I/O results of the completed I/O operations. We introduce an MMIO region for the vfio-ccw device here. This region is defined to content: 1. areas to store arguments that an ssch required. 2. areas to store the I/O results. Using pwrite/pread to the device on this region, a user-space program could write/read data to/from the vfio-ccw device. Reviewed-by:
-
Dong Jia Shi authored
To make vfio support subchannel devices, we need to leverage the mediated device framework to create a mediated device for the subchannel device. This registers the subchannel device to the mediated device framework during probe to enable mediated device creation. Reviewed-by:
-
Dong Jia Shi authored
Introduce ccwchain structure and helper functions that can be used to handle a channel program issued from a virtual machine. The following limitations apply: 1. Supports only prefetch enabled mode. 2. Supports idal(c64) ccw chaining. 3. Supports 4k idaw. 4. Supports ccw1. 5. Supports direct ccw chaining by translating them to idal ccws. CCW translation requires to leverage the vfio_(un)pin_pages interfaces to pin/unpin sets of mem pages frequently. Currently we have a lack of support to do this in an efficient way. So we introduce pfn_array data structure and helper functions to handle pin/unpin operations here. Signed-off-by:
-
Dong Jia Shi authored
To make vfio support subchannel devices, we need a css driver for the vfio subchannels. This patch adds a basic vfio-ccw subchannel driver for this purpose. To enable VFIO for vfio-ccw, enable S390_CCW_IOMMU config option and configure VFIO as required. Acked-by:
-
