Re: [PATCH] kvm: ioapic: conditionally delay irq delivery during eoi broadcast

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/12/2012 05:23 PM, Gleb Natapov wrote:
On Mon, Mar 12, 2012 at 05:07:35PM +0800, Jason Wang wrote:
>  Currently, we call ioapic_service() immediately when we find the irq is still
>  active during eoi broadcast. But for real hardware, there's some dealy between
>  the EOI writing and irq delivery (system bus latency?). So we need to emulate
>  this behavior. Otherwise, for a guest who haven't register a proper irq handler
>  , it would stay in the interrupt routine as this irq would be re-injected
>  immediately after guest enables interrupt. This would lead guest can't move
>  forward and may miss the possibility to get proper irq handler registered (one
>  example is windows guest resuming from hibernation).
>
Yes, I saw this behaviour with Windows NICs, but it looks like the
guest bug. Does this happen with other kind of devices too? Because
if it does not then the correct hack would be to add a delay between
Windows enabling PHY and sending first interrupt to a guest. This will
model what happens on real HW. NIC does not start receiving packets at
the same moment PHY is enabled. Some time is spent bring up the link.


Looks common for any unhandled level irq but I haven't tried. What I've tested is running a similar test program by hacking the card driver and let it run in both real physical machine and a kvm guest, and see what happens if there's no irq handled:

- In real hardware, there's a gap between two successive irqs injected by eoi broadcast, and OS can move forward. - In a kvm guest, no gap, guest can't move forward and would always stay in the irq context forever.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux