aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/s390/virtio (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-06-17s390/cio: Use generalized CCW handler in cp_init()Eric Farman1-23/+4
It is now pretty apparent that ccwchain_handle_ccw() (nee ccwchain_handle_tic()) does everything that cp_init() wants to do. Let's remove that duplicated code from cp_init() and let ccwchain_handle_ccw() handle it itself. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190606202831.44135-5-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-17s390/cio: Generalize the TIC handlerEric Farman1-5/+6
Refactor ccwchain_handle_tic() into a routine that handles a channel program address (which itself is a CCW pointer), rather than a CCW pointer that is only a TIC CCW. This will make it easier to reuse this code for other CCW commands. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190606202831.44135-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-17s390/cio: Refactor the routine that handles TIC CCWsEric Farman1-4/+4
Extract the "does the target of this TIC already exist?" check from ccwchain_handle_tic(), so that it's easier to refactor that function into one that cp_init() is able to use. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190606202831.44135-3-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-17s390/cio: Squash cp_free() and cp_unpin_free()Eric Farman1-20/+16
The routine cp_free() does nothing but call cp_unpin_free(), and while most places call cp_free() there is one caller of cp_unpin_free() used when the cp is guaranteed to have not been marked initialized. This seems like a dubious way to make a distinction, so let's combine these routines and make cp_free() do all the work. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190606202831.44135-2-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-15Update default configurationMartin Schwidefsky3-3/+8
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15processor: get rid of cpu_relax_yieldHeiko Carstens5-13/+9
stop_machine is the only user left of cpu_relax_yield. Given that it now has special semantics which are tied to stop_machine introduce a weak stop_machine_yield function which architectures can override, and get rid of the generic cpu_relax_yield implementation. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390: improve wait logic of stop_machineMartin Schwidefsky5-13/+25
The stop_machine loop to advance the state machine and to wait for all affected CPUs to check-in calls cpu_relax_yield in a tight loop until the last missing CPUs acknowledged the state transition. On a virtual system where not all logical CPUs are backed by real CPUs all the time it can take a while for all CPUs to check-in. With the current definition of cpu_relax_yield a diagnose 0x44 is done which tells the hypervisor to schedule *some* other CPU. That can be any CPU and not necessarily one of the CPUs that need to run in order to advance the state machine. This can lead to a pretty bad diagnose 0x44 storm until the last missing CPU finally checked-in. Replace the undirected cpu_relax_yield based on diagnose 0x44 with a directed yield. Each CPU in the wait loop will pick up the next CPU in the cpumask of stop_machine. The diagnose 0x9c is used to tell the hypervisor to run this next CPU instead of the current one. If there is only a limited number of real CPUs backing the virtual CPUs we end up with the real CPUs passed around in a round-robin fashion. [heiko.carstens@de.ibm.com]: Use cpumask_next_wrap as suggested by Peter Zijlstra. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15processor: remove spin_cpu_yieldHeiko Carstens2-11/+0
spin_cpu_yield is unused, therefore remove it. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/traps: simplify data exception handlerVasily Gorbik1-8/+2
Simplify conditions and remove unnecessary variable in data exception handler. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15virtio/s390: make airq summary indicators DMAHalil Pasic1-8/+24
The hypervisor needs to interact with the summary indicators, so these need to be DMA memory as well (at least for protected virtualization guests). Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15virtio/s390: use DMA memory for ccw I/O and classic notifiersHalil Pasic1-80/+89
Before virtio-ccw could get away with not using DMA API for the pieces of memory it does ccw I/O with. With protected virtualization this has to change, since the hypervisor needs to read and sometimes also write these pieces of memory. The hypervisor is supposed to poke the classic notifiers, if these are used, out of band with regards to ccw I/O. So these need to be allocated as DMA memory (which is shared memory for protected virtualization guests). Let us factor out everything from struct virtio_ccw_device that needs to be DMA memory in a satellite that is allocated as such. Note: The control blocks of I/O instructions do not need to be shared. These are marshalled by the ultravisor. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15virtio/s390: add indirection to indicators accessHalil Pasic1-15/+25
This will come in handy soon when we pull out the indicators from virtio_ccw_device to a memory area that is shared with the hypervisor (in particular for protected virtualization guests). Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15virtio/s390: use cacheline aligned airq bit vectorsHalil Pasic1-1/+2
The flag AIRQ_IV_CACHELINE was recently added to airq_iv_create(). Let us use it! We actually wanted the vector to span a cacheline all along. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/airq: use DMA memory for adapter interruptsHalil Pasic4-14/+28
Protected virtualization guests have to use shared pages for airq notifier bit vectors, because the hypervisor needs to write these bits. Let us make sure we allocate DMA memory for the notifier bit vectors by replacing the kmem_cache with a dma_cache and kalloc() with cio_dma_zalloc(). Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Sebastian Ott <sebott@linux.ibm.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/cio: add basic protected virtualization supportHalil Pasic10-83/+164
As virtio-ccw devices are channel devices, we need to use the dma area within the common I/O layer for any communication with the hypervisor. Note that we do not need to use that area for control blocks directly referenced by instructions, e.g. the orb. It handles neither QDIO in the common code, nor any device type specific stuff (like channel programs constructed by the DASD driver). An interesting side effect is that virtio structures are now going to get allocated in 31 bit addressable storage. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Sebastian Ott <sebott@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/cio: introduce DMA pools to cioHalil Pasic3-4/+141
To support protected virtualization cio will need to make sure the memory used for communication with the hypervisor is DMA memory. Let us introduce one global pool for cio. Our DMA pools are implemented as a gen_pool backed with DMA pages. The idea is to avoid each allocation effectively wasting a page, as we typically allocate much less than PAGE_SIZE. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Sebastian Ott <sebott@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/mm: force swiotlb for protected virtualizationHalil Pasic3-0/+68
On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Michael Mueller <mimu@linux.ibm.com> Tested-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/crypto: sha: Use -ENODEV instead of -EOPNOTSUPPDavid Hildenbrand3-3/+3
Let's use the error value that is typically used if HW support is not available when trying to load a module - this is also what systemd's systemd-modules-load.service expects. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/crypto: prng: Use -ENODEV instead of -EOPNOTSUPPDavid Hildenbrand1-2/+2
Let's use the error value that is typically used if HW support is not available when trying to load a module - this is also what systemd's systemd-modules-load.service expects. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/crypto: ghash: Use -ENODEV instead of -EOPNOTSUPPDavid Hildenbrand1-1/+1
Let's use the error value that is typically used if HW support is not available when trying to load a module - this is also what systemd's systemd-modules-load.service expects. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15s390/pkey: Use -ENODEV instead of -EOPNOTSUPPDavid Hildenbrand1-4/+4
systemd-modules-load.service automatically tries to load the pkey module on systems that have MSA. Pkey also requires the MSA3 facility and a bunch of subfunctions. Failing with -EOPNOTSUPP makes "systemd-modules-load.service" fail on any system that does not have all needed subfunctions. For example, when running under QEMU TCG (but also on systems where protected keys are disabled via the HMC). Let's use -ENODEV, so systemd-modules-load.service properly ignores failing to load the pkey module because of missing HW functionality. While at it, also convert the -EOPNOTSUPP in pkey_clr2protkey() to -ENODEV. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11s390/kdump: get rid of compile warningHeiko Carstens1-1/+2
Move the CONFIG_CRASH_DUMP ifdef to get rid of this: arch/s390/kernel/machine_kexec.c:146:22: warning: 'do_start_kdump' defined but not used [-Wunused-function] Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11RAID/s390: remove invalid 'r' inline asm operand modifierVasily Gorbik1-1/+1
gcc silently ignores unsupported inline asm operand modifiers, effectively turning '%r0' into '%0', but upcoming clang 9 complains about them: lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' asm volatile ("VLM %2,%3,0,%r1" ^ Clean up what look like a typo 'r' inline asm operand modifier usage. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11s390: include/asm/debug.h add kerneldoc markupsMauro Carvalho Chehab2-671/+232
Instead of keeping the documentation inside s390dbf.rst, move them to arch/s390/include/asm/debug.h, using standard kernel-doc markups. Keeping the documentation close to the code helps to keep it updated. It also makes easier to document other stuff inside debug.h, as all it needs is to add kernel-doc markups inside it, as the file will be already be included at the produced documentation. - Those were converted to kerneldoc using this script specially designed to parse ths file, and manually editted: <script> use strict; my $mode = ""; my $parameter = ""; my $ret = ""; my $descr = ""; sub add_var($) { my $ln = shift; $ln =~ s/^\s+//; $ln =~ s/\s+$//; return if ($ln eq ""); $ln =~ s/^(\S+)\s+/$1\t/; print " * \@$ln\n"; } sub add_return($) { my $ln = shift; print " *\n * Return:\n" if ($mode ne "Return Value:"); $ln =~ s/^\s+//; $ln =~ s/\s+$//; return if ($ln eq ""); print " * - $ln\n"; } sub add_description($) { my $ln = shift; print " *\n * \n" if ($mode ne "Description:"); $ln =~ s/^\s+//; $ln =~ s/\s+$//; return if ($ln eq ""); print " * $ln\n"; } sub flush_results() { print " */\n\n"; } while (<>) { if (m/^[\-]+$/) { flush_results(); $mode = ""; $parameter = ""; $ret = ""; $descr = ""; next; } if (m/(Parameter:)(.*)/) { print " *\n" if ($mode eq "func"); add_var($2); $mode = $1; next; } if (m/(Return Value:)(.*)/) { add_return($2); $mode = $1; next; } if (m/(Description:)(.*)/) { add_description($2); $mode = $1; next; } if ($mode eq "Parameter:") { add_var($_); next; } if ($mode eq "Return Value:") { add_return($_); next; } if ($mode eq "Description:") { add_description($_); next; } next if (m/^\s*$/); if (m/^\S+.*\s\*?(\S+)\s*\(/) { if ($mode eq "") { print "/**\n * $1()\n"; } else { print " * $1()\n"; } $mode="func"; } } flush_results(); </script> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11docs: s390: convert docs to ReST and rename to *.rstMauro Carvalho Chehab21-2262/+3118
Convert all text files with s390 documentation to ReST format. Tried to preserve as much as possible the original document format. Still, some of the files required some work in order for it to be visible on both plain text and after converted to html. The conversion is actually: - add blank lines and identation in order to identify paragraphs; - fix tables markups; - add some lists markups; - mark literal blocks; - adjust title markups. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11docs: Debugging390.txt: convert table to ascii artworkMauro Carvalho Chehab1-90/+120
The first bit/value table inside the document is very hard to read and won't fit ReST format. Also, some columns aren't properly aligned. Convert it to a nice ascii artwork table with makes it easier to read as plain text and is compatible with ReST format parser on Sphinx. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/qdio: handle PENDING state for QEBSM devicesJulian Wiedmann1-0/+1
When a CQ-enabled device uses QEBSM for SBAL state inspection, get_buf_states() can return the PENDING state for an Output Queue. get_outbound_buffer_frontier() isn't prepared for this, and any PENDING buffer will permanently stall all further completion processing on this Queue. This isn't a concern for non-QEBSM devices, as get_buf_states() for such devices will manually turn PENDING buffers into EMPTY ones. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/jump_label: remove unused structure definitionHeiko Carstens1-5/+0
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/boot: disable address-of-packed-member warningHeiko Carstens1-0/+1
Get rid of gcc9 warnings like this: arch/s390/boot/ipl_report.c: In function 'find_bootdata_space': arch/s390/boot/ipl_report.c:42:26: warning: taking address of packed member of 'struct ipl_rb_components' may result in an unaligned pointer value [-Waddress-of-packed-member] 42 | for_each_rb_entry(comp, comps) | ^~~~~ This is effectively the s390 variant of commit 20c6c1890455 ("x86/boot: Disable the address-of-packed-member compiler warning"). Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/cio: fix kdoc for tiqdio_thinint_handlerSebastian Ott1-0/+1
Add missing parameter description to fix the following warning: drivers/s390/cio/qdio_thinint.c:183: warning: Function parameter or member 'floating' not described in 'tiqdio_thinint_handler' Signed-off-by: Sebastian Ott <sebott@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/zcrypt: support special flagged EP11 cprbsHarald Freudenberger1-0/+4
Within an EP11 cprb there exists a byte field flags. Bit 0x20 of this field indicates a special cprb. A special cprb triggers special handling in the firmware below the OS layer. However, a special cprb also needs to have the S bit in GPR0 set when NQAP is called. This was not the case for EP11 cprbs and this patch now introduces the code to support this. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390: fix unrecognized __aligned() in uapi headerMasahiro Yamada1-1/+1
__aligned() is a shorthand that is only available in the kernel space because it is defined in include/linux/compiler_attributes.h, which is not exported to the user space. Detected by compile-testing exported headers. ./usr/include/asm/runtime_instr.h:60:37: error: expected declaration specifiers or ‘...’ before numeric constant } __attribute__((packed)) __aligned(8); ^ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390/configs: remove useless UEVENT_HELPER_PATHKrzysztof Kozlowski2-2/+0
Remove the CONFIG_UEVENT_HELPER_PATH because: 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was made default to 'n', 2. It is not recommended (help message: "This should not be used today [...] creates a high system load") and was kept only for ancient userland, 3. Certain userland specifically requests it to be disabled (systemd README: "Legacy hotplug slows down the system and confuses udev"). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390: enforce CONFIG_HOTPLUG_CPUHeiko Carstens3-29/+0
x86 and powerpc (partially) enforce already CONFIG_HOTPLUG_CPU. On s390 it is enabled on all distributions by default since ages. The only exception is our zfcpdump kernel. However to simplify testing, enforce HOTPLUG_CPU. This was suggested by Paul McKenney, since his rcutorture test environments for CONFIG_SMP=y only support HOTPLUG_CPU=y. Suggested-by: Paul E. McKenney <paulmck@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07s390: enforce CONFIG_SMPHeiko Carstens12-95/+7
There never have been distributions that shiped with CONFIG_SMP=n for s390. In addition the kernel currently doesn't even compile with CONFIG_SMP=n for s390. Most likely it wouldn't even work, even if we fix the compile error, since nobody tests it, since there is no use case that I can think of. Therefore simply enforce CONFIG_SMP and get rid of some more or less unused code. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/disassembler: update opcode tableMartin Schwidefsky2-10/+46
Sync with binutils and add a couple of missing instructions. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/mm: mmap base does not depend on ADDR_NO_RANDOMIZE personalityAlexandre Ghiti1-2/+0
randomize_stack_top() checks for current task flag PF_RANDOMIZE in order to use stack randomization and PF_RANDOMIZE is set when ADDR_NO_RANDOMIZE is unset, so no need to check for ADDR_NO_RANDOMIZE in stack_maxrandom_size. [heiko.carstens@de.ibm.com]: See also commit 01578e36163c ("x86/elf: Remove the unnecessary ADDR_NO_RANDOMIZE checks") Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/Kconfig: pedantic cleanupsEnrico Weigelt, metux IT consult4-14/+13
Formatting of Kconfig files doesn't look so pretty, so just take damp cloth and clean it up. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/purgatory: update .gitignoreMasahiro Yamada1-1/+2
Since commit 4c0f032d4963 ("s390/purgatory: Omit use of bin2c"), kexec-purgatory.c is not generated. purgatory and purgatory.lds are generated files, so should be ignored by git. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop meaningless 'targets' from tools MakefileMasahiro Yamada1-1/+0
'targets' should be specified to include .*.cmd files to evaluate if_changed or friends. Here, facility-defs.h and dis-defs.h are generated by filechk. Because filechk does not generate .*.cmd file, the 'targets' addition is meaningless. The filechk correctly updates the target when its content is changed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop redundant directory creation from tools MakefileMasahiro Yamada1-3/+0
As you can see in scripts/Kbuild.include, the filechk creates the parent directory of the target as needed. This Makefile does not need to explicitly create the directory. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: drop unneeded -Wall addition from tools MakefileMasahiro Yamada1-2/+1
The top level Makefile adds -Wall globally for all host tools: KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ I see two "-Wall" added for compiling these tools. Of course, it is allowed to pass the same option multiple times, but we do not need to do so. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390: do not pass $(LINUXINCLUDE) to gen_opcode_table.cMasahiro Yamada1-1/+1
I guess HOSTCFLAGS_gen_opcode_table.o was blindly copied from HOSTCFLAGS_gen_facilities.o The reason of adding $(LINUXINCLUDE) to HOSTCFLAGS_gen_facilities.o is because gen_facilities.c references some CONFIG options. (Kbuild does not cater to this for host tools automatically.) On the other hand, gen_opcode_table.c does not reference CONFIG options at all. So, there is no good reason to pass $(LINUXINCLUDE). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/idal: use struct_size() in kmalloc()xiaolinkui1-2/+1
Use the new struct_size() helper to keep code simple. Signed-off-by: xiaolinkui <xiaolinkui@kylinos.cn> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-04s390/jump_label: replace stop_machine with smp_call_functionMartin Schwidefsky2-17/+10
The use of stop_machine to replace the mask bits of the jump label branch is a very heavy-weight operation. This is in fact not necessary, the mask of the branch can simply be updated, followed by a signal processor to all the other CPUs to force them to pick up the modified instruction. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> [heiko.carstens@de.ibm.com]: Change jump_label_make_nop() so we get brcl 0,offset instead of brcl 0,0. This makes sure that only the mask part of the instruction gets changed when updated. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-03s390/cio: Remove vfio-ccw checks of command codesEric Farman1-6/+5
If the CCW being processed is a No-Operation, then by definition no data is being transferred. Let's fold those checks into the normal CCW processors, rather than skipping out early. Likewise, if the CCW being processed is a "test" (a category defined here as an opcode that contains zero in the lowest four bits) then no special processing is necessary as far as vfio-ccw is concerned. These command codes have not been valid since the S/370 days, meaning they are invalid in the same way as one that ends in an eight [1] or an otherwise valid command code that is undefined for the device type in question. Considering that, let's just process "test" CCWs like any other CCW, and send everything to the hardware. [1] POPS states that a x08 is a TIC CCW, and that having any high-order bits enabled is invalid for format-1 CCWs. For format-0 CCWs, the high-order bits are ignored. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190516161403.79053-4-farman@linux.ibm.com> Acked-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-03s390/cio: Allow zero-length CCWs in vfio-ccwEric Farman1-18/+12
It is possible that a guest might issue a CCW with a length of zero, and will expect a particular response. Consider this chain: Address Format-1 CCW -------- ----------------- 0 33110EC0 346022CC 33177468 1 33110EC8 CF200000 3318300C CCW[0] moves a little more than two pages, but also has the Suppress Length Indication (SLI) bit set to handle the expectation that considerably less data will be moved. CCW[1] also has the SLI bit set, and has a length of zero. Once vfio-ccw does its magic, the kernel issues a start subchannel on behalf of the guest with this: Address Format-1 CCW -------- ----------------- 0 021EDED0 346422CC 021F0000 1 021EDED8 CF240000 3318300C Both CCWs were converted to an IDAL and have the corresponding flags set (which is by design), but only the address of the first data address is converted to something the host is aware of. The second CCW still has the address used by the guest, which happens to be (A) (probably) an invalid address for the host, and (B) an invalid IDAW address (doubleword boundary, etc.). While the I/O fails, it doesn't fail correctly. In this example, we would receive a program check for an invalid IDAW address, instead of a unit check for an invalid command. To fix this, revert commit 4cebc5d6a6ff ("vfio: ccw: validate the count field of a ccw before pinning") and allow the individual fetch routines to process them like anything else. We'll make a slight adjustment to our allocation of the pfn_array (for direct CCWs) or IDAL (for IDAL CCWs) memory, so that we have room for at least one address even though no guest memory will be pinned and thus the IDAW will not be populated with a host address. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190516161403.79053-3-farman@linux.ibm.com> Acked-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-03s390/cio: Don't pin vfio pages for empty transfersEric Farman1-5/+50
The skip flag of a CCW offers the possibility of data not being transferred, but is only meaningful for certain commands. Specifically, it is only applicable for a read, read backward, sense, or sense ID CCW and will be ignored for any other command code (SA22-7832-11 page 15-64, and figure 15-30 on page 15-75). (A sense ID is xE4, while a sense is x04 with possible modifiers in the upper four bits. So we will cover the whole "family" of sense CCWs.) For those scenarios, since there is no requirement for the target address to be valid, we should skip the call to vfio_pin_pages() and rely on the IDAL address we have allocated/built for the channel program. The fact that the individual IDAWs within the IDAL are invalid is fine, since they aren't actually checked in these cases. Set pa_nr to zero when skipping the pfn_array_pin() call, since it is defined as the number of pages pinned and is used to determine whether to call vfio_unpin_pages() upon cleanup. The pfn_array_pin() routine returns the number of pages that were pinned, but now might be skipped for some CCWs. Thus we need to calculate the expected number of pages ourselves such that we are guaranteed to allocate a reasonable number of IDAWs, which will provide a valid address in CCW.CDA regardless of whether the IDAWs are filled in with pinned/translated addresses or not. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190516161403.79053-2-farman@linux.ibm.com> Acked-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-03s390/cio: Initialize the host addresses in pfn_arrayEric Farman1-1/+4
Let's initialize the host address to something that is invalid, rather than letting it default to zero. This just makes it easier to notice when a pin operation has failed or been skipped. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190514234248.36203-5-farman@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-06-03s390/cio: Split pfn_array_alloc_pin into piecesEric Farman1-18/+46
The pfn_array_alloc_pin routine is doing too much. Today, it does the alloc of the pfn_array struct and its member arrays, builds the iova address lists out of a contiguous piece of guest memory, and asks vfio to pin the resulting pages. Let's effectively revert a significant portion of commit 5c1cfb1c3948 ("vfio: ccw: refactor and improve pfn_array_alloc_pin()") such that we break pfn_array_alloc_pin() into its component pieces, and have one routine that allocates/populates the pfn_array structs, and another that actually pins the memory. In the future, we will be able to handle scenarios where pinning memory isn't actually appropriate. Signed-off-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20190514234248.36203-4-farman@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>