> Xen seems not suport 8139too now.
> So I want to port it to xen from linux.
>
> Are there any advice about porting?
Attached is a compendium of text from earlier replies on the
subject. We really need to go through the mailing list and create
a FAQ from the text in the emails...
Thanks,
Ian
Porting network drivers is generally very straight forward. Our
device drivers use the traditional Linux API rather than the new
Linux NAPI API. (Most decent Gig Ethernet cards have hardware
interrupt hold-off, which works at least as well as NAPI anyway).
In many cases, just copying the driver into the tree and building
it will work. Getting drivers that use scatter-gather DMA working
is working is actually easier than old PIO drivers. The reason
for this is that network buffer pages are, by default, not mapped
into Xen''s address space, hence you can''t just read and write
them. You need to call map_domain_mem( phys addr ) first, then
remember to call unmap_domain_mem( virt addr ) when you''re
done. See the e100 driver for an example.
The other thing to watch out for is that Xen is entirely event
driven -- there''s no process contexts that you can use semaphores
or wait queues on. It''s just possible that there''s some
Ethernet
driver that uses these for sleeping during media detection. In
which case, it can probably be fairly easily rewritten to use
schedule_timeout (which is supported).
> One the receive side the code compiles as is, but I have not yet verified
if
> the interface it calls -- eth_copy_and_sum() -- will work, or if I need to
> changed it to somehting like this:
>
> > vdata = map_domain_mem(skb->data);
> > copy ''len'' bytes to ''vdata'' from
NIC buffer
> > unmap_domain_mem(vdata);
> > skb_put(len);
>
> as you suggested. If you (or anyone else) has any thoughts on why this
(and
> other) skbuff interfaces where not supported in Xen, that would help with
my
> digging. Remember, I''m not at all familiar with the linux kernel
source so
> I have to read it all to know what anything is doing... on the other hand
it
> is just time and code...
You will have to change it. Any function which will access the packet
data must use map_domain_mem(), as the data pointer within the skbuff
is not usable directly by Xen.
Note that some skb_* functions already do the map_domain_mem() for you
--- any skb copying function based on skb_copy_bits() is safe.
Note also that we hope fairly soon (within the next few months) to
move all device drivers into "I/O domains" running outside of Xen in
ring 1. At that point we will hopefully be able to run Linux device
drivers unmodified, so this porting pain will no longer be necessary
:-)
> A quick glance reveals that the 8139too driver contains a `watch
> thread'' (interruptible_sleep_on_timeout). This will have to be
> transformed into an event call back that uses schedule_timeout.
There are two key issues when porting 8139.
First, there''s the timer issue. That is fixed either by removing the
watch thread altogether (maybe risky) or by using add_ac_timer() to
get yourself an event callback sometime later. The end of the handler
should call add_ac_timer() again if the event is periodic.
Second, there''s the issue that 8139 doesn''t do DMA. On
transmit this
is not a problem if you don''t specify NETIF_F_SG in the NIC flags --
in that case Xen will provide you with a linearized skbuff which is
directly readable/writeable by the NIC driver. Receive is harder,
since the data page does not have a mapping in Xen''s address space. To
read out of the NIC buffer you will have to do something like:
vdata = map_domain_mem(skb->data);
copy ''len'' bytes to ''vdata'' from NIC buffer
unmap_domain_mem(vdata);
skb_put(len);
> The main modifications in the PCnet32 ethernet driver seems to be macro
that
> test if COPYBREAK is define. I notice that for network driver which were
writt
en> for Xen the main modifications was around the copybreak and also some
> adjustments with include files. Is it true if I say that the port of
network
> device from Linux to Xen is quite "easy" and that the majority of
the
> modifications are due to the differences with inlcude files and differences
wi
th> "copybreak" scheme?
Porting network drivers is usually straight forward.
We could add a few more dummy header files to make the job even
easier, but since we''re planning on moving to a new IO scheme we
haven''t put much effort into this.
Areas of memory into which packets are received are not by
default mapped into Xen''s virtual address space, hence using the
CPU to memcpy the data (as in COPYBREAK) doesn''t work unless you
add a ''map_domain_mem'' call in front of it. The quick and easy
fix in the case of pcnet32 was just to disable COPYBREAK.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM''s
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel