qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [patch] robust user-mode networking


From: John Coiner
Subject: [Qemu-devel] [patch] robust user-mode networking
Date: Wed, 12 Oct 2005 22:34:05 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050731


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]