1. 12 Apr, 2021 8 commits
  2. 07 Apr, 2021 3 commits
  3. 05 Apr, 2021 9 commits
    • Alexander Gordeev's avatar
      s390/mm: fix phys vs virt confusion in mark_kernel_pXd() functions family · 3784231b
      Alexander Gordeev authored
      Due to historical reasons mark_kernel_pXd() functions
      misuse the notion of physical vs virtual addresses
      difference.
      Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      3784231b
    • 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
    • Heiko Carstens's avatar
      s390/irq: fix reading of ext_params2 field from lowcore · 85012e76
      Heiko Carstens authored
      The contents of the ext_params2 field of the lowcore should just be
      copied to the pt_regs structure, not dereferenced.
      
      Fixes crashes / program check loops like this:
      
      Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
      Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0
                 0000000080030000 000000000000000f 0000000000000000 0000000000000000
                 0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518
                 0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428
      Krnl Code: 00000000d6d02b2e: 58100080            l       %r1,128
                 00000000d6d02b32: 5010b0a4            st      %r1,164(%r11)
                #00000000d6d02b36: e31001b80104        lg      %r1,4536
                >00000000d6d02b3c: e31010000004        lg      %r1,0(%r1)
                 00000000d6d02b42: e310b0a80024        stg     %r1,168(%r11)
                 00000000d6d02b48: c01000242270        larl    %r1,00000000d7187028
                 00000000d6d02b4e: d5071000b010        clc     0(8,%r1),16(%r11)
                 00000000d6d02b54: a784001b            brc     8,00000000d6d02b8a
      Call Trace:
       [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
       [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
       [<00000000d621d266>] die+0x106/0x188
       [<00000000d62305b8>] do_no_context+0xc8/0x100
       [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0
       [<00000000d6d0e950>] pgm_check_handler+0x118/0x160
       [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
       [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
       [<00000000d621d266>] die+0x106/0x188
       [<00000000d62305b8>] do_no_context+0xc8/0x100
       [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0
       [<00000000d6d0e950>] pgm_check_handler+0x118/0x160
       [<00000000d6d02b3c>] do_ext_irq+0x74/0x170
       [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4
       [<0000000000000000>] 0x0
       [<00000000d6d0e57a>] default_idle_call+0x42/0x110
       [<00000000d629856e>] do_idle+0xce/0x160
       [<00000000d62987be>] cpu_startup_entry+0x36/0x40
       [<00000000d621f2f2>] smp_start_secondary+0x82/0x88
      
      Cc: Sven Schnelle <svens@linux.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Fixes: 56e62a73 ("s390: convert to generic entry")
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      85012e76
    • Vasily Gorbik's avatar
      s390/unwind: add machine check handler stack · 08edb968
      Vasily Gorbik authored
      Fixes: b61b1595 ("s390: add stack for machine check handler")
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      08edb968
    • Alexander Gordeev's avatar
      s390/cpcmd: fix inline assembly register clobbering · 7a2f9144
      Alexander Gordeev authored
      Register variables initialized using arithmetic. That leads to
      kasan instrumentaton code corrupting the registers contents.
      Follow GCC guidlines and use temporary variables for assigning
      init values to register variables.
      
      Fixes: 94c12cc7 ("[S390] Inline assembly cleanup.")
      Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      Acked-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.htmlSigned-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      7a2f9144
  4. 28 Mar, 2021 3 commits
  5. 25 Mar, 2021 3 commits
    • Heiko Carstens's avatar
      s390/vdso: fix initializing and updating of vdso_data · 5b43bd18
      Heiko Carstens authored
      Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns
      incorrect values when time is provided via vdso instead of system call:
      
      vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507
      sys_ts_nsec  = 1446923235377, sys_ts.tv_sec  = 1446, sys_ts.tv_nsec  = 923235377
      
      Within the s390 specific vdso function __arch_get_hw_counter() reads
      tod clock steering values from the arch_data member of the passed in
      vdso_data structure.
      
      Problem is that only for the CS_HRES_COARSE vdso_data arch_data is
      initialized and gets updated. The CS_RAW specific vdso_data does not
      contain any valid tod_clock_steering information, which explains the
      different values.
      
      Fix this by initializing and updating all vdso_datas.
      Reported-by: default avatarLi Wang <liwang@redhat.com>
      Tested-by: default avatarLi Wang <liwang@redhat.com>
      Fixes: 1ba2d6c0 ("s390/vdso: simplify __arch_get_hw_counter()")
      Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osirisSigned-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      5b43bd18
    • Heiko Carstens's avatar
      s390/vdso: fix tod_steering_delta type · b24bacd6
      Heiko Carstens authored
      The s390 specific vdso function __arch_get_hw_counter() is supposed to
      consider tod clock steering.
      
      If a tod clock steering event happens and the tod clock is set to a
      new value __arch_get_hw_counter() will not return the real tod clock
      value but slowly drift it from the old delta until the returned value
      finally matches the real tod clock value again.
      
      Unfortunately the type of tod_steering_delta unsigned while it is
      supposed to be signed. It depends on if tod_steering_delta is negative
      or positive in which direction the vdso code drifts the clock value.
      
      Worst case is now that instead of drifting the clock slowly it will
      jump into the opposite direction by a factor of two.
      
      Fix this by simply making tod_steering_delta signed.
      
      Fixes: 4bff8cb5 ("s390: convert to GENERIC_VDSO")
      Cc: <stable@vger.kernel.org> # 5.10
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      b24bacd6
    • Heiko Carstens's avatar
      s390/vdso: copy tod_steering_delta value to vdso_data page · 72bbc226
      Heiko Carstens authored
      When converting the vdso assembler code to C it was forgotten to
      actually copy the tod_steering_delta value to vdso_data page.
      
      Which in turn means that tod clock steering will not work correctly.
      
      Fix this by simply copying the value whenever it is updated.
      
      Fixes: 4bff8cb5 ("s390: convert to GENERIC_VDSO")
      Cc: <stable@vger.kernel.org> # 5.10
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      72bbc226
  6. 24 Mar, 2021 2 commits
  7. 22 Mar, 2021 11 commits
    • Bhaskar Chowdhury's avatar
    • 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
  8. 21 Mar, 2021 1 commit