1. 04 2月, 2015 3 次提交
  2. 14 12月, 2014 1 次提交
  3. 12 11月, 2014 1 次提交
    • O
      iommu/amd: Fix accounting of device_state · 1c51099a
      Oded Gabbay 提交于
      This patch fixes a bug in the accounting of the
      device_state.  In the current code, the device_state was put
      (decremented) too many times, which sometimes lead to the
      driver getting stuck permanently in put_device_state_wait().
      That happen because the device_state->count would go below
      zero, which is never supposed to happen.
      
      The root cause is that the device_state was decremented in
      put_pasid_state() and put_pasid_state_wait() but also in all
      the functions that call those functions. Therefore, the
      device_state was decremented twice in each of these code
      paths.
      
      The fix is to decouple the device_state accounting from the
      pasid_state accounting - remove the call to
      put_device_state() from the put_pasid_state() and the
      put_pasid_state_wait())
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      1c51099a
  4. 24 9月, 2014 1 次提交
    • A
      kvm: Fix page ageing bugs · 57128468
      Andres Lagar-Cavilla 提交于
      1. We were calling clear_flush_young_notify in unmap_one, but we are
      within an mmu notifier invalidate range scope. The spte exists no more
      (due to range_start) and the accessed bit info has already been
      propagated (due to kvm_pfn_set_accessed). Simply call
      clear_flush_young.
      
      2. We clear_flush_young on a primary MMU PMD, but this may be mapped
      as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
      This required expanding the interface of the clear_flush_young mmu
      notifier, so a lot of code has been trivially touched.
      
      3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
      the access bit by blowing the spte. This requires proper synchronizing
      with MMU notifier consumers, like every other removal of spte's does.
      Signed-off-by: NAndres Lagar-Cavilla <andreslc@google.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      57128468
  5. 30 7月, 2014 4 次提交
  6. 10 7月, 2014 9 次提交
  7. 09 7月, 2014 1 次提交
  8. 20 6月, 2014 1 次提交
    • J
      iommu/amd: Fix small race between invalidate_range_end/start · d73a6d72
      Joerg Roedel 提交于
      Commit e79df31c introduced mmu_notifer_count to protect
      against parallel mmu_notifier_invalidate_range_start/end
      calls. The patch left a small race condition when
      invalidate_range_end() races with a new
      invalidate_range_start() the empty page-table may be
      reverted leading to stale TLB entries in the IOMMU and the
      device. Use a spin_lock instead of just an atomic variable
      to eliminate the race.
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      d73a6d72
  9. 26 5月, 2014 5 次提交
  10. 13 5月, 2014 1 次提交
  11. 10 11月, 2014 1 次提交
    • O
      iommu/amd: fix accounting of device_state · a015c1e9
      Oded Gabbay 提交于
      This patch fixes a bug in the accounting of the device_state.
      In the current code, the device_state was put (decremented) too many times,
      which sometimes lead to the driver getting stuck permanently in
      put_device_state_wait(). That happen because the device_state->count would go
      below zero, which is never supposed to happen.
      
      The root cause is that the device_state was decremented in put_pasid_state()
      and put_pasid_state_wait() but also in all the functions that call those
      functions. Therefore, the device_state was decremented twice in each of these
      code paths.
      
      The fix is to decouple the device_state accounting from the pasid_state
      accounting - remove the call to put_device_state() from the
      put_pasid_state() and the put_pasid_state_wait())
      Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      a015c1e9
  12. 13 11月, 2014 1 次提交
  13. 24 7月, 2012 1 次提交
  14. 19 7月, 2012 1 次提交
  15. 17 7月, 2012 1 次提交
  16. 15 3月, 2012 1 次提交
  17. 15 12月, 2011 1 次提交
  18. 14 12月, 2011 2 次提交
  19. 12 12月, 2011 4 次提交