- 03 Jun, 2020 2 commits
-
-
Farhan Ali authored
Use the IRQ to notify userspace that there is a CRW pending in the region, related to path-availability changes on the passthrough subchannel. Signed-off-by:
Farhan Ali <alifm@linux.ibm.com> Signed-off-by:
Eric Farman <farman@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20200505122745.53208-8-farman@linux.ibm.com> Signed-off-by:
-
Farhan Ali authored
This region provides a mechanism to pass a Channel Report Word that affect vfio-ccw devices, and needs to be passed to the guest for its awareness and/or processing. The base driver (see crw_collect_info()) provides space for two CRWs, as a subchannel event may have two CRWs chained together (one for the ssid, one for the subchannel). As vfio-ccw will deal with everything at the subchannel level, provide space for a single CRW to be transferred in one shot. Signed-off-by:
-
- 02 Jun, 2020 7 commits
-
-
Eric Farman authored
To simplify future expansion. Signed-off-by:
-
Farhan Ali authored
The schib region can be used by userspace to get the subchannel- information block (SCHIB) for the passthrough subchannel. This can be useful to get information such as channel path information via the SCHIB.PMCW fields. Signed-off-by:
-
Eric Farman authored
This is mostly for the purposes of a later patch, since we'll need to do the same thing later. While we are at it, move the resulting function call to ahead of the unregistering of the IOMMU notifier, so that it's done in the reverse order of how it was created. Signed-off-by:
-
Farhan Ali authored
Register the chp_event callback to receive channel path related events for the subchannels managed by vfio-ccw. Signed-off-by:
-
Farhan Ali authored
Consolidate some of the cleanup code for the regions, so that as more are added we reduce code duplication. Signed-off-by:
-
Cornelia Huck authored
Interacting with the I/O and the async regions can yield a number of errors, which had been undocumented so far. These are part of the api, so remedy that. Signed-off-by:
-
Jared Rossi authored
Remove the explicit prefetch check when using vfio-ccw devices. This check does not trigger in practice as all Linux channel programs are intended to use prefetch. It is expected that all ORBs issued by Linux will request prefetch. Although non-prefetching ORBs are not rejected, they will prefetch nonetheless. A warning is issued up to once per 5 seconds when a forced prefetch occurs. A non-prefetch ORB does not necessarily result in an error, however frequent encounters with non-prefetch ORBs indicate that channel programs are being executed in a way that is inconsistent with what the guest is requesting. While there is currently no known case of an error caused by forced prefetch, it is possible in theory that forced prefetch could result in an error if applied to a channel program that is dependent on non-prefetch. Signed-off-by:
Jared Rossi <jrossi@linux.ibm.com> Reviewed-by:
-
- 28 May, 2020 6 commits
-
-
Petr Tesarik authored
After disabling a function, the original handle is logged instead of the disabled handle. Link: https://lkml.kernel.org/r/20200522183922.5253-1-ptesarik@suse.com Fixes: 17cdec96 ("s390/pci: Recover handle in clp_set_pci_fn()") Reviewed-by:
Pierre Morel <pmorel@linux.ibm.com> Signed-off-by:
Petr Tesarik <ptesarik@suse.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Alexandra Winter authored
CHSC3D (PNSO - perform network subchannel operation) is used for OC0 (Store-network-bridging-information) as well as for OC3 (Store-network-address-information). So common fields are renamed from *brinfo* to *pnso*. Also *_bridge_host_* is changed into *_addr_change_*, e.g. qeth_bridge_host_event to qeth_addr_change_event, for the same reasons. The keywords in the card traces are changed accordingly. Remove unused L3 types, as PNSO will only return Layer2 entries. Make PNSO CHSC implementation more consistent with existing API usage: Add new function ccw_device_pnso() to drivers/s390/cio/device_ops.c and the function declaration to arch/s390/include/asm/ccwdev.h, which takes a struct ccw_device * as parameter instead of schid and calls chsc_pnso(). PNSO CHSC has no strict relationship to qdio. So move the calling function from qdio to qeth_l2 and move the necessary structures to a new file arch/s390/include/asm/chsc.h. Do response code evaluation only in chsc_error_from_response() and use return code in all other places. qeth_anset_makerc() was meant to evaluate the PNSO response code, but never did, because pnso_rc was already non-zero. Indentation was corrected in some places. Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
q->first_to_kick is obsolete, and can be replaced by q->first_to_check. Both cursors start off at 0. Out of the three code paths that update first_to_check, the qdio_inspect_queue() path is irrelevant as it doesn't even touch first_to_kick anymore. This leaves us with the two tasklet-driven code paths. Here any update to first_to_check is followed by a call to qdio_kick_handler(), which advances first_to_kick by the same amount. So the two cursors will differ only for a tiny moment. Drivers have no way of deterministically observing this difference, and thus it doesn't matter which of the cursors we use for reporting an error to q->handler. Signed-off-by:
-
Julian Wiedmann authored
Document the actual semantics, correcting an old copy & paste mistake. Signed-off-by:
-
Sven Schnelle authored
The current code is rather complex and caused a lot of subtle and hard to debug bugs in the past. Simplify the code by calling the system_call handler with interrupts disabled, save machine state, and re-enable them later. This requires significant changes to the machine check handling code as well. When the machine check interrupt arrived while being in kernel mode the new code will signal pending machine checks with a SIGP external call. When userspace was interrupted, the handler will switch to the kernel stack and directly execute s390_handle_mcck(). Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Sven Schnelle authored
This will be used with the upcoming entry.S changes to signal that there's a machine check pending that cannot be handled in the Machine check handler itself. Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
- 20 May, 2020 11 commits
-
-
Niklas Schnelle authored
Let's use the same signature and parameter names as in the generic ioremap() definition making the physical address' type explicit. Add a check against address wrap around as in the generic lib/ioremap.c:ioremap_prot() code. Finally use free_vm_area() instead of vunmap() as in the generic code. Besides being clearer free_vm_area() can also skip a few additional checks compared with vunmap(). Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Harald Freudenberger authored
Provide a new interface function to be used by the ap drivers: struct ap_queue *ap_get_qdev(ap_qid_t qid); Returns ptr to the struct ap_queue device or NULL if there was no ap_queue device with this qid found. When something is found, the reference count of the embedded device is increased. So the caller has to decrease the reference count after use with a call to put_device(&aq->ap_dev.device). With this patch also the ap_card_list is removed from the ap core code and a new hashtable is introduced which stores hnodes of all the ap queues known to the ap bus. The hashtable approach and a first implementation of this interface comes from a previous patch from Anthony Krowiak and an idea from Halil Pasic. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Suggested-by:
Tony Krowiak <akrowiak@linux.ibm.com> Suggested-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
-
Gerald Schaefer authored
s390 documentation now lives in IBM Knowledge Center, so update the link in the zfcpdump documentation. Also, remove the old developerWorks links from the appldata source code. Those were not really documentation related, but rather a reminder to the developer that some documentation has to be adjusted when changing the record layout, which should still be pretty obvious from the remaining comment. Signed-off-by:
-
David Hildenbrand authored
Assume we have a crashkernel area of 256MB reserved: root@vm0:~# cat /proc/iomem 00000000-6fffffff : System RAM 0f258000-0fcfffff : Kernel code 0fd00000-101d10e3 : Kernel data 105b3000-1068dfff : Kernel bss 70000000-7fffffff : Crash kernel This exactly corresponds to memory block 7 (memory block size is 256MB). Trying to offline that memory block results in: root@vm0:~# echo "offline" > /sys/devices/system/memory/memory7/state -bash: echo: write error: Device or resource busy [ 128.458762] page:000003d081c00000 refcount:1 mapcount:0 mapping:00000000d01cecd4 index:0x0 [ 128.458773] flags: 0x1ffff00000001000(reserved) [ 128.458781] raw: 1ffff00000001000 000003d081c00008 000003d081c00008 0000000000000000 [ 128.458781] raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000 [ 128.458783] page dumped because: unmovable page The craskernel area is marked reserved in the bootmem allocator. This results in the memmap getting initialized (refcount=1, PG_reserved), but the pages are never freed to the page allocator. So these pages look like allocated pages that are unmovable (esp. PG_reserved), and therefore, memory offlining fails early, when trying to isolate the page range. We only have to care about the exchange area, make that clear. Signed-off-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
-
Niklas Schnelle authored
On s390 PCI Virtual Functions (VFs) are scanned by firmware and are made available to Linux via the hot-plug interface. As such the common code path of doing the scan directly using the parent Physical Function (PF) is not used and fenced off with the no_vf_scan attribute. Even if the partition created the VFs itself e.g. using the sriov_numvfs attribute of a PF, the PF/VF links thus need to be established after the fact. To do this when a VF is plugged we scan through all functions on the same zbus and test whether they are the parent PF in which case we establish the necessary links. With these links established there is now no more need to fence off pci_iov_remove_virtfn() for pdev->no_vf_scan as the common code now works fine. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
-
Niklas Schnelle authored
Currently pci_iov_add_virtfn() scans the SR-IOV BARs, adds the VF to the bus and also creates the sysfs links between the newly added VF and its parent PF. With pdev->no_vf_scan fencing off the entire pci_iov_add_virtfn() call s390 as the sole pdev->no_vf_scan user thus ends up missing these sysfs links which are required for example by QEMU/libvirt. Instead of duplicating the code refactor pci_iov_add_virtfn() to make sysfs link creation callable separately. Signed-off-by:
-
Julian Wiedmann authored
SBALs in PRIMED or ERROR state represent new work on the Input Queue. But while inbound_primed() does all sorts of ACK management for new PRIMED work, the same handling is currently missing for ERROR work. In particular the path for ERROR work doesn't clear up _old_ ACKs. Treat ERROR work the same as PRIMED work, but consider that the QEBSM auto-ACK feature doesn't apply here. So we need to set the ACK manually, as if it was a non-QEBSM device. Note that this doesn't aspire to actually improve performance, the main goal is to just unify the code paths and have consistent behaviour. Signed-off-by:
-
Julian Wiedmann authored
inbound_primed() currently has two code paths - one for QEBSM that knows how to deal with multiple ACKs, and a non-QEBSM path that strictly assumes a single ACK on the queue. In preparation for a subsequent patch, slightly adjust the non-QEBSM path so that it can manage a queue with multiple ACKs. Signed-off-by:
-
Julian Wiedmann authored
Refilling the Input Queue requires additional checks, as the refilled SBALs can overlap with the ACKs that qdio maintains on the queue. This code path is way too complex, and does a whole bunch of wrap-around checks that the modulo arithmetic in sub_buf() takes care of by itself. So shrink down all that code into a few lines of equivalent functionality. Signed-off-by:
-
YueHaibing authored
commit 8ebd51a7 ("s390/cio: idset.c: remove some unused functions") left behind this, remove it Link: https://lkml.kernel.org/r/20200508140643.30540-1-yuehaibing@huawei.comSigned-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
YueHaibing authored
commit 657480d9 ("s390: support KPROBES_ON_FTRACE") left behind this, remove it. Signed-off-by:
-
- 06 May, 2020 5 commits
-
-
Jason J. Herne authored
Populate sysfs and structs with reipl entries for nvme ipl type. This allows specifying a target nvme device when rebooting/reipling. Signed-off-by:
Jason J. Herne <jjherne@linux.ibm.com> Signed-off-by:
-
Jason J. Herne authored
Recognize IPL Block's Ipl Type of "nvme". Populate related structs and sysfs entries. Signed-off-by:
-
Pierre Morel authored
Clarify the documentation. Signed-off-by:
-
Pierre Morel authored
The assignment of the PCI device multifunction attribute is set during the PCI device probe. There is no need to set it here. Let's do it right and remove this assignment. Signed-off-by:
-
Masahiro Yamada authored
s390 uses the UTS_MACHINE defined arch/s390/Makefile as follows: UTS_MACHINE := s390x We do not need to pass the fixed string from the command line. Hard-code user_regset_view::name, like many other architectures do. Link: https://lkml.kernel.org/r/20200413013113.8529-1-masahiroy@kernel.orgSigned-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
- 28 Apr, 2020 9 commits
-
-
Julian Wiedmann authored
buf_in_between() gets passed q->u.in.ack_start as 'bufnr' parameter. The ack_start always ranges between 0 and QDIO_MAX_BUFFERS_PER_Q - 1, so the subsequent check will always return true. Remove it. Signed-off-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Except for some initial thinint-only steps, the processing is identical to the non-thinint case. So re-use the existing helper. Signed-off-by:
-
Julian Wiedmann authored
Knowing how many queues we initially allocated allows us to 1) sanity-check a subsequent qdio_establish() request, and 2) walk the queue arrays without further checks. Apply this while cleanly splitting qdio_free_queues() into two separate helpers. Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Reviewed-by:
-
Julian Wiedmann authored
When qdio_allocate_qs() fails, have it deal with its previous allocations. This way qdio_allocate() doesn't need to clean up afterwards. Signed-off-by:
-
Julian Wiedmann authored
Instead of having a catch-all qdio_release_memory() helper, free the individual allocations from the respective error path. Signed-off-by:
-
Julian Wiedmann authored
Wrap the init/exit steps for thinint into a single helper that follows the established naming scheme. Signed-off-by:
-
Julian Wiedmann authored
qdio_establish() calls qdio_setup_thinint() via qdio_setup_irq(). If the subsequent qdio_establish_thinint() fails, we miss to put the DSCI again. Thus the DSCI isn't available for re-use. Given enough of such errors, we could end up with having only the shared DSCI available. Merge qdio_setup_thinint() into qdio_establish_thinint(), and deal with such an error internally. Fixes: 779e6e1c ("[S390] qdio: new qdio driver.") Signed-off-by:
-
Julian Wiedmann authored
qdio_establish() calls qdio_establish_thinint(), but later has an error exit path that doesn't roll this call back. Fix it. Fixes: 779e6e1c ("[S390] qdio: new qdio driver.") Signed-off-by:
-
Julian Wiedmann authored
For rolling back after an error, qdio_establish() calls qdio_shutdown(). If the error occurs early enough, then the qdio_irq's state still is QDIO_IRQ_STATE_INACTIVE and qdio_shutdown() does nothing. But at _any_ point where qdio_establish() bails out in this way, qdio_setup_irq() will have already replaced the IRQ handler. This then won't be restored after an early error, and the device can end up being returned to the device driver with qdio's IRQ handler still installed. Slightly reorder qdio_setup_irq() so we can be 100% sure that the IRQ handler was replaced. Then fix the bug in qdio_establish() by calling a helper that rolls back only the IRQ handler modification. Also use the new helper in qdio_shutdown() to keep things in sync, and slightly clean up the locking while doing so. This makes minor semantical changes, but holding setup_mutex gives us sufficient leeway to eg. pull qdio_shutdown_thinint() outside of the ccwdev lock's scope. Fixes: 779e6e1c ("[S390] qdio: new qdio driver.") Signed-off-by:
-
