* Pekka Enberg <[email protected]> wrote:
> On Fri, Apr 29, 2011 at 1:32 PM, Ingo Molnar <[email protected]> wrote:
> >>> Without the mutex around the kvm__irq_line, I am still seeing the
> >>> hangs(with the irq assertion movement patch).
> >>
> >> since the mutex has no effect on the other party that modifies the virtual
> >> queue (the guest OS), this at best only changes timings and hides the bug.
>
> On Fri, Apr 29, 2011 at 1:42 PM, Pekka Enberg <[email protected]> wrote:
> > Yes, I don't think it has anything to do with the queues - it's simply
> > a bug in the RX path which requires other work to happen to raise the
> > IRQ.
>
> Turns out thread pool isn't related to the problem. Asias and Sasha reported
> that the problem triggers even with all the thread pool code reverted. I'm
> guessing it's a latent bug in the virtio network driver that got exposed by
> Cyrill's patch. It seems to be related to IRQ handling and I still think it's
> related to assuming VIRTIO_PCI_QUEUE_NOTIFY will be triggered for the RX
> path.
Some sort of timeout would make it more robust i suspect, although the guest
can always 'hang' both the rx and tx flow: by not clearing ring entries.
So i think it needs to be understood how those stalls occur - who misses to
issue a notification?
Also, do perhaps TX activity assume a wakeup for RX processing? Right now the
TX and RX threads are independent. So it would be nice to document how the
virtio protocol works.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
