Re: [Qemu-devel] tap networking - how?

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 02/13/2014 07:40 PM, Max Filippov wrote:
> Hi,
> 
> On Thu, Feb 13, 2014 at 11:34 AM, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>> Hi!
>>
>> I am debugging spapr-vlan and hit the following issue.
>>
>> When I run QEMU as below, the kernel's DHCP client does not continue till I
>> hit any key in console. If I replace spapr-vlan with
>> e1000/rtl8139/virtio-net, everything is just fine. If I use "user" network
>> - everything is fine too. So the problem is with combination of spapr-vlan
>> + tap.
>>
>> The issue looks like - the guest kernel boots and then prints:
>> Sending DHCP requests ..
>> and it keeps printing dots till I press key or timeout expires. tcpdump
>> (running on the tap interface) shows one DHCP request and one DHCP response.
>>
>> What normally happens is that QEMU calls os_host_main_loop_wait() which
>> calls qemu_poll_ns() and it is sitting there till eventfd signals.
>> This eventfd is registered via qemu_init_main_loop() -> aio_context_new()
>> -> aio_set_event_notifier() but I cannot find where it gets passed to the
>> kernel (otherwise why would we need eventfd?).  When eventfd signals, QEMU
>> calls qemu_iohandler_poll() which checks if TAP device has something to
>> read and eventually calls tap_send().
>>
>> However in my bad example QEMU does not exit qemu_poll_ns() on eventfd,
>> only on stdin event.
>>
>> I can see AIO eventfd created and event_notifier_test_and_clear() is called
>> on it before the kernel starts using spapr-vlan.
>>
>> So. h_send_logical_lan() is called to sent a DHCP request packet. Now I
>> expect eventfd to signal but this does not happen. Have I missed some reset
>> or notification request or "bottom half" (virtio-net uses them but
>> e1000/rtl8139 do not)?
> 
> Sounds pretty much like the problem I had recently with opencores
> 10/100 MAC: https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00073.html
> 
> Does the following help?:


Yes, it does, thanks a lot!

While we are here and you seem to understand this stuff -
how is tap expected to work to deliver a packet from the external network
to the guest? I mean what event should be triggered in what order? My brain
is melting :( I just cannot see how receiving a packet on "tap" in the host
kernel can make os_host_main_loop_wait() exit in QEMU so it could call
qemu_iohandler_poll() and do the job. Thanks!




> diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
> index 1bd6f50..2436b5e 100644
> --- a/hw/net/spapr_llan.c
> +++ b/hw/net/spapr_llan.c
> @@ -404,6 +404,7 @@ static target_ulong
> h_add_logical_lan_buffer(PowerPCCPU *cpu,
>      vio_stq(sdev, dev->buf_list + dev->add_buf_ptr, buf);
> 
>      dev->rx_bufs++;
> +    qemu_flush_queued_packets(qemu_get_queue(dev->nic));
> 
>      DPRINTF("h_add_logical_lan_buffer():  Added buf  ptr=%d  rx_bufs=%d"
>              " bd=0x%016llx\n", dev->add_buf_ptr, dev->rx_bufs,
> 
> 


-- 
Alexey