1. 13 Apr, 2023 12 commits
  2. 04 Apr, 2023 20 commits
  3. 27 Mar, 2023 4 commits
  4. 20 Mar, 2023 4 commits
    • Heiko Carstens's avatar
      s390/mm: make use of atomic_fetch_xor() · d28d86a0
      Heiko Carstens authored
      Make use of atomic_fetch_xor() instead of an atomic_cmpxchg() loop to
      implement atomic_xor_bits() (aka atomic_xor_return()). This makes the C
      code more readable and in addition generates better code, since for z196
      and newer a single lax instruction is generated instead of a cmpxchg()
      loop.
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      d28d86a0
    • Harald Freudenberger's avatar
      s390/ap: add ap status asynch error support · 038c5bed
      Harald Freudenberger authored
      Review and extend the low level AP code to be able to
      deal with asynchronous reported errors on APQNs.
      
      The hypervisor and the SE guest may be confronted with
      an asynchronously reported error at return of an AP
      instruction. So all places where AP instructions are
      called need review and may eventually need extensions.
      However, not all places need rework. As together with
      the AP status and the enabled asynch bit there is always
      a response code set. The asynch error reporting comes
      with new response codes which may be simple handled in
      the default case of a switch statement.
      
      The idea behind this patch is to report asynch errors
      as -EPERM (read this as "Operation not permitted") which
      reflects the fact that only a rapq (with F bit enabled)
      is a valid AP instruction when an asynch error is flagged.
      
      The AP queue state machine functions return
      AP_SM_WAIT_NONE when a asynch error is detected to reflect
      the fact, that the state machine can't do anything with
      such an error as long as the queue is reset.
      
      Unfortunately the ap bus scan function needed some
      update as the ap_queue_info() now needs to return
      3 states: 1 if an APQN exists and info is available,
      -1 if it is assumed an APQN does not exist and the new
      return value 0 without any info values filled. This 0
      returncode is handled as "there is an APQN but we currently
      don't know any more hw info about this, so please use
      your previous info and try again later".
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarHolger Dengler <dengler@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      038c5bed
    • Harald Freudenberger's avatar
      s390/ap: implement SE AP bind, unbind and associate · 2d72eaf0
      Harald Freudenberger authored
      Implementation of the new functions for SE AP support:
      bind, unbind and associate. There are two new sysfs
      attributes for this:
      
      /sys/devices/ap/cardxx/xx.yyyy/se_bind
      /sys/devices/ap/cardxx/xx.yyyy/se_associate
      
      Writing a 1 into the se_bind attribute triggers the
      SE AP bind for this AP queue, writing a 0 into does
      an unbind - that's a reset (RAPQ) with the F bit enabled.
      
      The se_associate attribute needs an integer value in
      range 0...2^16-1 written in. This is the index into a
      secrets table feed into the ultravisor. For more details
      please see the Architecture documents.
      
      These both new ap queue attributes are only visible
      inside a SE guest with SB (Secure Binding) available.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarHolger Dengler <dengler@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      2d72eaf0
    • Harald Freudenberger's avatar
      s390/ap: introduce low frequency polling possibility · 263c8454
      Harald Freudenberger authored
      For some events the ap bus needs to poll. For example
      when an AP queue is reset until the reset is through.
      Also when no interrupt support is available (e.g. zVM)
      there is a need to poll until all requests have been
      processed and all replies have been delivered.
      
      Polling is done with a high resolution timer by default
      run with a rate of 4kHz (LPAR) or 666Hz (zVM guest).
      
      For some events (wait for reset complete, wait for irq
      enabled complete) this is a much too high poll rate
      which triggers a lot of TAPQ invocations.
      
      This patch introduces the possibility for the state
      machine functions to return a new wait enum
      AP_SM_WAIT_LOW_TIMEOUT which gives a hint to the
      ap_wait() function to eventually set up the timer
      with a more relaxed timeout value of 25Hz.
      
      This patch also includes a slight rework of the sysfs
      functions parsing the timer related stuff: Use of
      kstrtobool and kstrtoul instead of sscanf.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarHolger Dengler <dengler@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      263c8454