1. 17 3月, 2014 1 次提交
  2. 04 3月, 2014 5 次提交
  3. 27 2月, 2014 2 次提交
  4. 30 1月, 2014 5 次提交
  5. 20 1月, 2014 1 次提交
    • C
      KVM: s390: Fix memory access error detection · 699bde3b
      Christian Borntraeger 提交于
      Seems that commit 210b1607
      (KVM: s390: Removed SIE_INTERCEPT_UCONTROL) lost a hunk when we
      reworked our patch queue to rework the async_fp code. We now
      ignore faults on the sie instruction (guest accesses non-existing
      memory) instead of sending a fault into the guest. This leads to
      hang situations with the old virtio transport that checks for
      descriptor memory after guest memory. Instead of bailing out this
      code now goes wild...
      Lets re-add the check.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      699bde3b
  6. 17 1月, 2014 2 次提交
  7. 16 1月, 2014 1 次提交
  8. 12 12月, 2013 5 次提交
  9. 28 11月, 2013 9 次提交
  10. 24 10月, 2013 2 次提交
  11. 22 10月, 2013 1 次提交
    • M
      s390/time: correct use of store clock fast · 8c071b0f
      Martin Schwidefsky 提交于
      The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
      It can happen that the value stored on one CPU is smaller than the value
      stored on another CPU, although the order of the stores is the other
      way around. This can cause deltas of get_tod_clock() values to become
      negative when they should not be.
      
      We need to be more careful with store-clock-fast, this patch partially
      reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
      always use stckf instead of stck if available". The get_tod_clock()
      function now uses the store-clock-extended (STCKE) instruction.
      get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
      is acceptable e.g. for wait loops local to a CPU.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c071b0f
  12. 17 10月, 2013 1 次提交
  13. 25 9月, 2013 5 次提交