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
