1. 10 9月, 2009 9 次提交
  2. 09 8月, 2009 1 次提交
    • G
      KVM: Avoid redelivery of edge interrupt before next edge · b4a2f5e7
      Gleb Natapov 提交于
      The check for an edge is broken in current ioapic code. ioapic->irr is
      cleared on each edge interrupt by ioapic_service() and this makes
      old_irr != ioapic->irr condition in kvm_ioapic_set_irq() to be always
      true. The patch fixes the code to properly recognise edge.
      
      Some HW emulation calls set_irq() without level change. If each such
      call is propagated to an OS it may confuse a device driver. This is the
      case with keyboard device emulation and Windows XP x64  installer on SMP VM.
      Each keystroke produce two interrupts (down/up) one interrupt is
      submitted to CPU0 and another to CPU1. This confuses Windows somehow
      and it ignores keystrokes.
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      b4a2f5e7
  3. 10 6月, 2009 9 次提交
  4. 24 3月, 2009 3 次提交
  5. 31 12月, 2008 2 次提交
  6. 15 10月, 2008 2 次提交
  7. 20 7月, 2008 2 次提交
  8. 06 7月, 2008 1 次提交
    • M
      KVM: IOAPIC: Fix level-triggered irq injection hang · 35baff25
      Mark McLoughlin 提交于
      The "remote_irr" variable is used to indicate an interrupt
      which has been received by the LAPIC, but not acked.
      
      In our EOI handler, we unset remote_irr and re-inject the
      interrupt if the interrupt line is still asserted.
      
      However, we do not set remote_irr here, leading to a
      situation where if kvm_ioapic_set_irq() is called, then we go
      ahead and call ioapic_service(). This means that IRR is
      re-asserted even though the interrupt is currently in service
      (i.e. LAPIC IRR is cleared and ISR/TMR set)
      
      The issue with this is that when the currently executing
      interrupt handler finishes and writes LAPIC EOI, then TMR is
      unset and EOI sent to the IOAPIC. Since IRR is now asserted,
      but TMR is not, then when the second interrupt is handled,
      no EOI is sent and if there is any pending interrupt, it is
      not re-injected.
      
      This fixes a hang only seen while running mke2fs -j on an
      8Gb virtio disk backed by a fully sparse raw file, with
      aliguori "avoid fragmented virtio-blk transfers by copying"
      changes.
      Signed-off-by: NMark McLoughlin <markmc@redhat.com>
      Acked-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      35baff25
  9. 24 6月, 2008 1 次提交
    • A
      KVM: ioapic: fix lost interrupt when changing a device's irq · 4fa6b9c5
      Avi Kivity 提交于
      The ioapic acknowledge path translates interrupt vectors to irqs.  It
      currently uses a first match algorithm, stopping when it finds the first
      redirection table entry containing the vector.  That fails however if the
      guest changes the irq to a different line, leaving the old redirection table
      entry in place (though masked).  Result is interrupts not making it to the
      guest.
      
      Fix by always scanning the entire redirection table.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      4fa6b9c5
  10. 07 6月, 2008 1 次提交
    • M
      KVM: IOAPIC: only set remote_irr if interrupt was injected · ff4b9df8
      Marcelo Tosatti 提交于
      There's a bug in the IOAPIC code for level-triggered interrupts. Its
      relatively easy to trigger by sharing (virtio-blk + usbtablet was the
      testcase, initially reported by Gerd von Egidy).
      
      The "remote_irr" variable is used to indicate accepted but not yet acked
      interrupts. Its cleared from the EOI handler.
      
      Problem is that the EOI handler clears remote_irr unconditionally, even
      if it reinjected another pending interrupt.
      
      In that case, kvm_ioapic_set_irq() proceeds to ioapic_service() which
      sets remote_irr even if it failed to inject (since the IRR was high due
      to EOI reinjection).
      
      Since the TMR bit has been cleared by the first EOI, the second one
      fails to clear remote_irr.
      
      End result is interrupt line dead.
      
      Fix it by setting remote_irr only if a new pending interrupt has been
      generated (and the TMR bit for vector in question set).
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      ff4b9df8
  11. 04 3月, 2008 1 次提交
    • A
      KVM: Route irq 0 to vcpu 0 exclusively · 8c35f237
      Avi Kivity 提交于
      Some Linux versions allow the timer interrupt to be processed by more than
      one cpu, leading to hangs due to tsc instability.  Work around the issue
      by only disaptching the interrupt to vcpu 0.
      
      Problem analyzed (and patch tested) by Sheng Yang.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      8c35f237
  12. 31 1月, 2008 3 次提交
  13. 30 1月, 2008 5 次提交