* Pekka Enberg <penberg@xxxxxxxxxx> wrote: > On Fri, Apr 29, 2011 at 1:32 PM, Ingo Molnar <mingo@xxxxxxx> 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 <penberg@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
