VirtIO

Introduction to VirtIO | Oracle (2022)

https://blogs.oracle.com/linux/post/introduction-to-virtio

• VirtIO: Virtual Input and Output

  Virtio is an open standard that defines a protocol for communication between drivers and devices of different types… of the virtio spec. Originally developed as a standard for paravirtualized devices implemented by a hypervisor, it can be used to interface any compliant device (real or emulated) with a driver. https://docs.kernel.org/driver-api/virtio/virtio.html

• Abstraction layer over host’s devices for VMs

  • Allows VM to use host’s devices via minimal virtual devices (VirtIO devices)
  • VirtIO devices only have bare necessities to send/receive data, lets the host handle majority of work on actual physical hardware devices

For the VM to access the host’s NIC, and therefore access the internet, a VirtIO device called virtio-net can be created. In a nutshell, it’s main purpose is to send and receive network data to and from the host.

• Offloading to host improves speed and efficiency versus emulating a device
• VirtIO core framework is standardized to an official specification
• Virtualization, not emulation, so guests are limited to what the host’s hardware supports
  • Emulation is useful when using a device/software not supported by the host’s hardware (e.g. running MacOS on Windows PC)

VirtIO Architecture

• 3 parts to VirtIO architecture:

  • Front-end drivers (in the guest kernel)
    • A kernel module in the guest OS
    • Accepts user process I/O requests → transfers them to the back-end device → retrieves completed request from device
  • Back-end devices (in the hypervisor)
    • Accepts driver I/O request → offloads I/O operations to host’s hardware → makes processed data available to driver (via shared VirtQueue)
  • VirtQueues and VRings (comms between in data plane)

  

  Typical setup (no VHost, SR-IOV, etc.) Notifications are from VirtIO drivers and devices → routed to KVM interruptions

VirtQueues and VRings

• VirtQueues are a data structure that assist devices/drivers in performing VRing operations

  • Shared in guest physical memory
    • Each driver-device pair accesses the same page in RAM, it is a single region, so no sync required

  …VRings are the main feature of VirtQueues, as VRings are the actual data structures that facilitate the transfer of data between a VirtIO device and driver.

  

  QEMU’s VirtQueue and VRing data structures

  …a VirtQueue’s organization is specific to the guest’s OS and whether we’re talking about userspace (e.g. Qemu) or kernel VirtIO framework. Also, the operations of VirtQueues are specific to the VirtIO configuration…

  

  Linux kernel’s VirtQueue and VRing data structures

  The takeaway here is to know that VirtQueues and VRings are two different data structures and that a VirtQueue’s organization will vary depending on the operating system and whether we’re talking about userland or kernel VirtIO framework.

• VRing is the main feature of VirtQueues; holds the actual data being transferred

  • Referred to as ring because it a wrap-around array
  • Now being referred to as “areas”, but still VRing in QEMU source
  • 3 types of VRing [article describes each in detail, didn’t read it]:
    • Descriptor ring
    • Available ring
    • Used ring

VHost

Unlike VirtIO drivers & devices, whose data plane exists in the Qemu process, VHost can offload the data plane to either another host user process (VHost-User) or to the host’s kernel (VHost, as a kernel module). The motivation behind doing this is performance.

• In pure VirtIO solution (Figure 2), every driver→host request is a context switch (expensive)

  • Offloading data plane to host lets us bypass QEMU process, reducing latency

  

  VHost example with VHost-SCSI

  • Differences to Figure 2:
    • Transport layer (data plane) moved from guest kernel to host kernel
    • A VirtIO device model still exists, but capabilities reduced to control plane task handling
    • New VHost-SCSI kernel module in host kernel