X-Git-Url: http://xvm.mit.edu/gitweb/invirt/packages/invirt-xen-config.git/blobdiff_plain/a6b65f6b004fde0e3d108b8e6821bd4c5b266ed0..eec0fc5b94f1bed727d1255dba2dc6cfd046a871:/vif-invirtroute?ds=sidebyside

diff --git a/vif-invirtroute b/vif-invirtroute
index c76a95e..ed2d072 100755
--- a/vif-invirtroute
+++ b/vif-invirtroute
@@ -23,7 +23,6 @@
 # type read to determine if the device is ioemu
 
 #============================================================================
-
 dir=$(dirname "$0")
 . "$dir/vif-common.sh"
 
@@ -31,19 +30,22 @@ main_ip=$(dom0_ip)
 dev=${dev:-${vif}}
 
 case "$command" in
-    online)
+    online|add)
         ifconfig ${dev} ${main_ip} netmask 255.255.255.255 up
         echo 1 >/proc/sys/net/ipv4/conf/${dev}/proxy_arp
 	echo 1 >/proc/sys/net/ipv4/conf/${dev}/rp_filter 
+	xenstore-write "$XENBUS_PATH/feature-gso-tcpv4" 0
         if [ x${qemu_online} != xyes ]; then
           ethtool -K ${dev} tx off
         fi
         ipcmd='add'
+	ipt_action='-A'
         cmdprefix=''
         ;;
-    offline)
+    offline|remove)
         do_without_error ifdown ${vif}
         ipcmd='del'
+	ipt_action='-D'
         cmdprefix='do_without_error'
         ;;
 esac
@@ -54,16 +56,59 @@ if [  ${vif_type} != "ioemu"  -o  x${qemu_online} = xyes ] ; then
     # If we've been given a list of IP addresses, then add routes from dom0 to
     # the guest using those addresses.
 	for addr in ${ip} ; do
-	    ${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip}
-	    arpspoof -i $(invirt-getconf xen.iface) -t 18.181.0.1 ${addr}&
-	    sleep 5
-	    kill %arpspoof
+	    # When PVHVM is enabled, Xen plugs two interfaces into
+	    # HVMs - an emulated tap device and a paravirt vif device.
+	    # vif-invirtroute (and vif-route, for that matter!) will
+	    # fail when the second one is brought up, because the
+	    # second invocation of 'ip route add' is identical to the
+	    # first (same source and destination IPs) and the kernel
+	    # rejects the new route.
+	    #
+	    # We work around this by adding the routes with different metrics.
+	    # This should work because:
+	    #
+	    # 1) In the case of a pv-aware guest, the kernel will
+	    # unplug the tap interface, which will bring down the tap
+	    # interface's route, leaving only the one via the vif (and
+	    # so the metric shouldn't matter, because it's the only
+	    # route)
+	    #
+	    # 2) In the case of a non-pv-aware guest, the tap route
+	    # (with metric 1) should take precedence over the vif
+	    # route and carry all the traffic.
+
+	    if [ $ipcmd == "add" ]; then
+		case $dev in
+		    vif*)
+			metric="metric 2"
+			;;
+		    tap*)
+			metric="metric 1"
+			;;
+		esac
+	    fi
+	    ${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip} $metric
+	    case "$command" in
+		online|add)
+		    timeout 5 arpspoof -i $(invirt-getconf xen.iface) -t ${gateway} ${addr} || :
+		    ;;
+	    esac
 	done 
+	if [ -n "$other_ip" ]; then
+	    ${cmdprefix} ip route ${ipcmd} ${other_ip} dev ${dev} src ${main_ip} $metric
+	    iptables -t nat ${ipt_action} PREROUTING -d ${other_ip} -j DNAT --to-destination ${addr}
+	    case "$command" in
+		online|add)
+		    timeout 5 arpspoof -i $(invirt-getconf xen.iface) -t ${other_gateway} ${other_ip} || :
+		    ;;
+	    esac
+	fi
     fi
 fi
 
 log debug "Successful vif-route $command for $vif."
-if [ "$command" == "online" ]
-then
-  success
-fi
+case "$command" in
+    online|add)
+	success
+	;;
+esac