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)? Please, help. Thanks! ./qemu-system-ppc64 \ -enable-kvm \ -m 2048 \ -L qemu-ppc64-bios/ \ -machine pseries \ -trace events=qemu_trace_events \ -nographic \ -vga none \ -netdev tap,id=id0,ifname=tap-id0,script=ifup.sh,downscript=ifdown.sh \ -device spapr-vlan,id=id1,netdev=id0,mac=C0:41:49:4b:00:00 \ -kernel vml313 \ -append "root=/dev/nfs ip=dhcp selinux=0 nfsroot=10.61.145.11:/scratch/alexey/fc19nfs_/" -- Alexey