From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] tap networking - how?
Date: Thu, 13 Feb 2014 18:34:56 +1100 [thread overview]
Message-ID: <52FC75A0.5020902@ozlabs.ru> (raw)
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
next reply other threads:[~2014-02-13 7:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 7:34 Alexey Kardashevskiy [this message]
2014-02-13 8:40 ` [Qemu-devel] tap networking - how? Max Filippov
2014-02-13 10:34 ` Alexey Kardashevskiy
2014-02-13 12:23 ` Max Filippov
2014-02-13 13:42 ` Alexey Kardashevskiy
2014-02-13 14:02 ` Max Filippov
2014-02-13 14:06 ` Alexey Kardashevskiy
2014-02-13 14:17 ` Max Filippov
2014-02-13 14:25 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52FC75A0.5020902@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).