1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
<table class="head">
<tr>
<td class="head-ltitle">XNB(4)</td>
<td class="head-vol">Device Drivers Manual</td>
<td class="head-rtitle">XNB(4)</td>
</tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">xnb</code> — <span class="Nd">Xen
Paravirtualized Backend Ethernet Driver</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp">To compile this driver into the kernel, place the following lines
in your kernel configuration file:</p>
<div class="Bd Pp Bd-indent"><code class="Cd">options XENHVM</code>
<br/>
<code class="Cd">device xenpci</code></div>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">xnb</code> driver provides the back half of a
paravirtualized <a class="Xr">xen(4)</a> network connection. The netback and
netfront drivers appear to their respective operating systems as Ethernet
devices linked by a crossover cable. Typically, <code class="Nm">xnb</code>
will run on Domain 0 and the netfront driver will run on a guest domain.
However, it is also possible to run <code class="Nm">xnb</code> on a guest
domain. It may be bridged or routed to provide the netfront domain access to
other guest domains or to a physical network.</p>
<p class="Pp">In most respects, the <code class="Nm">xnb</code> device appears
to the OS as any other Ethernet device. It can be configured at runtime
entirely with <a class="Xr">ifconfig(8)</a>. In particular, it supports MAC
changing, arbitrary MTU sizes, checksum offload for IP, UDP, and TCP for
both receive and transmit, and TSO. However, see
<a class="Sx" href="#CAVEATS">CAVEATS</a> before enabling txcsum, rxcsum, or
tso.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYSCTL_VARIABLES"><a class="permalink" href="#SYSCTL_VARIABLES">SYSCTL
VARIABLES</a></h1>
<p class="Pp">The following read-only variables are available via
<a class="Xr">sysctl(8)</a>:</p>
<dl class="Bl-tag">
<dt id="dev.xnb._d.dump_rings"><var class="Va">dev.xnb.%d.dump_rings</var></dt>
<dd>Displays information about the ring buffers used to pass requests between
the netfront and netback. Mostly useful for debugging, but can also be
used to get traffic statistics.</dd>
<dt id="dev.xnb._d.unit_test_results"><var class="Va">dev.xnb.%d.unit_test_results</var></dt>
<dd>Runs a builtin suite of unit tests and displays the results. Does not
affect the operation of the driver in any way. Note that the test suite
simulates error conditions; this will result in error messages being
printed to the system log.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
ALSO</a></h1>
<p class="Pp"><a class="Xr">arp(4)</a>, <a class="Xr">netintro(4)</a>,
<a class="Xr">ng_ether(4)</a>, <a class="Xr">xen(4)</a>,
<a class="Xr">ifconfig(8)</a></p>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">xnb</code> device driver first appeared in
<span class="Ux">FreeBSD 10.0</span>.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp">The <code class="Nm">xnb</code> driver was written by
<span class="An">Alan Somers</span>
<<a class="Mt" href="mailto:asomers@FreeBSD.org">asomers@FreeBSD.org</a>>
and John Suykerbuyk.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="CAVEATS"><a class="permalink" href="#CAVEATS">CAVEATS</a></h1>
<p class="Pp">Packets sent through Xennet pass over shared memory, so the
protocol includes no form of link-layer checksum or CRC. Furthermore, Xennet
drivers always report to their hosts that they support receive and transmit
checksum offloading. They "offload" the checksum calculation by
simply skipping it. That works fine for packets that are exchanged between
two domains on the same machine. However, when a Xennet interface is bridged
to a physical interface, a correct checksum must be attached to any packets
bound for that physical interface. Currently,
<span class="Ux">FreeBSD</span> lacks any mechanism for an Ethernet device
to inform the OS that newly received packets are valid even though their
checksums are not. So if the netfront driver is configured to offload
checksum calculations, it will pass non-checksumed packets to
<code class="Nm">xnb</code>, which must then calculate the checksum in
software before passing the packet to the OS.</p>
<p class="Pp">For this reason, it is recommended that if
<code class="Nm">xnb</code> is bridged to a physical interface, then
transmit checksum offloading should be disabled on the netfront. The Xennet
protocol does not have any mechanism for the netback to request the netfront
to do this; the operator must do it manually.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1>
<p class="Pp">The <code class="Nm">xnb</code> driver does not properly checksum
UDP datagrams that span more than one Ethernet frame. Nor does it correctly
checksum IPv6 packets. To workaround that bug, disable transmit checksum
offloading on the netfront driver.</p>
</section>
</div>
<table class="foot">
<tr>
<td class="foot-date">June 6, 2014</td>
<td class="foot-os">FreeBSD 15.0</td>
</tr>
</table>
|
