mirror of
https://github.com/tbsdtv/linux_media.git
synced 2025-07-23 04:33:26 +02:00
Merge tag 's390-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 updates from Vasily Gorbik: - Add support for multi-function devices in pci code. - Enable PF-VF linking for architectures using the pdev->no_vf_scan flag (currently just s390). - Add reipl from NVMe support. - Get rid of critical section cleanup in entry.S. - Refactor PNSO CHSC (perform network subchannel operation) in cio and qeth. - QDIO interrupts and error handling fixes and improvements, more refactoring changes. - Align ioremap() with generic code. - Accept requests without the prefetch bit set in vfio-ccw. - Enable path handling via two new regions in vfio-ccw. - Other small fixes and improvements all over the code. * tag 's390-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (52 commits) vfio-ccw: make vfio_ccw_regops variables declarations static vfio-ccw: Add trace for CRW event vfio-ccw: Wire up the CRW irq and CRW region vfio-ccw: Introduce a new CRW region vfio-ccw: Refactor IRQ handlers vfio-ccw: Introduce a new schib region vfio-ccw: Refactor the unregister of the async regions vfio-ccw: Register a chp_event callback for vfio-ccw vfio-ccw: Introduce new helper functions to free/destroy regions vfio-ccw: document possible errors vfio-ccw: Enable transparent CCW IPL from DASD s390/pci: Log new handle in clp_disable_fh() s390/cio, s390/qeth: cleanup PNSO CHSC s390/qdio: remove q->first_to_kick s390/qdio: fix up qdio_start_irq() kerneldoc s390: remove critical section cleanup from entry.S s390: add machine check SIGP s390/pci: ioremap() align with generic code s390/ap: introduce new ap function ap_get_qdev() Documentation/s390: Update / remove developerWorks web links ...
This commit is contained in:
Linus Torvalds
@@ -15,6 +15,7 @@ s390 Architecture
|
||||
vfio-ccw
|
||||
zfcpdump
|
||||
common_io
|
||||
pci
|
||||
|
||||
text_files
|
||||
|
||||
|
||||
125
Documentation/s390/pci.rst
Normal file
125
Documentation/s390/pci.rst
Normal file
@@ -0,0 +1,125 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========
|
||||
S/390 PCI
|
||||
=========
|
||||
|
||||
Authors:
|
||||
- Pierre Morel
|
||||
|
||||
Copyright, IBM Corp. 2020
|
||||
|
||||
|
||||
Command line parameters and debugfs entries
|
||||
===========================================
|
||||
|
||||
Command line parameters
|
||||
-----------------------
|
||||
|
||||
* nomio
|
||||
|
||||
Do not use PCI Mapped I/O (MIO) instructions.
|
||||
|
||||
* norid
|
||||
|
||||
Ignore the RID field and force use of one PCI domain per PCI function.
|
||||
|
||||
debugfs entries
|
||||
---------------
|
||||
|
||||
The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
|
||||
|
||||
* /sys/kernel/debug/s390dbf/pci_*/
|
||||
|
||||
For example:
|
||||
|
||||
- /sys/kernel/debug/s390dbf/pci_msg/sprintf
|
||||
Holds messages from the processing of PCI events, like machine check handling
|
||||
and setting of global functionality, like UID checking.
|
||||
|
||||
Change the level of logging to be more or less verbose by piping
|
||||
a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For
|
||||
details, see the documentation on the S/390 debug feature at
|
||||
Documentation/s390/s390dbf.rst.
|
||||
|
||||
Sysfs entries
|
||||
=============
|
||||
|
||||
Entries specific to zPCI functions and entries that hold zPCI information.
|
||||
|
||||
* /sys/bus/pci/slots/XXXXXXXX
|
||||
|
||||
The slot entries are set up using the function identifier (FID) of the
|
||||
PCI function.
|
||||
|
||||
- /sys/bus/pci/slots/XXXXXXXX/power
|
||||
|
||||
A physical function that currently supports a virtual function cannot be
|
||||
powered off until all virtual functions are removed with:
|
||||
echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
|
||||
|
||||
* /sys/bus/pci/devices/XXXX:XX:XX.X/
|
||||
|
||||
- function_id
|
||||
A zPCI function identifier that uniquely identifies the function in the Z server.
|
||||
|
||||
- function_handle
|
||||
Low-level identifier used for a configured PCI function.
|
||||
It might be useful for debuging.
|
||||
|
||||
- pchid
|
||||
Model-dependent location of the I/O adapter.
|
||||
|
||||
- pfgid
|
||||
PCI function group ID, functions that share identical functionality
|
||||
use a common identifier.
|
||||
A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
|
||||
|
||||
- vfn
|
||||
The virtual function number, from 1 to N for virtual functions,
|
||||
0 for physical functions.
|
||||
|
||||
- pft
|
||||
The PCI function type
|
||||
|
||||
- port
|
||||
The port corresponds to the physical port the function is attached to.
|
||||
It also gives an indication of the physical function a virtual function
|
||||
is attached to.
|
||||
|
||||
- uid
|
||||
The unique identifier (UID) is defined when configuring an LPAR and is
|
||||
unique in the LPAR.
|
||||
|
||||
- pfip/segmentX
|
||||
The segments determine the isolation of a function.
|
||||
They correspond to the physical path to the function.
|
||||
The more the segments are different, the more the functions are isolated.
|
||||
|
||||
Enumeration and hotplug
|
||||
=======================
|
||||
|
||||
The PCI address consists of four parts: domain, bus, device and function,
|
||||
and is of this form: DDDD:BB:dd.f
|
||||
|
||||
* When not using multi-functions (norid is set, or the firmware does not
|
||||
support multi-functions):
|
||||
|
||||
- There is only one function per domain.
|
||||
|
||||
- The domain is set from the zPCI function's UID as defined during the
|
||||
LPAR creation.
|
||||
|
||||
* When using multi-functions (norid parameter is not set),
|
||||
zPCI functions are addressed differently:
|
||||
|
||||
- There is still only one bus per domain.
|
||||
|
||||
- There can be up to 256 functions per bus.
|
||||
|
||||
- The domain part of the address of all functions for
|
||||
a multi-Function device is set from the zPCI function's UID as defined
|
||||
in the LPAR creation for the function zero.
|
||||
|
||||
- New functions will only be ready for use after the function zero
|
||||
(the function with devfn 0) has been enumerated.
|
||||
@@ -204,15 +204,44 @@ definition of the region is::
|
||||
__u32 ret_code;
|
||||
} __packed;
|
||||
|
||||
This region is always available.
|
||||
|
||||
While starting an I/O request, orb_area should be filled with the
|
||||
guest ORB, and scsw_area should be filled with the SCSW of the Virtual
|
||||
Subchannel.
|
||||
|
||||
irb_area stores the I/O result.
|
||||
|
||||
ret_code stores a return code for each access of the region.
|
||||
ret_code stores a return code for each access of the region. The following
|
||||
values may occur:
|
||||
|
||||
``0``
|
||||
The operation was successful.
|
||||
|
||||
``-EOPNOTSUPP``
|
||||
The orb specified transport mode or an unidentified IDAW format, or the
|
||||
scsw specified a function other than the start function.
|
||||
|
||||
``-EIO``
|
||||
A request was issued while the device was not in a state ready to accept
|
||||
requests, or an internal error occurred.
|
||||
|
||||
``-EBUSY``
|
||||
The subchannel was status pending or busy, or a request is already active.
|
||||
|
||||
``-EAGAIN``
|
||||
A request was being processed, and the caller should retry.
|
||||
|
||||
``-EACCES``
|
||||
The channel path(s) used for the I/O were found to be not operational.
|
||||
|
||||
``-ENODEV``
|
||||
The device was found to be not operational.
|
||||
|
||||
``-EINVAL``
|
||||
The orb specified a chain longer than 255 ccws, or an internal error
|
||||
occurred.
|
||||
|
||||
This region is always available.
|
||||
|
||||
vfio-ccw cmd region
|
||||
-------------------
|
||||
@@ -231,6 +260,64 @@ This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD.
|
||||
|
||||
Currently, CLEAR SUBCHANNEL and HALT SUBCHANNEL use this region.
|
||||
|
||||
command specifies the command to be issued; ret_code stores a return code
|
||||
for each access of the region. The following values may occur:
|
||||
|
||||
``0``
|
||||
The operation was successful.
|
||||
|
||||
``-ENODEV``
|
||||
The device was found to be not operational.
|
||||
|
||||
``-EINVAL``
|
||||
A command other than halt or clear was specified.
|
||||
|
||||
``-EIO``
|
||||
A request was issued while the device was not in a state ready to accept
|
||||
requests.
|
||||
|
||||
``-EAGAIN``
|
||||
A request was being processed, and the caller should retry.
|
||||
|
||||
``-EBUSY``
|
||||
The subchannel was status pending or busy while processing a halt request.
|
||||
|
||||
vfio-ccw schib region
|
||||
---------------------
|
||||
|
||||
The vfio-ccw schib region is used to return Subchannel-Information
|
||||
Block (SCHIB) data to userspace::
|
||||
|
||||
struct ccw_schib_region {
|
||||
#define SCHIB_AREA_SIZE 52
|
||||
__u8 schib_area[SCHIB_AREA_SIZE];
|
||||
} __packed;
|
||||
|
||||
This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_SCHIB.
|
||||
|
||||
Reading this region triggers a STORE SUBCHANNEL to be issued to the
|
||||
associated hardware.
|
||||
|
||||
vfio-ccw crw region
|
||||
---------------------
|
||||
|
||||
The vfio-ccw crw region is used to return Channel Report Word (CRW)
|
||||
data to userspace::
|
||||
|
||||
struct ccw_crw_region {
|
||||
__u32 crw;
|
||||
__u32 pad;
|
||||
} __packed;
|
||||
|
||||
This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_CRW.
|
||||
|
||||
Reading this region returns a CRW if one that is relevant for this
|
||||
subchannel (e.g. one reporting changes in channel path state) is
|
||||
pending, or all zeroes if not. If multiple CRWs are pending (including
|
||||
possibly chained CRWs), reading this region again will return the next
|
||||
one, until no more CRWs are pending and zeroes are returned. This is
|
||||
similar to how STORE CHANNEL REPORT WORD works.
|
||||
|
||||
vfio-ccw operation details
|
||||
--------------------------
|
||||
|
||||
@@ -333,7 +420,14 @@ through DASD/ECKD device online in a guest now and use it as a block
|
||||
device.
|
||||
|
||||
The current code allows the guest to start channel programs via
|
||||
START SUBCHANNEL, and to issue HALT SUBCHANNEL and CLEAR SUBCHANNEL.
|
||||
START SUBCHANNEL, and to issue HALT SUBCHANNEL, CLEAR SUBCHANNEL,
|
||||
and STORE SUBCHANNEL.
|
||||
|
||||
Currently all channel programs are prefetched, regardless of the
|
||||
p-bit setting in the ORB. As a result, self modifying channel
|
||||
programs are not supported. For this reason, IPL has to be handled as
|
||||
a special case by a userspace/guest program; this has been implemented
|
||||
in QEMU's s390-ccw bios as of QEMU 4.1.
|
||||
|
||||
vfio-ccw supports classic (command mode) channel I/O only. Transport
|
||||
mode (HPF) is not supported.
|
||||
|
||||
@@ -46,5 +46,5 @@ initramfs with a user space application that writes the dump to a SCSI
|
||||
partition.
|
||||
|
||||
For more information on how to use zfcpdump refer to the s390 'Using the Dump
|
||||
Tools book', which is available from
|
||||
http://www.ibm.com/developerworks/linux/linux390.
|
||||
Tools' book, which is available from IBM Knowledge Center:
|
||||
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_dt.html
|
||||
|
||||
Reference in New Issue
Block a user