OK, maybe "robust" should read "slightly less flimsy" :)
It'd be nice if these use cases worked, under user-mode networking:
1. The user disables and re-enables a network interface in windows.
Instead of hanging, it should come back up. (Does anyone else have this
issue?)
2. The host's DNS server changes. QEMU should reread the host's DNS,
instead of requiring the user to quit QEMU and run it again. This is an
issue on a laptop.
The patch below fixes both of these. Handling use case (2) is just a few
lines -- It rereads host DNS info on each guest DHCP request.
The fix for use case (1) is thousands of lines, this may be controversial...
I transformed the slirp code into a reentrant version of itself. So,
when bringing up a network card, we can dynamically allocate a slirp
object for it. If that network card is reset, we can deallocate its
slirp stack and allocate a fresh one.
http://people.brandeis.edu/~jcoiner/qemu_idedma/usermode_net.patch
This required lots of typing and no thinking. When it was done, it worked.
The alternative would have been to debug the slirp stack, and understand
how it works and why Windows leaves it in a frozen state, when disabling
and reenabling the NIC. That might still be a good idea, considering
Linux did not seem to have the same problem. Network experts: would you
expect the slirp stack to be able to restart, mid-stream, without being
explicitly told to restart? Is there a slirp design document that would
shed light on this?
I tested the patch with Windows and Linux clients, with the '-smb' and
'-tftp' options, on a linux host. The build is also tested on a Windows
host.
This patch includes two other small changes in "vl.c" which I posted to
the list a few days ago:
* the fix to make "-smb" use the user's account rather than "nobody"
* the fix for when the CPU tick counter leaps backward following
suspend-to-disk.
Should I split those out?
Please let me know if this patch is helpful, or if it introduces bugs,
or if there would have been an easier way :)
Thanks.
-- John
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
