1. 13 Apr, 2023 14 commits
  2. 04 Apr, 2023 20 commits
  3. 27 Mar, 2023 4 commits
  4. 20 Mar, 2023 2 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