1. 15 Jun, 2012 1 commit
  2. 05 Jun, 2012 1 commit
    • Avi Kivity's avatar
      KVM: Fix buffer overflow in kvm_set_irq() · f2ebd422
      Avi Kivity authored
      kvm_set_irq() has an internal buffer of three irq routing entries, allowing
      connecting a GSI to three IRQ chips or on MSI.  However setup_routing_entry()
      does not properly enforce this, allowing three irqchip routes followed by
      an MSI route to overflow the buffer.
      
      Fix by ensuring that an MSI entry is added to an empty list.
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      f2ebd422
  3. 30 Apr, 2012 1 commit
  4. 24 Apr, 2012 1 commit
  5. 18 Apr, 2012 1 commit
    • Alex Williamson's avatar
      KVM: lock slots_lock around device assignment · 21a1416a
      Alex Williamson authored
      As pointed out by Jason Baron, when assigning a device to a guest
      we first set the iommu domain pointer, which enables mapping
      and unmapping of memory slots to the iommu.  This leaves a window
      where this path is enabled, but we haven't synchronized the iommu
      mappings to the existing memory slots.  Thus a slot being removed
      at that point could send us down unexpected code paths removing
      non-existent pinnings and iommu mappings.  Take the slots_lock
      around creating the iommu domain and initial mappings as well as
      around iommu teardown to avoid this race.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      21a1416a
  6. 16 Apr, 2012 1 commit
    • Michael S. Tsirkin's avatar
      KVM: dont clear TMR on EOI · a0c9a822
      Michael S. Tsirkin authored
      Intel spec says that TMR needs to be set/cleared
      when IRR is set, but kvm also clears it on  EOI.
      
      I did some tests on a real (AMD based) system,
      and I see same TMR values both before
      and after EOI, so I think it's a minor bug in kvm.
      
      This patch fixes TMR to be set/cleared on IRR set
      only as per spec.
      
      And now that we don't clear TMR, we can save
      an atomic read of TMR on EOI that's not propagated
      to ioapic, by checking whether ioapic needs
      a specific vector first and calculating
      the mode afterwards.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      a0c9a822
  7. 11 Apr, 2012 1 commit
    • Alex Williamson's avatar
      KVM: unmap pages from the iommu when slots are removed · 32f6daad
      Alex Williamson authored
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      32f6daad
  8. 08 Apr, 2012 4 commits
  9. 20 Mar, 2012 1 commit
  10. 08 Mar, 2012 8 commits
  11. 05 Mar, 2012 5 commits
  12. 01 Feb, 2012 1 commit
    • Takuya Yoshikawa's avatar
      KVM: Fix __set_bit() race in mark_page_dirty() during dirty logging · 50e92b3c
      Takuya Yoshikawa authored
      It is possible that the __set_bit() in mark_page_dirty() is called
      simultaneously on the same region of memory, which may result in only
      one bit being set, because some callers do not take mmu_lock before
      mark_page_dirty().
      
      This problem is hard to produce because when we reach mark_page_dirty()
      beginning from, e.g., tdp_page_fault(), mmu_lock is being held during
      __direct_map():  making kvm-unit-tests' dirty log api test write to two
      pages concurrently was not useful for this reason.
      
      So we have confirmed that there can actually be race condition by
      checking if some callers really reach there without holding mmu_lock
      using spin_is_locked():  probably they were from kvm_write_guest_page().
      
      To fix this race, this patch changes the bit operation to the atomic
      version:  note that nr_dirty_pages also suffers from the race but we do
      not need exactly correct numbers for now.
      Signed-off-by: default avatarTakuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      50e92b3c
  13. 12 Jan, 2012 1 commit
  14. 27 Dec, 2011 13 commits