vdev virtio-net

Provide the standard VIRTIO interface for network devices

Synopsis:

vdev virtio-net options

Options:

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. Standard negotiation isn't possible, so feature bits must be used, as explained in Configuring the features of a peer connection below.

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.

Configuring access permissions

The access permissions for the node used for a peer-to-peer connection are controlled using a security policy. For more information, refer to the Security Policies chapter of the System Security Guide. There's no virtio-net configuration option for setting access permissions, unlike in previous releases.

Configuring the features of a peer connection

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 OS 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 OS 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-sock 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 setting up peer connections, see Networking in the Using Virtual Devices, Networking, and Memory Sharing chapter.

Page updated: