Boost VM I/O Performance with SR‑IOV: Hardware‑Based PCIe Virtualization Explained

To improve the performance and scalability of virtual machine packet transmission in servers and solve the last‑mile problem of I/O virtualization, a hardware‑based SR‑IOV virtualization solution is proposed. The SR‑IOV standard allows efficient sharing of PCIe (Peripheral Component Interconnect Express) devices among VMs, delivering I/O performance close to native because it is implemented in hardware.

SR‑IOV (Single‑Root I/O Virtualization) is a standard introduced by PCI‑SIG that defines a mechanism for PCIe device virtualization. It implements a “virtual channel” technology, turning one physical PCIe device into multiple virtual PCIe devices, each with its own PCIe configuration space and providing services to upper‑level software just like a physical device.

SR‑IOV is a hardware‑based virtualization solution that can boost the performance and scalability of physical I/O devices, commonly network adapters. Because it is implemented in hardware, virtual machines can achieve I/O performance comparable to the host.

SR‑IOV virtual channels are divided into two types:

PF (Physical Function) : Manages the physical‑layer channel functions of the PCIe device, acting as a complete PCIe device that includes the SR‑IOV functionality and can configure and manage VFs.

VF (Virtual Function) : Represents the virtual‑layer channel of the PCIe device, containing only I/O functionality. VFs share physical resources, are trimmed versions of a PCIe device, and can be configured only with their own resources; VMs cannot use a VF to manage the SR‑IOV NIC. All VFs are derived from a PF, and some NIC models can generate up to 256 VFs.

In short, each VF is like a slice of the physical NIC’s hardware resources, while the PF coordinates all physical resources and manages the many VFs to work together.

SR‑IOV implementation relies on both hardware and software. It requires a dedicated NIC chip and BIOS version, and the hypervisor must install appropriate drivers. Only through the PF can the physical NIC’s I/O resources be managed and VFs generated, and the hypervisor must distinguish PF and VF to configure the NIC correctly.

When the hypervisor detects a VF, it uses the PF to manage and configure the VF’s I/O resources. From the hypervisor’s perspective, a VF behaves like a regular PCIe NIC; after installing the driver, it can be used directly. For example, a server with a single‑port SR‑IOV NIC that creates four VFs will present four Ethernet connections to the hypervisor.

Building on SR‑IOV, technologies such as Intel VT‑d or AMD IOMMU can map a VF directly to a VM (PCI‑Passthrough), bypassing the hypervisor’s software switch and achieving low latency and near‑line‑rate performance. Compared with VMware’s DirectPath, this approach provides direct VF hardware access without needing additional physical NICs as VM count grows.

By default, VFs on an SR‑IOV NIC are disabled, and the PF functions as a traditional PCIe device. Enabling a VF causes the PF to create the VF via registers and access each VF’s PCIe configuration space using bus, device, and function numbers (routing IDs). Each VF has its own PCIe memory space for register mapping; the VF driver operates on these registers to enable functionality, appearing as an actual PCIe device.