vdev virtio-net

Synopsis:

vdev virtio-net options

Options:

bind-mode num: Set the access permissions to num for the node used for the peer-to-peer connection. The default setting is 0600.
intr intr: Signal intr for device interrupts. Not required when the vdev appears as a PCI device.
legacy: Provide the VIRTIO legacy interface (0.9.5) rather than the 1.0 or later standard versions.
loc addr: Set the base address of the device registers to addr. If this option isn't specified, the vdev appears as a PCI device.
mac mac_address: Use the mac_address as the Ethernet address for the vdev in the guest.
name name: Set this side of a peer-to-peer networking connection to name.
peer path: Directly connect to the peer device path (usually of the form /dev/qvm/vm/vnet). In this case, specifying mac and name is highly recommended.; For the name, use the name (system_name) of the system with the peered device (see system in the “VM Configuration Reference” chapter).
peerfeats mask: Specify VIRTIO Network feature bits that should be assumed to be supported by the peer, since it is impossible to do proper negotiation (see below).
tapdev host_device_name: Deprecated.

For a list of options available to all vdevs, see “Common vdev options” at the beginning of this chapter.

Description:

The virtio-net vdev provides an interface for network devices. Normally this device appears as a PCI device, but if you specify the loc and intr options, the guest will see it as a memory-mapped I/O device at the specified location.

For virtio-net, packed virtqueues are enabled if the guest supports them.

Using the peerfeats option

Feature bits are used to specify the features exposed to a peer in a network. They can be defined for each individual virtio-net interface (i.e., each peer connection can have its own feature set).

The peerfeats option defines the maximum set of features that will be negotiated between the two TCP stacks connected as peers. The available feature bits are specified in Virtual I/O Device (VIRTIO) Version 1.1, Section 5.1.3 (see the document repository at oasis-open.org). This maximum set of bits is currently set at 0x7fc3. The current QNX Neutrino TCP stack supports a subset of the maximum set. This subset is 0x19c3, or:

0001 1001 1100 0011

with the least-significant bit (bit zero) on the right.

Of particular interest are the bits that support checksumming and Transmit Segmentation Offload (TSO); both these features are supported in the QNX TCP stack (see the table below).

The default peerfeats value for a peer interface is 0x0000.

You should limit the feature bits to the features supported by the guests. For example, if you are configuring two QNX Neutrino guests to connect as peers, you should specify 0x19c3 as the value for the peerfeats option's mask in the VM configuration for each guest.

When using the peerfeats option:

If you know the features supported by both the near-end and the far-end peer interfaces, specify them with the peerfeats option in the VM configurations for each guest.
If you don't know the features supported by both peers, you can set the peerfeats mask to 0x7fc3 and let the connected TCP stacks negotiate the features they will use (check your OS documentation for details).
If you are configuring a peer connection to a QNX io-pkt-* bridge, you must set the peerfeats option to 0x0 (zero) to disable all features on both peer nodes.
If one of the peers is in the hypervisor host, configure its interface to disable checksums for TCP and UDP, as follows:
```
ifconfig vp0 -tcp4csum -udp4csum -udp6csum -tcp6csum
```
This is required so that the host bridge does not incorrectly discard or delay packets. Note, however, that you disable checksums only for receiving IP (-rx), so you can still send packets with checksums. If the peer node is properly configured, it should have checksums disabled and be able to receive your packets.

Note: If you enable TSO in the interface, you must also use ifconfig after the interface starts running to turn the TSO support on. For example, the ifconfig startup in your guest might look something like this:

ifconfig vt1 tcp4csum udp4csum tcp6csum udp6csum tso4 tso6

Guest-to-guest and guest-to-host

The table below lists the recommended feature set for guest-to-guest and guest-to host connections:

Bit	Name	Feature
0	VIRTIO_NET_F_CSUM	Device handles packets with partial (or no) checksum.
1	VIRTIO_NET_F_GUEST_CSUM	Driver handles packets with partial (or no) checksum.

Guest-to-guest only

The table below lists the recommended feature set for guest-to-guest connections only:

Bit	Name	Feature
7	VIRTIO_NET_F_GUEST_TSO4	Driver can receive TSOv4.
8	VIRTIO_NET_F_GUEST_TSO6	Driver can receive TSOv6.
11	VIRTIO_NET_F_HOST_TSO4	Device can receive TSOv4.
12	VIRTIO_NET_F_HOST_TSO6	Device can receive TSOv6.

For more information about using the virtio-net vdev, see “Networking” in the “Using a QNX Hypervisor for Safety System” chapter.