1. 03 Jun, 2019 7 commits
    • Eric Farman's avatar
      s390/cio: Remove vfio-ccw checks of command codes · 9b6e57e5
      Eric Farman authored
      If the CCW being processed is a No-Operation, then by definition no
      data is being transferred.  Let's fold those checks into the normal
      CCW processors, rather than skipping out early.
      
      Likewise, if the CCW being processed is a "test" (a category defined
      here as an opcode that contains zero in the lowest four bits) then no
      special processing is necessary as far as vfio-ccw is concerned.
      These command codes have not been valid since the S/370 days, meaning
      they are invalid in the same way as one that ends in an eight [1] or
      an otherwise valid command code that is undefined for the device type
      in question.  Considering that, let's just process "test" CCWs like
      any other CCW, and send everything to the hardware.
      
      [1] POPS states that a x08 is a TIC CCW, and that having any high-order
      bits enabled is invalid for format-1 CCWs.  For format-0 CCWs, the
      high-order bits are ignored.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-4-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      9b6e57e5
    • Eric Farman's avatar
      s390/cio: Allow zero-length CCWs in vfio-ccw · 453eac31
      Eric Farman authored
      It is possible that a guest might issue a CCW with a length of zero,
      and will expect a particular response.  Consider this chain:
      
         Address   Format-1 CCW
         --------  -----------------
       0 33110EC0  346022CC 33177468
       1 33110EC8  CF200000 3318300C
      
      CCW[0] moves a little more than two pages, but also has the
      Suppress Length Indication (SLI) bit set to handle the expectation
      that considerably less data will be moved.  CCW[1] also has the SLI
      bit set, and has a length of zero.  Once vfio-ccw does its magic,
      the kernel issues a start subchannel on behalf of the guest with this:
      
         Address   Format-1 CCW
         --------  -----------------
       0 021EDED0  346422CC 021F0000
       1 021EDED8  CF240000 3318300C
      
      Both CCWs were converted to an IDAL and have the corresponding flags
      set (which is by design), but only the address of the first data
      address is converted to something the host is aware of.  The second
      CCW still has the address used by the guest, which happens to be (A)
      (probably) an invalid address for the host, and (B) an invalid IDAW
      address (doubleword boundary, etc.).
      
      While the I/O fails, it doesn't fail correctly.  In this example, we
      would receive a program check for an invalid IDAW address, instead of
      a unit check for an invalid command.
      
      To fix this, revert commit 4cebc5d6 ("vfio: ccw: validate the
      count field of a ccw before pinning") and allow the individual fetch
      routines to process them like anything else.  We'll make a slight
      adjustment to our allocation of the pfn_array (for direct CCWs) or
      IDAL (for IDAL CCWs) memory, so that we have room for at least one
      address even though no guest memory will be pinned and thus the
      IDAW will not be populated with a host address.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-3-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      453eac31
    • Eric Farman's avatar
      s390/cio: Don't pin vfio pages for empty transfers · 5d87fbf7
      Eric Farman authored
      The skip flag of a CCW offers the possibility of data not being
      transferred, but is only meaningful for certain commands.
      Specifically, it is only applicable for a read, read backward, sense,
      or sense ID CCW and will be ignored for any other command code
      (SA22-7832-11 page 15-64, and figure 15-30 on page 15-75).
      
      (A sense ID is xE4, while a sense is x04 with possible modifiers in the
      upper four bits.  So we will cover the whole "family" of sense CCWs.)
      
      For those scenarios, since there is no requirement for the target
      address to be valid, we should skip the call to vfio_pin_pages() and
      rely on the IDAL address we have allocated/built for the channel
      program.  The fact that the individual IDAWs within the IDAL are
      invalid is fine, since they aren't actually checked in these cases.
      
      Set pa_nr to zero when skipping the pfn_array_pin() call, since it is
      defined as the number of pages pinned and is used to determine
      whether to call vfio_unpin_pages() upon cleanup.
      
      The pfn_array_pin() routine returns the number of pages that were
      pinned, but now might be skipped for some CCWs.  Thus we need to
      calculate the expected number of pages ourselves such that we are
      guaranteed to allocate a reasonable number of IDAWs, which will
      provide a valid address in CCW.CDA regardless of whether the IDAWs
      are filled in with pinned/translated addresses or not.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190516161403.79053-2-farman@linux.ibm.com>
      Acked-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      5d87fbf7
    • Eric Farman's avatar
      s390/cio: Initialize the host addresses in pfn_array · c34a12e6
      Eric Farman authored
      Let's initialize the host address to something that is invalid,
      rather than letting it default to zero.  This just makes it easier
      to notice when a pin operation has failed or been skipped.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-5-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      c34a12e6
    • Eric Farman's avatar
      s390/cio: Split pfn_array_alloc_pin into pieces · e4f3f18b
      Eric Farman authored
      The pfn_array_alloc_pin routine is doing too much.  Today, it does the
      alloc of the pfn_array struct and its member arrays, builds the iova
      address lists out of a contiguous piece of guest memory, and asks vfio
      to pin the resulting pages.
      
      Let's effectively revert a significant portion of commit 5c1cfb1c
      ("vfio: ccw: refactor and improve pfn_array_alloc_pin()") such that we
      break pfn_array_alloc_pin() into its component pieces, and have one
      routine that allocates/populates the pfn_array structs, and another
      that actually pins the memory.  In the future, we will be able to
      handle scenarios where pinning memory isn't actually appropriate.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-4-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      e4f3f18b
    • Eric Farman's avatar
      s390/cio: Set vfio-ccw FSM state before ioeventfd · 4e31d6ae
      Eric Farman authored
      Otherwise, the guest can believe it's okay to start another I/O
      and bump into the non-idle state.  This results in a cc=2 (with
      the asynchronous CSCH/HSCH code) returned to the guest, which is
      unfortunate since everything is otherwise working normally.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <20190514234248.36203-3-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      4e31d6ae
    • Eric Farman's avatar
      s390/cio: Update SCSW if it points to the end of the chain · 15f0eb3d
      Eric Farman authored
      Per the POPs [1], when processing an interrupt the SCSW.CPA field of an
      IRB generally points to 8 bytes after the last CCW that was executed
      (there are exceptions, but this is the most common behavior).
      
      In the case of an error, this points us to the first un-executed CCW
      in the chain.  But in the case of normal I/O, the address points beyond
      the end of the chain.  While the guest generally only cares about this
      when possibly restarting a channel program after error recovery, we
      should convert the address even in the good scenario so that we provide
      a consistent, valid, response upon I/O completion.
      
      [1] Figure 16-6 in SA22-7832-11.  The footnotes in that table also state
      that this is true even if the resulting address is invalid or protected,
      but moving to the end of the guest chain should not be a surprise.
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190514234248.36203-2-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      15f0eb3d
  2. 31 May, 2019 2 commits
  3. 29 May, 2019 1 commit
  4. 28 May, 2019 6 commits
  5. 25 May, 2019 1 commit
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 2409207a
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is the same set of patches sent in the merge window as the final
        pull except that Martin's read only rework is replaced with a simple
        revert of the original change that caused the regression.
      
        Everything else is an obvious fix or small cleanup"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        Revert "scsi: sd: Keep disk read-only when re-reading partition"
        scsi: bnx2fc: fix incorrect cast to u64 on shift operation
        scsi: smartpqi: Reporting unhandled SCSI errors
        scsi: myrs: Fix uninitialized variable
        scsi: lpfc: Update lpfc version to 12.2.0.2
        scsi: lpfc: add check for loss of ndlp when sending RRQ
        scsi: lpfc: correct rcu unlock issue in lpfc_nvme_info_show
        scsi: lpfc: resolve lockdep warnings
        scsi: qedi: remove set but not used variables 'cdev' and 'udev'
        scsi: qedi: remove memset/memcpy to nfunc and use func instead
        scsi: qla2xxx: Add cleanup for PCI EEH recovery
      2409207a
  6. 24 May, 2019 23 commits