On Fri, 2011-04-29 at 12:22 +0200, Ingo Molnar wrote: > If that is so then indeed the right approach might be to signal the guest > every > time we manage to readv() something - there might not come any other packet > for > a long time. But the reason is not some 'erroneous state' - all state is > perfectly fine, this is simply a basic property of the event loop that the rx > thread implements ...
My idea as for 'erroneous state' was as follows: We have 2 virt queues: one for RX and one for TX, each on it's own thread. RX Thread: - Runs readv() and reads data. - Calls virt_queue__set_used_elem() which starts updating the RX virt queue. TX Thread: - Runs readv() and reads data. - Calls and returns from virt_queue__set_used_elem(). - Calls kvm__irq_line(). At this point, The RX queue state is being updated but since the IRQ was signaled (same IRQ for both TX and RX) the guest virtio-net checks the RX queue and finds a virt queue that wasn't fully updated. -- Sasha. -- 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
