On 02/13/2014 07:40 PM, Max Filippov wrote: > Hi, > > On Thu, Feb 13, 2014 at 11:34 AM, Alexey Kardashevskiy <a...@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