i suspect so, threadpool makes all things to be more async as they
were before and proper lockings does matter, i could test any patches
at evening, and i must admit i never get well uderstanding on virtio
device operations yet (in terms of virtio ring :)
On Friday, April 29, 2011, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> On Fri, Apr 29, 2011 at 1:02 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
>> So, if I understand all the things correct -- making virtio devices to
>> belong separated irqs
>> issued some race conditions on read\write operations between host and
>> guest and adding
>> thread pool revealed it, right? (because previously we were doing all
>> the work inside i/o
>> path on guest site).
>
> So does reverting commit a37089da817ce7aad9789aeb9fc09b68e088ad9a
> ("kvm tools: Use threadpool for virtio-net") fix things? I think the
> problem here is that now RX path relies on VIRTIO_PCI_QUEUE_NOTIFY to
> happen in order for it to trigger KVM_IRQ_LINE which is wrong. Using
> shared IRQs obviously masks the problem which is why reverting
> Cyrill's commit makes the problem go away.
>
> Pekka
>
--
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
