1. 18 May, 2016 1 commit
  2. 03 Mar, 2016 2 commits
  3. 25 Nov, 2015 1 commit
  4. 14 Oct, 2015 1 commit
    • Radim Krčmář's avatar
      KVM: x86: fix edge EOI and IOAPIC reconfig race · db2bdcbb
      Radim Krčmář authored
      KVM uses eoi_exit_bitmap to track vectors that need an action on EOI.
      The problem is that IOAPIC can be reconfigured while an interrupt with
      old configuration is pending and eoi_exit_bitmap only remembers the
      newest configuration;  thus EOI from the pending interrupt is not
      (Reconfiguration is not a problem for level interrupts, because IOAPIC
       sends interrupt with the new configuration.)
      For an edge interrupt with ACK notifiers, like i8254 timer; things can
      happen in this order
       1) IOAPIC inject a vector from i8254
       2) guest reconfigures that vector's VCPU and therefore eoi_exit_bitmap
          on original VCPU gets cleared
       3) guest's handler for the vector does EOI
       4) KVM's EOI handler doesn't pass that vector to IOAPIC because it is
          not in that VCPU's eoi_exit_bitmap
       5) i8254 stops working
      A simple solution is to set the IOAPIC vector in eoi_exit_bitmap if the
      vector is in PIR/IRR/ISR.
      This creates an unwanted situation if the vector is reused by a
      non-IOAPIC source, but I think it is so rare that we don't want to make
      the solution more sophisticated.  The simple solution also doesn't work
      if we are reconfiguring the vector.  (Shouldn't happen in the wild and
      I'd rather fix users of ACK notifiers instead of working around that.)
      The are no races because ioapic injection and reconfig are locked.
      Fixes: b053b2ae ("KVM: x86: Add EOI exit bitmap inference")
      [Before b053b2ae, this bug happened only with APICv.]
      Fixes: c7c9c56c ("x86, apicv: add virtual interrupt delivery support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  5. 01 Oct, 2015 2 commits
    • Paolo Bonzini's avatar
      KVM: x86: store IOAPIC-handled vectors in each VCPU · 3bb345f3
      Paolo Bonzini authored
      We can reuse the algorithm that computes the EOI exit bitmap to figure
      out which vectors are handled by the IOAPIC.  The only difference
      between the two is for edge-triggered interrupts other than IRQ8
      that have no notifiers active; however, the IOAPIC does not have to
      do anything special for these interrupts anyway.
      This again limits the interactions between the IOAPIC and the LAPIC,
      making it easier to move the former to userspace.
      Inspired by a patch from Steve Rutherford.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      KVM: x86: set TMR when the interrupt is accepted · bdaffe1d
      Paolo Bonzini authored
      Do not compute TMR in advance.  Instead, set the TMR just before the interrupt
      is accepted into the IRR.  This limits the coupling between IOAPIC and LAPIC.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  6. 07 May, 2015 2 commits
  7. 26 Mar, 2015 1 commit
  8. 23 Mar, 2015 2 commits
  9. 10 Mar, 2015 1 commit
  10. 21 Nov, 2014 2 commits
  11. 20 Nov, 2014 1 commit
  12. 16 Sep, 2014 1 commit
    • Zhang Haoyu's avatar
      kvm: ioapic: conditionally delay irq delivery duringeoi broadcast · 184564ef
      Zhang Haoyu authored
      Currently, we call ioapic_service() immediately when we find the irq is still
      active during eoi broadcast. But for real hardware, there's some delay between
      the EOI writing and irq delivery.  If we do not emulate this behavior, and
      re-inject the interrupt immediately after the guest sends an EOI and re-enables
      interrupts, a guest might spend all its time in the ISR if it has a broken
      handler for a level-triggered interrupt.
      Such livelock actually happens with Windows guests when resuming from
      As there's no way to recognize the broken handle from new raised ones, this patch
      delays an interrupt if 10.000 consecutive EOIs found that the interrupt was
      still high.  The guest can then make a little forward progress, until a proper
      IRQ handler is set or until some detection routine in the guest (such as
      Linux's note_interrupt()) recognizes the situation.
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarZhang Haoyu <zhanghy@sangfor.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  13. 30 Jul, 2014 1 commit
    • Paolo Bonzini's avatar
      KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table · 0f6c0a74
      Paolo Bonzini authored
      Currently, the EOI exit bitmap (used for APICv) does not include
      interrupts that are masked.  However, this can cause a bug that manifests
      as an interrupt storm inside the guest.  Alex Williamson reported the
      bug and is the one who really debugged this; I only wrote the patch. :)
      The scenario involves a multi-function PCI device with OHCI and EHCI
      USB functions and an audio function, all assigned to the guest, where
      both USB functions use legacy INTx interrupts.
      As soon as the guest boots, interrupts for these devices turn into an
      interrupt storm in the guest; the host does not see the interrupt storm.
      Basically the EOI path does not work, and the guest continues to see the
      interrupt over and over, even after it attempts to mask it at the APIC.
      The bug is only visible with older kernels (RHEL6.5, based on 2.6.32
      with not many changes in the area of APIC/IOAPIC handling).
      Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ)
      on in the eoi_exit_bitmap and TMR, and things then work.  What happens
      is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap.
      It does not have set bit 59 because the RTE was masked, so the IOAPIC
      never sees the EOI and the interrupt continues to fire in the guest.
      My guess was that the guest is masking the interrupt in the redirection
      table in the interrupt routine, i.e. while the interrupt is set in a
      LAPIC's ISR, The simplest fix is to ignore the masking state, we would
      rather have an unnecessary exit rather than a missed IRQ ACK and anyway
      IOAPIC interrupts are not as performance-sensitive as for example MSIs.
      Alex tested this patch and it fixed his bug.
      [Thanks to Alex for his precise description of the problem
       and initial debugging effort.  A lot of the text above is
       based on emails exchanged with him.]
      Reported-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Tested-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  14. 04 Apr, 2014 2 commits
    • Paolo Bonzini's avatar
      KVM: ioapic: try to recover if pending_eoi goes out of range · 4009b249
      Paolo Bonzini authored
      The RTC tracking code tracks the cardinality of rtc_status.dest_map
      into rtc_status.pending_eoi.  It has some WARN_ONs that trigger if
      pending_eoi ever becomes negative; however, these do not do anything
      to recover, and it bad things will happen soon after they trigger.
      When the next RTC interrupt is triggered, rtc_check_coalesced() will
      return false, but ioapic_service will find pending_eoi != 0 and
      do a BUG_ON.  To avoid this, should pending_eoi ever be nonzero,
      call kvm_rtc_eoi_tracking_restore_all to recompute a correct
      dest_map and pending_eoi.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      KVM: ioapic: fix assignment of ioapic->rtc_status.pending_eoi (CVE-2014-0155) · 5678de3f
      Paolo Bonzini authored
      QE reported that they got the BUG_ON in ioapic_service to trigger.
      I cannot reproduce it, but there are two reasons why this could happen.
      The less likely but also easiest one, is when kvm_irq_delivery_to_apic
      does not deliver to any APIC and returns -1.
      Because irqe.shorthand == 0, the kvm_for_each_vcpu loop in that
      function is never reached.  However, you can target the similar loop in
      kvm_irq_delivery_to_apic_fast; just program a zero logical destination
      address into the IOAPIC, or an out-of-range physical destination address.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  15. 21 Mar, 2014 4 commits
  16. 13 Mar, 2014 1 commit
    • Gabriel L. Somlo's avatar
      kvm: x86: ignore ioapic polarity · 100943c5
      Gabriel L. Somlo authored
      Both QEMU and KVM have already accumulated a significant number of
      optimizations based on the hard-coded assumption that ioapic polarity
      will always use the ActiveHigh convention, where the logical and
      physical states of level-triggered irq lines always match (i.e.,
      active(asserted) == high == 1, inactive == low == 0). QEMU guests
      are expected to follow directions given via ACPI and configure the
      ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
      guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
      QEMU will still use the ActiveHigh signaling convention when
      interfacing with KVM.
      This patch modifies KVM to completely ignore ioapic polarity as set by
      the guest OS, enabling misbehaving guests to work alongside those which
      comply with the ActiveHigh polarity specified by QEMU's ACPI tables.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGabriel L. Somlo <somlo@cmu.edu>
      [Move documentation to KVM_IRQ_LINE, add ia64. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
  17. 08 Jan, 2014 1 commit
  18. 16 Apr, 2013 2 commits
  19. 15 Apr, 2013 6 commits
  20. 07 Apr, 2013 1 commit
  21. 19 Mar, 2013 1 commit
  22. 29 Jan, 2013 1 commit
  23. 23 Dec, 2012 1 commit
  24. 14 Aug, 2012 1 commit
  25. 20 Jul, 2012 1 commit