1. 18 9月, 2012 1 次提交
    • M
      KVM: make processes waiting on vcpu mutex killable · 9fc77441
      Michael S. Tsirkin 提交于
      vcpu mutex can be held for unlimited time so
      taking it with mutex_lock on an ioctl is wrong:
      one process could be passed a vcpu fd and
      call this ioctl on the vcpu used by another process,
      it will then be unkillable until the owner exits.
      
      Call mutex_lock_killable instead and return status.
      Note: mutex_lock_interruptible would be even nicer,
      but I am not sure all users are prepared to handle EINTR
      from these ioctls. They might misinterpret it as an error.
      
      Cleanup paths expect a vcpu that can't be used by
      any userspace so this will always succeed - catch bugs
      by calling BUG_ON.
      
      Catch callers that don't check return state by adding
      __must_check.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      9fc77441
  2. 06 9月, 2012 3 次提交
  3. 28 8月, 2012 1 次提交
  4. 27 8月, 2012 1 次提交
  5. 22 8月, 2012 7 次提交
  6. 06 8月, 2012 8 次提交
  7. 26 7月, 2012 2 次提交
  8. 23 7月, 2012 2 次提交
  9. 20 7月, 2012 3 次提交
  10. 19 7月, 2012 1 次提交
  11. 07 7月, 2012 1 次提交
  12. 04 7月, 2012 1 次提交
  13. 03 7月, 2012 1 次提交
  14. 18 6月, 2012 1 次提交
  15. 05 6月, 2012 2 次提交
  16. 01 5月, 2012 1 次提交
  17. 24 4月, 2012 1 次提交
  18. 12 4月, 2012 1 次提交
    • A
      KVM: unmap pages from the iommu when slots are removed · 32f6daad
      Alex Williamson 提交于
      We've been adding new mappings, but not destroying old mappings.
      This can lead to a page leak as pages are pinned using
      get_user_pages, but only unpinned with put_page if they still
      exist in the memslots list on vm shutdown.  A memslot that is
      destroyed while an iommu domain is enabled for the guest will
      therefore result in an elevated page reference count that is
      never cleared.
      
      Additionally, without this fix, the iommu is only programmed
      with the first translation for a gpa.  This can result in
      peer-to-peer errors if a mapping is destroyed and replaced by a
      new mapping at the same gpa as the iommu will still be pointing
      to the original, pinned memory address.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      32f6daad
  19. 08 4月, 2012 2 次提交