Re: [Qemu-devel] net/tap.c: Possibly a way to stall tap input

[Jan Kiszka]

On 2013-08-02 09:33, Stefan Hajnoczi wrote:
> On Thu, Aug 01, 2013 at 07:24:13PM +0200, Jan Kiszka wrote:
>> On 2013-08-01 19:15, Jan Kiszka wrote:
>>> Hi all,
>>>
>>> I'm tracking down a nasty stall of tap input over a custom 1.3.x QEMU
>>> version. Under certain load, our tap backend stops reading from the char
>>> device, and that even if we reset the guest. The frontend device
>>> (pcnet32) is able to receive (can_receive would return > 0), but the
>>    ^^^^^^^
>> Yes, the pcnet lacks qemu_flush_queued_packets, like certain other NIC
>> models already have. We added that to pcnet_init and pcnet_start (patch
>> will follow), but that didn't make a difference, likely due to what I
>> described below.
> 
> Yes, you need to add qemu_flush_queued_packets() where the guest enables
> RX or marks RX descriptors free (usually by writing to a hardware
> register to update the RX ring index).

For the pcnet, this is different as can_receive checks for stop and
suspend states.

> 
> Please also confirm that you are using -netdev tap -device pcnet32
> instead of the legacy -net syntax.  The reason I'm asking is because I
> remember the same issue with net/hub.c, which gets in the way if you use
> legacy syntax (see 199ee608).

We are using legacy syntax. But my analysis of the issue in tap.c
appears to be independent of other networking components. Possibly,
other setup paper over it, but the conceptual issue remains.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux