WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Trying to get HyperSCSI and Xen to work... ;-)

To: sven.kretzschmar@xxxxxx
Subject: Re: [Xen-devel] Trying to get HyperSCSI and Xen to work... ;-)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 09 Oct 2003 00:25:15 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Oct 2003 00:26:52 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 09 Oct 2003 00:02:02 +0200." <21648.1065650522@xxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> After some puzzling I was able to compile, load and use the 
> HyperSCSI client(!) module in Xen's domain 0.
> It reported that it found the eth0 interface, but that there are no
> HyperSCSI servers on the local network.
> The same try with booting a "normal/standard" kernel on the same machine
> worked out OK, so it's a problem with Xen's VFR, I think.

Absolutely. Out of the box Xen currently only groks IP and ARP
packets. I've appended a patch to (hopefully) fix this for the first
VIF of domain 0. 

> How is this done correctly ????  (Of course, the above code did NOT work ;-)

Your fix to network.c is unnecessary -- by default unrouteable packets
from DOM0 are sent to the physical interface, and incoming packets are
sent to DOM0. However, a fix *is* required to net/dev.c.

I've appended an alternative patch, to net/dev.c. It compiles but I
haven't actually tested it out ;-) 

> 1.) I am not sure about the exact difference between VIF_PHYS and
> VIF_PHYSICAL_INTERFACE ?

The latter is used in the network rule lists. The former is returned
by get_target_vif to inform the network data path to route a packet to
teh physical interface.

> 2.) What exactly is the meaning and use of VIF_SPECIAL ?

It's a revolting hack to get the currently broken packet-forwarding
code to work properly. I very much want to get rid of it as soon as
possible :-)

> 3.) I am not really understanding the use of VIF_DOMAIN_SHIFT and 
>      VIF_DOMAIN_MASK  (some way to identify the domain # only from
>      the id by shifting ?)  ?

It's a packed representation for addressing VIFs. VIFs are indexed per
domain. E.g. DOM2, idx 3. The packed representation of that VIF, as
passed to get_vif_by_id(), is (2<<VIF_DOMAIN_SHIFT)|3.

There ought to be neat access macros to hide the packed
representation. They haven't been written yet. :-)

A lot of the network control code (e.g., routing of packets) isn't
great. We want to rework it at some point in the near future -- adding
more flexible packet forwarding, filtering and rewriting. The code has
evolved into its current form rather than being cleanly designed :-(

 Regards,
 Keir

--- 1.62/xen/net/dev.c  Tue Sep 30 12:47:02 2003
+++ edited/xen/net/dev.c        Thu Oct  9 00:14:19 2003
@@ -1800,20 +1800,28 @@
     return 0;
 }
 
-inline int init_tx_header(u8 *data, unsigned int len, struct net_device *dev)
+inline int init_tx_header(net_vif_t *vif, u8 *data, 
+                          unsigned int len, struct net_device *dev)
 {
+    int proto = ntohs(*(unsigned short *)(data + 12));
+
     memcpy(data + ETH_ALEN, dev->dev_addr, ETH_ALEN);
         
-    switch ( ntohs(*(unsigned short *)(data + 12)) )
+    switch ( proto )
     {
     case ETH_P_ARP:
         if ( len < 42 ) break;
         memcpy(data + 22, dev->dev_addr, ETH_ALEN);
-        return ETH_P_ARP;
+        break;
     case ETH_P_IP:
-        return ETH_P_IP;
+        break;
+    default:
+        /* Unsupported protocols are onyl allowed to/from VIF0/0. */
+        if ( (vif->domain->domain != 0) || (vif->idx != 0) )
+            proto = 0;
+        break;
     }
-    return 0;
+    return proto;
 }
 
 
@@ -1884,7 +1892,7 @@
         g_data = map_domain_mem(tx.addr);
 
         protocol = __constant_htons(
-            init_tx_header(g_data, tx.size, the_dev));
+            init_tx_header(vif, g_data, tx.size, the_dev));
         if ( protocol == 0 )
         {
             __make_tx_response(vif, tx.id, RING_STATUS_BAD_PAGE);


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel