1. 01 Mar, 2019 6 commits
  2. 27 Feb, 2019 1 commit
  3. 26 Feb, 2019 2 commits
    • Eric Farman's avatar
      s390/cio: Use cpa range elsewhere within vfio-ccw · 2904337f
      Eric Farman authored
      Since we have a little function to see whether a channel
      program address falls within a range of CCWs, let's use
      it in the other places of code that make these checks.
      
      (Why isn't ccw_head fully removed?  Well, because this
      way some longs lines don't have to be reflowed.)
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190222183941.29596-3-farman@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      2904337f
    • Eric Farman's avatar
      s390/cio: Fix vfio-ccw handling of recursive TICs · 48bd0eee
      Eric Farman authored
      The routine ccwchain_calc_length() is tasked with looking at a
      channel program, seeing how many CCWs are chained together by
      the presence of the Chain-Command flag, and returning a count
      to the caller.
      
      Previously, it also considered a Transfer-in-Channel CCW as being
      an appropriate mechanism for chaining.  The problem at the time
      was that the TIC CCW will almost certainly not go to the next CCW
      in memory (because the CC flag would be sufficient), and so
      advancing to the next 8 bytes will cause us to read potentially
      invalid memory.  So that comparison was removed, and the target
      of the TIC is processed as a new chain.
      
      This is fine when a TIC goes to a new chain (consider a NOP+TIC to
      a channel program that is being redriven), but there is another
      scenario where this falls apart.  A TIC can be used to "rewind"
      a channel program, for example to find a particular record on a
      disk with various orientation CCWs.  In this case, we DO want to
      consider the memory after the TIC since the TIC will be skipped
      once the requested criteria is met.  This is due to the Status
      Modifier presented by the device, though software doesn't need to
      operate on it beyond understanding the behavior change of how the
      channel program is executed.
      
      So to handle this, we will re-introduce the check for a TIC CCW
      but limit it by examining the target of the TIC.  If the TIC
      doesn't go back into the current chain, then current behavior
      applies; we should stop counting CCWs and let the target of the
      TIC be handled as a new chain.  But, if the TIC DOES go back into
      the current chain, then we need to keep looking at the memory after
      the TIC for when the channel breaks out of the TIC loop.  We can't
      use tic_target_chain_exists() because the chain in question hasn't
      been built yet, so we will redefine that comparison with some small
      functions to make it more readable and to permit refactoring later.
      
      Fixes: 405d566f ("vfio-ccw: Don't assume there are more ccws after a TIC")
      Signed-off-by: default avatarEric Farman <farman@linux.ibm.com>
      Message-Id: <20190222183941.29596-2-farman@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      48bd0eee
  4. 22 Feb, 2019 15 commits
  5. 21 Feb, 2019 3 commits
  6. 20 Feb, 2019 4 commits
    • Sebastian Ott's avatar
      s390/ism: ignore some errors during deregistration · 0ff06c44
      Sebastian Ott authored
      Prior to dma unmap/free operations the ism driver tries to ensure
      that the memory is no longer accessed by the HW. When errors
      during deregistration of memory regions from the HW occur the ism
      driver will not unmap/free this memory.
      
      When we receive notification from the hypervisor that a PCI function
      has been detached we can no longer access the device and would never
      unmap/free these memory regions which led to complaints by the DMA
      debug API.
      
      Treat this kind of errors during the deregistration of memory regions
      from the HW as success since it is already ensured that the memory
      is no longer accessed by HW.
      Reported-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Reported-by: default avatarHans Wippel <hwippel@linux.ibm.com>
      Signed-off-by: default avatarSebastian Ott <sebott@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      0ff06c44
    • Martin Schwidefsky's avatar
      s390/setup: fix boot crash for machine without EDAT-1 · 86a86804
      Martin Schwidefsky authored
      The fix to make WARN work in the early boot code created a problem
      on older machines without EDAT-1. The setup_lowcore_dat_on function
      uses the pointer from lowcore_ptr[0] to set the DAT bit in the new
      PSWs. That does not work if the kernel page table is set up with
      4K pages as the prefix address maps to absolute zero.
      
      To make this work the PSWs need to be changed with via address 0 in
      form of the S390_lowcore definition.
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarCornelia Huck <cohuck@redhat.com>
      Fixes: 94f85ed3e2f8 ("s390/setup: fix early warning messages")
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      86a86804
    • Martin Schwidefsky's avatar
      s390/setup: fix early warning messages · 87276384
      Martin Schwidefsky authored
      The setup_lowcore() function creates a new prefix page for the boot CPU.
      The PSW mask for the system_call, external interrupt, i/o interrupt and
      the program check handler have the DAT bit set in this new prefix page.
      
      At the time setup_lowcore is called the system still runs without virtual
      address translation, the paging_init() function creates the kernel page
      table and loads the CR13 with the kernel ASCE.
      
      Any code between setup_lowcore() and the end of paging_init() that has
      a BUG or WARN statement will create a program check that can not be
      handled correctly as there is no kernel page table yet.
      
      To allow early WARN statements initially setup the lowcore with DAT off
      and set the DAT bit only after paging_init() has completed.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      87276384
    • Ilya Leoshkevich's avatar
      s390/jump_label: Use "jdd" constraint on gcc9 · 14644852
      Ilya Leoshkevich authored
      [heiko.carstens@de.ibm.com]:
      -----
      Laura Abbott reported that the kernel doesn't build anymore with gcc 9,
      due to the "X" constraint. Ilya provided the gcc 9 patch "S/390:
      Introduce jdd constraint" which introduces the new "jdd" constraint
      which fixes this.
      -----
      
      The support for section anchors on S/390 introduced in gcc9 has changed
      the behavior of "X" constraint, which can now produce register
      references. Since existing constraints, in particular, "i", do not fit
      the intended use case on S/390, the new machine-specific "jdd"
      constraint was introduced. This patch makes jump labels use "jdd"
      constraint when building with gcc9.
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      14644852
  7. 13 Feb, 2019 1 commit
    • Harald Freudenberger's avatar
      s390/zcrypt: use new state UNBOUND during queue driver rebind · b1af7528
      Harald Freudenberger authored
      When an alternate driver (vfio-ap) has bound an ap queue and this
      binding is revised the ap queue device is in an intermittent
      state not bound to any driver. The internal state variable
      covered this with the state AP_STATE_BORKED which is also used to
      reflect broken devices. When now an ap bus scan runs such a
      device is destroyed and on the next scan reconstructed.
      
      So a stress test with high frequency switching the queue driver
      between the default and the vfio-ap driver hit this gap and the
      queue was removed until the next ap bus scan. This fix now
      introduces another state for the in-between condition for a queue
      momentary not bound to a driver and so the ap bus scan function
      skips this device instead of removing it.
      
      Also some very slight but maybe helpful debug feature messages
      come with this patch - in particular a message showing that a
      broken card/queue device will get removed.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      b1af7528
  8. 07 Feb, 2019 8 commits