Skip to content

L
linux
Switch branch/tag
  1. 05 Apr, 2021 5 commits
    • Tony Krowiak's avatar
      s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks · 0cc00c8d
      Tony Krowiak authored 
      This patch fixes a lockdep splat introduced by commit f21916ec
("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated").
The lockdep splat only occurs when starting a Secure Execution guest.
Crypto virtualization (vfio_ap) is not yet supported for SE guests;
however, in order to avoid this problem when support becomes available,
this fix is being provided.

The circular locking dependency was introduced when the setting of the
masks in the guest's APCB was executed while holding the matrix_dev->lock.
While the lock is definitely needed to protect the setting/unsetting of the
matrix_mdev->kvm pointer, it is not necessarily critical for setting the
masks; so, the matrix_dev->lock will be released while the masks are being
set or cleared.

Keep in mind, however, that another process that takes the matrix_dev->lock
can get control while the masks in the guest's APCB are being set or
cleared as a result of the driver being notified that the KVM pointer
has been set or unset. This could result in invalid access to the
matrix_mdev->kvm pointer by the intervening process. To avoid this
scenario, two new fields are being added to the ap_matrix_mdev struct:

struct ap_matrix_mdev {
	...
	bool kvm_busy;
	wait_queue_head_t wait_for_kvm;
   ...
};

The functions that handle notification that the KVM pointer value has
been set or cleared will set the kvm_busy flag to true until they are done
processing at which time they will set it to false and wake up the tasks on
the matrix_mdev->wait_for_kvm wait queue. Functions that require
access to matrix_mdev->kvm will sleep on the wait queue until they are
awakened at which time they can safely access the matrix_mdev->kvm
field.

Fixes: f21916ec ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      0cc00c8d
    • Wan Jiabing's avatar
      s390/cio: remove duplicate struct ccw1 declaration · f38033c8
      Wan Jiabing authored 
      struct ccw1 is declared twice. One has been declared
at 21st line. Remove the duplicate.
Signed-off-by: default avatarWan Jiabing <wanjiabing@vivo.com>
Acked-by: default avatarVineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      f38033c8
    • Shixin Liu's avatar
      s390/cio: use DECLARE_WAIT_QUEUE_HEAD() for wait_queue · 4e774d59
      Shixin Liu authored 
      wait_queue_head_t can be initialized automatically with
DECLARE_WAIT_QUEUE_HEAD() rather than explicitly calling
init_waitqueue_head().
Signed-off-by: default avatarShixin Liu <liushixin2@huawei.com>
Acked-by: default avatarVineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      4e774d59
    • Shixin Liu's avatar
      s390/cio: use DEFINE_SPINLOCK() for spinlock · 1034c96c
      Shixin Liu authored 
      static spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: default avatarShixin Liu <liushixin2@huawei.com>
Acked-by: default avatarVineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      1034c96c
    • Niklas Schnelle's avatar
      s390/pci: expose UID uniqueness guarantee · 408f2c9c
      Niklas Schnelle authored 
      On s390 each PCI device has a user-defined ID (UID) exposed under
/sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI
device's primary index and to match the device within Linux to the
device configured in the hypervisor. To serve as a primary identifier
the UID must be unique within the Linux instance, this is guaranteed by
the platform if and only if the UID Uniqueness Checking flag is set
within the CLP List PCI Functions response.

While the UID has been exposed to userspace since commit ac4995b9
("s390/pci: add some new arch specific pci attributes") whether or not
the platform guarantees its uniqueness for the lifetime of the Linux
instance while defined is not visible from userspace. Remedy this by
exposing this as a per device attribute at

/sys/bus/pci/devices/<dev>/uid_is_unique

Keeping this a per device attribute allows for maximum flexibility if we
ever end up with some devices not having a UID or not enjoying the
guaranteed uniqueness.
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: default avatarViktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      408f2c9c
  3. 28 Mar, 2021 2 commits
  5. 24 Mar, 2021 2 commits
  7. 22 Mar, 2021 11 commits
    • Bhaskar Chowdhury's avatar
      s390/kernel: fix a typo · 5671d971
      Bhaskar Chowdhury authored 
      s/struture/structure/
Signed-off-by: default avatarBhaskar Chowdhury <unixbhaskar@gmail.com>
Link: https://lore.kernel.org/r/20210322062500.3109603-1-unixbhaskar@gmail.comSigned-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      5671d971
    • Julian Wiedmann's avatar
      s390/qdio: let driver manage the QAOB · 396c1004
      Julian Wiedmann authored 
      We are spending way too much effort on qdio-internal bookkeeping for
QAOB management & caching, and it's still not robust. Once qdio's
TX path has detached the QAOB from a PENDING buffer, we lost all
track of it until it shows up in a CQ notification again. So if the
device is torn down before that notification arrives, we leak the QAOB.

Just have the driver take care of it, and simply pass down a QAOB if
they want a TX with async-completion capability. For a buffer in PENDING
state that requires the QAOB for final completion, qeth can now also try
to recycle the buffer's QAOB rather than unconditionally freeing it.

This also eliminates the qdio_outbuf_state array, which was only needed
to transfer the aob->user1 tag from the driver to the qdio layer.
Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
Acked-by: default avatarBenjamin Block <bblock@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      396c1004
    • Niklas Schnelle's avatar
      s390/pci: move zpci_remove_device() to bus code · 95b3a8b4
      Niklas Schnelle authored 
      The zpci_remove_device() function removes the device from the PCI common
code core which is an operation dealing primarily with the zbus and PCI
bus code. With that and to match an upcoming refactoring of the
symmetric scanning part move it to the bus code.
Reviewed-by: default avatarMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      95b3a8b4
    • Niklas Schnelle's avatar
      s390/pci: unify de-/configure for slots and events · 2631f6b6
      Niklas Schnelle authored 
      A zPCI event with PEC 0x0301 for an existing zPCI device goes through
the same actions as enable_slot(). Similarly a zPCI event with PEC
0x0303 does the same steps as disable_slot().
We can thus unify both actions as zpci_configure_device() respectively
zpci_deconfigure_device().
Reviewed-by: default avatarMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      2631f6b6
    • Vineeth Vijayan's avatar
      s390/cio: add CRW inject functionality · a4f17cc7
      Vineeth Vijayan authored 
      This patch introduces the mechanism to inject artificial events to the
CIO layer.

One of the main-event type which triggers the CommonIO operations are
Channel Report events. When a malfunction or other condition affecting
channel-subsystem operation is recognized, a Channel Report Word
(consisting of one or more CRWs) describing the condition is made
pending for retrieval and analysis by the program. The CRW contains
information concerning the identity and state of a facility following
the detection of the malfunction or other condition.

The patch introduces two debugfs interfaces which can be used to inject
'artificial' events from the userspace. It is intended to provide an easy
means to increase the test coverage for CIO code. And this functionality
can be enabled via a new configuration option CONFIG_CIO_INJECT.

The newly introduces debugfs interfaces can be used as mentioned below
to generate different fake-events. To use the crw_inject, first we should
enable it by using enable_inject interface.
i.e

echo 1 > /sys/kernel/debug/s390/cio/enable_inject

After the first step, user can simulate CRW as follows:

echo <solicited> <overflow> <chaining> <rsc> <ancillary> <erc> <rsid> \
                               > /sys/kernel/debug/s390/cio/crw_inject

Example:
A permanent error ERC on CHPID 0x60 would look like this:

  echo 0 0 0 4 0 6 0x60 > /sys/kernel/debug/s390/cio/crw_inject

and an initialized ERC on the same CHPID:

  echo 0 0 0 4 0 2 0x60 > /sys/kernel/debug/s390/cio/crw_inject
Signed-off-by: default avatarVineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: default avatarPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      a4f17cc7
    • Vineeth Vijayan's avatar
      s390/cio: introduce CIO debugfs directory · 64a715ab
      Vineeth Vijayan authored 
      This patch introduces an s390 Common I/O layer debugfs directory that is
intended to provide access to debugging-related CIO functions and data.
The directory is created as /sys/kernel/debug/s390/cio
Signed-off-by: default avatarVineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: default avatarPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      64a715ab
    • Niklas Schnelle's avatar
      s390/pci: add zpci_event_hard_deconfigured() · dee60c0d
      Niklas Schnelle authored 
      Extract the handling of PEC 0x0304 into a function and make sure we only
attempt to disable the function if it is enabled. Also check for errors
returned by zpci_disable_device() and leave the function alone if there
are any.
Reviewed-by: default avatarMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      dee60c0d
    • Niklas Schnelle's avatar
      s390/pci: deconfigure device on release · a9045c22
      Niklas Schnelle authored 
      When zpci_release_device() is called on a zPCI function that is still
configured it would not be deconfigured. Until now this hasn't caused
any problems because zpci_zdev_put() is only ever called for devices
in Standby or Reserved. Fix it by adding sclp_pci_deconfigure() to the
switch when in Configured state.
Reviewed-by: default avatarMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      a9045c22
    • Niklas Schnelle's avatar
      s390/pci: refactor zpci function states · f6576a1b
      Niklas Schnelle authored 
      The current zdev->state mixes the configuration states supported by CLP
with an additional Online state which is used inconsistently to include
enabled zPCI functions which are not yet visible to the common PCI
subsytem. In preparation for a clean separation between architected
configuration states and fine grained function states remove the Online
function state.

Where we previously checked for Online it is more accurate to check if
the function is enabled to avoid an edge case where a disabled device
was still treated as Online. This also simplifies checks whether
a function is configured as this is now directly reflected by its
function state.
Reviewed-by: default avatarMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      f6576a1b
    • Peter Oberparleiter's avatar
      s390/sclp: increase sclp console line length · 98ce70b7
      Peter Oberparleiter authored 
      Kernel and console/TTY messages written to the SCLP line mode console
are wrapped at 80 characters per line by the associated SCLP driver.
This makes long lines of output difficult to read, and requires editing
of wrapped lines copied from the output device.

Neither the firmware interface used to access the SCLP console, nor the
HMC "Operating System Messages" web interface that displays these
messages require such a length limit. Also other operating systems such
as z/VM do not impose similar limits on messages they emit to the same
console device.

This patch therefore increases the limit to 320 characters per line to
make SCLP line mode console output more readable. As a result 99% of
lines written during a typical boot will not be wrapped, compared to
about 50% wrapped lines at 80 characters per line. Another positive
side-effect of this change is that the HMC console interface is able to
keep more messages in its history buffer due to fewer line-breaks being
generated.

In a worst case scenario this means that a 4k console buffer is emitted
with the last ~400 bytes empty (320 text + 78 headers). This is more
than offset by the fact that each line that is not truncated saves 78
header bytes in the buffer. As a result the actual number of emitted
buffers should be about the same as with the 80 character limit.

This patch also removes the differentiation between line lengths of
SCLP line mode output on z/VM and non-z/VM systems. While the z/VM
hypervisor adds a prefix in front of each line ('xx: ' where xx is the
number of the CPU issuing the message), adjusting Linux line lengths did
not significantly increase readability of console output, and makes even
less of a difference with longer lines.
Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.ibm.com>
Tested-by: default avatarNiklas Schnelle <schnelle@linux.ibm.com>
Acked-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      98ce70b7
    • Janosch Frank's avatar
      s390/uv: add prot virt guest/host indication files · 37564ed8
      Janosch Frank authored 
      Let's export the prot_virt_guest and prot_virt_host variables into the
UV sysfs firmware interface to make them easily consumable by
administrators.

prot_virt_host being 1 indicates that we did the UV
initialization (opt-in)

prot_virt_guest being 1 indicates that the UV indicates the share and
unshare ultravisor calls which is an indication that we are running as
a protected guest.
Signed-off-by: default avatarJanosch Frank <frankja@linux.ibm.com>
Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      37564ed8
  9. 21 Mar, 2021 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7