2406.01225

# SVFF: An Automated Framework for SR-IOV Virtual Function Management in FPGA Accelerated Virtualized Environments **Authors**: Stefano Cirici, Michele Paolino, Daniel Raho > Virtual Open Systems SASGrenoble, Frances.cirici@virtualopensystems.com > Virtual Open Systems SASGrenoble, Francem.paolino@virtualopensystems.com > Virtual Open Systems SASGrenoble, Frances.raho@virtualopensystems.com Abstract FPGA accelerator devices have emerged as a powerful platform for implementing high-performance and scalable solutions in a wide range of industries, leveraging their reconfigurability and virtualization capabilities. Virtualization, in particular, offers several benefits including improved security by resource isolation and sharing, and SR-IOV is the main solution for enabling it on FPGAs. This paper introduces the SR-IOV Virtual Function Framework (SVFF), a solution that aims to simplify and enhance the management of Virtual Functions (VFs) on PCIe-attached FPGA devices in Linux and QEMU/KVM environments, solving the lack of SR-IOV re-configuration support on guests. The framework leverages the SR-IOV support in the Xilinx Queue-based Direct Memory Access (QDMA) to automate the creation, attachment, detachment, and reconfiguration of VFs to different Virtual Machines (VMs). A novel pause functionality for the VFIO device has been implemented in QEMU to enable the detachment of VFs from the host without detaching them from the guest, making reconfiguration of VFs transparent for guests that already have a VF attached to them without any performance loss. The proposed solution offers the ability to automatically and seamlessly assign a set of VFs to different VMs and adjust the configuration on the fly. Thanks to the pause functionality, it also offers the ability to attach additional VFs to new VMs without affecting devices already attached to other VMs. Index Terms: virtualization, FPGA, SR-IOV, VFIO, QEMU I Introduction In recent years, the widespread adoption of virtualization technologies has led to a growing demand for effective and efficient management of hardware resources in data centers, cloud computing, and high-performance computing environments. The management of devices in these environments can be challenging, especially when dealing with multiple VMs and frequent reconfigurations. To accelerate complex workloads, Field Programmable Gate Arrays (FPGAs) are more and more used to provide a fast-deployment, fast-prototyping solution to custom problems, with an increasing interest in Artificial Intelligence (AI) and Machine Learning (ML) domains. Virtualization of FPGA resources also enables scenarios where a single FPGA can provide multiple devices to different VM, to enhance the workload and security. Addressing some of the VMs’ guest acceleration challenges is already possible using the Single Root I/O Virtualization (SR-IOV) technology to allow multiple VMs to share the same physical device providing direct access to the hardware with minimal to no overhead. However, SR-IOV usage is not always straightforward and can lead to complex scenarios, especially when there is the need to change the VF configuration on the fly which requires the removal of every VF from each VM. This is not a problem in applications with fixed and predictable workloads or with dedicated resources for the VMs, but in environments such as cloud computing, software as a service, high-performance computing, and edge computing where workloads can vary rapidly, resources need to be shared among different VMs, and devices need to be reconfigured and reassigned, the limitations of SR-IOV become more evident. In these cases, a solution that allows automatic assignment and reconfiguration of virtual functions, can significantly simplify device management and improve system efficiency. <details> <summary>extracted/5639339/images/svff.png Details</summary>  ### Visual Description ## System Diagram: SR-IOV PCIe Device Virtualization ### Overview The image is a system diagram illustrating the virtualization of an SR-IOV PCIe device. It shows the interaction between software components (SVFF, PF driver, VF drivers, VMs, QEMU/KVM) and hardware components (SR-IOV PCIe device with PF, VFs, FPGA, and QDMA). The diagram highlights the flow of data and control between these components, emphasizing the role of virtualization technologies like libvirt, QEMU, KVM, and IOMMU. ### Components/Axes * **Title:** None explicitly given, but the diagram depicts SR-IOV PCIe device virtualization. * **Software/Hardware Layers:** The diagram is divided into software and hardware layers, separated by a dotted line. * **SVFF (blue rectangle):** Contains the following functions: init, attach, detach, reconf, pause, unpause, and QDMA manager. * **libvirt (red rectangle):** Acts as an interface between SVFF and the virtualization stack. * **VM (Virtual Machine) (green and light blue rectangles):** Represents virtual machines. * **VF driver (purple rectangle):** Resides within each VM. * **QEMU (red dashed rectangle):** A hypervisor. * **VFIO + pause (blue rectangle):** Located within QEMU. * **KVM (red dashed rectangle):** Kernel-based Virtual Machine. * **IOMMU (red dashed rectangle):** I/O Memory Management Unit. * **PF driver (purple rectangle):** Manages the Physical Function of the SR-IOV device. * **SR-IOV PCIe device (gray rectangle):** Contains the Physical Function (PF), Virtual Functions (VFs), FPGA, and QDMA. * **PF (gray rectangle):** Physical Function of the SR-IOV device. * **VF (gray rectangle):** Virtual Function of the SR-IOV device. * **FPGA:** Field Programmable Gate Array. * **QDMA:** Quad Data Movement Accelerator. ### Detailed Analysis or Content Details * **SVFF:** * Position: Top-left corner. * Functions: init, attach, detach, reconf, pause, unpause, QDMA manager. * **libvirt:** * Position: Right of SVFF, connecting to QEMU/KVM. * **VMs:** * Two VMs are shown, one green and one light blue. * Each VM has a VF driver (purple rectangle). * **QEMU/KVM:** * QEMU contains VFIO + pause (blue rectangle). * KVM is the underlying virtualization technology. * **IOMMU:** * Connects the VMs to the SR-IOV PCIe device. * **PF driver:** * Connects SVFF to the PF of the SR-IOV PCIe device. * **SR-IOV PCIe device:** * Contains PF, two VFs, FPGA, and QDMA. * The PF connects to the PF driver. * The VFs connect to the VMs via the IOMMU. * QDMA is connected to the SVFF via the QDMA manager. ### Key Observations * The diagram illustrates the flow of data and control from the SVFF through libvirt, QEMU/KVM, IOMMU, and finally to the SR-IOV PCIe device. * The PF driver manages the physical function of the device, while the VF drivers manage the virtual functions within the VMs. * The IOMMU provides memory protection and isolation for the VMs. * The QDMA is managed by the SVFF, enabling high-performance data transfer. ### Interpretation The diagram provides a high-level overview of how an SR-IOV PCIe device is virtualized. It demonstrates the interaction between various software and hardware components, highlighting the role of virtualization technologies in enabling multiple VMs to share a single physical device. The use of SR-IOV allows for near-native performance in the VMs, as the VFs provide direct access to the device's resources. The diagram emphasizes the importance of the IOMMU for security and isolation, ensuring that each VM can only access its assigned resources. The SVFF plays a central role in managing the device and its functions, providing a unified interface for controlling the virtualization process. </details> Figure 1: SR-IOV Virtual Function Framework The proposed SR-IOV Virtual Function Framework (SVFF), in blue in figure 1, leverages the support of SR-IOV in the Xilinx QDMA IP to automate the creation, attachment, detachment, and reconfiguration of accelerators to different VMs. More in detail, SVFF is a KVM-based hardware-software framework where the hardware part is entirely managed by the Xilinx QDMA and the software improves flexibility and usability with a set of scripts that automates several operations, as well as with the implementation of a novel pause functionality that minimizes guests accelerator downtime by enabling VFs reconfiguration without detaching them from the guest. This comes with (1) native performance since SVFF is able to achieve performance comparable to standard SR-IOV accelerators (benchmarks in Section V show a 2% reduction of delay times with SVFF); (2) better software programmability, thanks to the pause functionality that enables transparent changes of the VF number with virtually no downtime at the guest level and with no need of modifying the guest driver; (3) flexibility of changing the number of VF seamlessly without worrying about all the SR-IOV, drivers, and VFIO procedures needed to attach and detach them to VMs; (4) high extensibility at the hardware level, since QDMA is a standard IP that easily enables the development of accelerators. II Background This section details the key technologies beyond SVFF, starting from a brief introduction of FPGAs, and later explaining key concepts of SR-IOV, QEMU/KVM, and libvirt. II-A FPGAs Moving away from their initial purpose as prototyping devices, FPGAs are becoming progressively more attractive for industrial and consumer solutions, also thanks to silicon technology improvements. With the future being in parallel computing, AI, and ML, FPGAs saw the introduction in the HPC market to offer some significant performance advantages with respect to other solutions, especially when flexibility is one of the main targets [1, 2]. Scaling performance to parallelize the workload is however not as easy as just increasing the number of processors or computing units in a system. FPGA provides the means to realize almost any custom-hardware configuration with top-class performance and low power while maintaining the flexibility of software re-programmability. With the help of virtualization, FPGA resources can then be assigned to different and independent users (VM) to parallelize workloads in HPC scenarios. One popular approach for exposing FPGAs to virtual machines is SR-IOV, which enables VMs to directly access physical hardware devices by assigning a portion of the hardware resources to each VM. II-B SR-IOV Technology Overview The SR-IOV specification enables a PCI Express (PCIe) device to appear as multiple, distinct physical devices, each with its own set of independent I/O resources [3]. This is achieved by partitioning a Physical Function (PF) device into virtual functions (VFs), which are then allocated to each VM. As a result, each VM can have direct access to its own set of I/O resources, without interfering with other VMs. The Physical Function (the single-root function) is a full PCIe function that provides the primary functionality of the device. The Virtual Function is a lightweight PCIe function (lacking some of the configuration resources) associated with the device’s PF and shares one or more physical resources. SR-IOV-capable devices can advertise several PFs each of which can support multiple VFs. The Virtual Machine Monitor (VMM) allows assigning one or more VFs to a VM, mapping the VF configuration space into the VM. Memory translation technologies usually relying on the I/O Memory Management Unit (IOMMU) such as Intel VT-d [4] or AMD-Vi [5], provide a hardware-based solution to enable virtualization of I/O resources including DMA and interrupt remapping, allowing direct transfers between the device and the VM. II-C KVM, QEMU, libvirt, and VFIO Kernel-based Virtual Machine (KVM) is an open-source Linux subsystem that implements virtualization capabilities in a form of a VMM (or hypervisor) [6]. It provides a complete virtualization solution, including virtualized CPU, memory, devices, and I/O, delivering near-native performance thanks to the use of hardware virtualization extensions. KVM allows multiple virtual machines to run on a single physical host, using a modular design with a frontend driver for managing guests’ I/Os and a backend driver for managing and multiplexing VMs’ I/O to the real device. QEMU is an open-source emulator that provides a set of devices that can be used in the guest systems, also implementing the backend drivers for KVM. It is used in conjunction with KVM with the help of libvirt, a toolkit that provides a common API for managing VMs and their resources to simplify their integration and management. Libvirt, a library that provides high-level API for managing virtualization technologies, including QEMU, is used to simplify and abstract the interface to manage VMs, providing additional functionalities for resource access and management without sacrificing performance. The library can interact with QEMU through the QEMU Monitor Protocol (QMP) for controlling the VM, through the QEMU Guest Agent for communicating with the guest, and optionally via a remote display protocol for connecting to a VM graphical console. QMP enables control of the VM state, configuration of virtual devices eventually hotplugging them, performance monitoring, and snapshot management. For device control, it offers functionalities for adding, removing, and configuring PCI devices. QEMU also implements Virtual Function I/O (VFIO), a framework that takes the place of the device driver in the KVM host, reserving host resources and providing access to them on behalf of the guest. It provides pass-through functionalities such as direct access to the device using the IOMMU, for the highest possible I/O performance and security through isolation of devices of the same IOMMU group. VFIO is often used in cloud computing, high-performance computing, and edge computing, where it is necessary to provide VMs with direct access to hardware devices in order to have high performance and low latencies. III Related Work Academic studies on the virtualization of FPGA resources are abundant in the research community [7, 8], covering a wide range of FPGA types (including PCIe, network, and SoC) and methodologies. The paper [9] proposes a framework where a control node is used to handle requests from tenants, schedule resources, and allocate and control VMs. The pvFPGA [10] is a hardware solution that uses the Xen hypervisor and a paravirtualized environment to enable multiple domains to access the FPGA resources. This requires the backend driver on domain 0 to manage all the traffic between the VMs and the custom DMA inside the FPGA. FPGAVirt [11] is a hardware-software solution that enables the communication between guest and FPGA using virtio to create a paravirtualized framework and an FPGA overlay allowing FPGA re-configuration and re-allocation of resources (VF). In particular, the HW overlay used to give flexibility is also in charge of the isolation and sandboxing, a crucial part that is left to SR-IOV in the SVFF. vFPGAmanager [12] is a hardware-software framework for exploiting FPGA resources in a Network Function Virtualization (NFV) environment. The SVFF framework takes into account the need for modifying the VF configuration, and is generic enough to handle various types of VFs, whereas most current solutions for SR-IOV either focus solely on network virtualization [13, 14, 15, 16, 17], storage [18] or lack these capabilities. The framework proposed in this paper: (1) is an application-generic solution that requires no driver modification on the guest; (2) uses the well-tested SR-IOV implemented in the QDMA, requiring the user to just attach a digital device (FPGA implemented) to the DMA IP; (3) automatize all the FPGA, device, driver, and virtualization management operations; (4) provides the pause functionality. IV SVFF: Design and Implementation This chapter describes the design and implementation of the SVFF framework, illustrating in detail the specific components and features it implements. The framework is a virtualization solution that provides a way to manage VFs on PCIe-attached FPGA devices. It acts as an intermediary between the VMM and the device driver and provides commands for automatically initializing and reconfiguring the FPGA device. Section IV-A will focus on the hardware component, based on Xilinx QDMA, which provides SR-IOV support on a PCIe-attached FPGA, and serves as the hardware virtualization support, in gray in figure 1. Section IV-B will cover the core of the SVFF virtualization solution, the part centered around the software component, which leverages VFIO on QEMU/KVM and libvirt for automatic VF management to implement the init and reconf functionalities, in blue in figure 1. It will also address the integration with QEMU/KVM and libvirt environment, in red in figure 1. IV-A SVFF: the hardware requirement In general, the key hardware requirement considered while developing SVFF was the use of a standard solution to enable HW programmers to provide accelerators that can be easily virtualized using SR-IOV. As a result, the SVFF hardware requirements are simple: the Xilinx Queue-based Direct Memory Access (QDMA) Intellectual Property (IP) needs to be integrated into the system bitstream. More in detail, QDMA is an IP core that implements a DMA engine optimized for high bandwidth and high packet count data transfers, internally composed of the UltraScale+ Integrated Block for PCI Express and an extensive DMA and bridge infrastructure. It supports PCIe devices up to Gen3x16, up to a 2048 queue set, polling or interrupt mode, and provides the necessary SR-IOV functionality. The QDMA IP supports SR-IOV and the creation of up to 4 PFs and 252 VFs, providing a flexible configuration mechanism for the VFs through the Linux drivers. On the FPGA side, the QDMA supports the UltraScale+ devices and provides both AXI4 Memory Mapped and AXI4 Stream interfaces for connecting to other FPGA-implemented devices. IV-B SVFF: the software framework The framework automates the initialization, creation, and configuration of VFs, leveraging the Xilinx QDMA Linux kernel driver. More in particular, the SVFF is composed of several modules that have been developed to assist in the management of the QDMA host driver (the QDMA manager) and perform flash operations using Xilinx Vivado or the Xilinx Software Command-Line Tool (XSCT). Hereafter, the main components of the framework are described, starting with the novel pause functionality, followed by a description of the QEMU/KVM libvirt integration, and software automation. IV-B 1 Pause Functionality The main drawback of SR-IOV is that it requires the removal of all the VFs by setting the number of VF for a PF to zero before changing it. To overcome this limitation, the pause functionality has been developed to provide a way to temporarily detach a VFIO device connected to a VM from the host side only. In this way, the removal of the device from the guest is avoided without causing interruption of the services due to driver unloading. This solution acts only on the host system, leaving complete flexibility on the guest that can use un-modified drivers. Since the VFIO device class implemented in QEMU only provides functionalities for creating (realize) and destroying (exit) a VFIO device type, the class has been extended with the pause function. The pause functionality allows to pause or unpause the device based on its status and its pausability (it is active and tested only for Xilinx devices but should work on every PCI device, eventually with minor tweaks). <details> <summary>extracted/5639339/images/pause.png Details</summary>  ### Visual Description ## Diagram: Virtual Function (VF) Management in a Virtualized Environment ### Overview The diagram illustrates the management of Virtual Functions (VFs) in a virtualized environment, showing the interaction between Guests (Virtual Machines), the Host, and various components like libvirt, KVM/QEMU, SVFF, and VFIO. It depicts the states of VFs (detached, attached, paused) and the flow of data and control between different layers. ### Components/Axes * **Title:** None explicitly present. * **Sections:** The diagram is divided into three horizontal sections: GUESTS (top), KVM/QEMU (middle), and HOST (bottom). * **Virtual Machines (VMs):** Three VMs are shown at the top, labeled "Detached" (orange outline), "Attached" (green outline), and "Paused" (light blue outline). Each VM has a "VF driver" (purple dashed outline) inside. * **Hypervisor Components:** The middle section contains "libvirt" (red outline), "KVM/QEMU" (red dashed outline), "SVFF" (blue), "VFIO" (blue), "VFIO paused" (blue), and "vfio-pci" (purple outline). A "PCI dev detached" (blue dashed outline) is also present within the KVM/QEMU section. * **Host Components:** The bottom section shows a physical device with an "FPGA" (gray), a "PF" (Physical Function, gray), and three "VF"s (Virtual Functions, gray). * **Arrows:** Arrows indicate the direction of data flow and control between components. * **Labels:** Additional labels such as "VF can be removed" and "vfio driver can be unloaded" provide context. ### Detailed Analysis * **GUESTS Section:** * **Detached VM:** An orange-outlined "VM" with a purple dashed-outlined "VF driver" inside. * **Attached VM:** A green-outlined "VM" with a purple dashed-outlined "VF driver" inside. * **Paused VM:** A light blue-outlined "VM" with a purple dashed-outlined "VF driver" inside. * **KVM/QEMU Section:** * **libvirt:** A red-outlined box on the left, connected to the "SVFF" and "KVM/QEMU" via bidirectional arrows. * **KVM/QEMU:** A red dashed-outlined box containing a blue dashed-outlined "PCI dev detached". It is connected to "libvirt" and "SVFF" via bidirectional arrows. It also contains "VFIO" and "VFIO paused" (both blue). * **SVFF:** A blue box in the center, connected to "libvirt", "KVM/QEMU", and "vfio-pci" via bidirectional arrows. It also connects to the "PF" in the HOST section via a bidirectional arrow. * **VFIO:** A blue box connected to the "Attached VM" via a vertical arrow pointing upwards, and to "vfio-pci" via a vertical arrow pointing downwards. * **VFIO paused:** A blue box connected to the "Paused VM" via a vertical arrow pointing upwards, and to "vfio-pci" via an arrow. * **vfio-pci:** A purple-outlined box connected to "SVFF" via a bidirectional arrow, and to the "VF"s in the HOST section via vertical arrows pointing downwards. A note "vfio driver can be unloaded" is associated with this component. * **HOST Section:** * **FPGA/PF/VF:** A gray representation of a physical device with an FPGA, a "PF" (Physical Function), and three "VF"s (Virtual Functions). The "PF" is connected to "SVFF" via a bidirectional arrow. * **VF can be removed:** Text labels above the "VF"s indicate that they can be removed. ### Key Observations * The diagram illustrates the different states a VF can be in: detached, attached, or paused. * The "SVFF" component appears to be central to the management of VFs, mediating communication between the hypervisor and the physical device. * The "vfio-pci" component acts as an interface between the virtualized environment and the physical VFs. * The ability to detach, attach, pause, and remove VFs suggests dynamic resource allocation. ### Interpretation The diagram depicts a system for managing Virtual Functions (VFs) in a virtualized environment. The key takeaway is the dynamic allocation and management of VFs to virtual machines. The "SVFF" component likely handles the switching and routing of VFs between the host and the guests. The "VFIO" and "vfio-pci" components are involved in the secure and efficient passthrough of the VFs to the VMs. The ability to detach, attach, pause, and remove VFs allows for flexible resource management and optimization. The diagram highlights the complexity of virtualized environments and the various components required to enable efficient hardware virtualization. </details> Figure 2: Device detached (left), attached (center), and paused (right) The pause procedure of a VFIO device consists of 3 main steps: 1. save the PCI device config space including emulated config space and Message Signaled Interrupts (MSI) state to be restored in the unpause; 1. perform unregister operations on the PCI device, including deletion of PCI memory subregions, optional device ROM, and interrupt bits; 1. perform unregister operations on the VFIO device, including un-registration of device request and error notifier (requests from the guest to the device will be ignored), disabling and teardown of interrupts, deletion of VFIO device BARs and exiting from IOMMU group (this is needed to completely detach the device from the host). This procedure will effectively detach the device from the host, keeping it visible but in a paused state in the VM, as can be seen in figure 2. In this state, the guest will still be able to see the device and its emulated registers but can not do any actual I/O operations until the device is unpaused. The unpause procedure of a previously paused VFIO device consists of 2 main steps: 1. restore the I/O connections of the VFIO device registering again the BARs, adding the device to the IOMMU group, and registering the interrupt notifiers without affecting the emulated registers; 1. restore the PCI device config registers to the values saved before the pause, eventually updating the memory regions mappings. This procedure will re-attach the VFIO device to the guest, enabling again I/O operations. IV-B 2 Integration with QEMU and libvirt The framework integrates with QEMU and libvirt to provide a streamlined and flexible mechanism for managing VFs in a virtualized environment. In order to provide controls for the additional pause functionality, QEMU has been modified to add a new paused device’s property that provides callbacks on its modification. A new command has been registered in the QEMU Monitor Protocol (QMP) to allow sending to QEMU a device_pause command with as first argument the device id and as second the pause status. When the command is executed, if the device class provides a pause() function, the monitor will call it to execute the action provided by the device. The QEMU vfio-pci implementation (under hw/vfio/pci.c) has been modified to introduce the pause status and the callbacks to pause and unpause the device as described in section IV-B 1. When the pause functionality is enabled, the attach and detach operations will behave differently. During the detachment, if the VM is live, the framework will send the QMP pause command for the device instead of asking to detach. It will then unbind the VF from the VFIO driver. For the attachment, if the VM is live and the VF was previously paused, the framework will bind the VF to the VFIO driver using the QDMA Manager and then send the QMP unpause command. IV-B 3 Automations Software automation is crucial in server environments for HPC, cloud computing, edge computing, and other use cases that involve repetitive tasks and minimal user interactions. In order to provide a comprehensive solution for users, SVFF handles various tasks including FPGA bitstream flashing, QDMA driver interactions, and VF attachment and detachment. The SVFF provides two main functionalities for the user: the init function used to initialize the FPGA device the first time is connected to the host, eventually flashing the bitstream, and the reconf function used to change the number of VFs to be created and attached to the VMs. The init process involves a recursive search for all the VFs associated with the PFs of the device, detaching them from the VM, and removing the PF from the PCI bus unloading its driver. Afterward, the bitstream can be flashed to the FPGA (automation of the bitstream flash procedure is achieved using TCL scripts for Xilinx Vivado or XSCT), the PF is discovered and configured, and the number of queues and VFs to be used is set. The new VFs are then attached to the VMs, making them available for the guests, and will use the vfio-pci as the backend driver on the host and the qdma-vf driver on the VM, leaving to QEMU the management of the passthrough operations. On the host system, the qdma-pf driver provides a sysfs interface to configure and control various parameters of the PF exposed by the QDMA IP. After the initial number of VFs is set using the init option, there may be a need to change the configuration using the reconf command. This could involve removing a VF from a VM, adding more VFs to a new or existing VM, or reflashing the FPGA bitstream to change the HW configuration. The reconfiguration option is used to change the number of VFs for a given PF and automatically manage the detach, reattach, and pause of a VF from its related VM. Attaching and detaching Virtual Function devices to VMs is automated in the program and facilitated through the use of virsh, which serves as the primary interface for managing guest domains with libvirt. In the attach process, each VF device is specified in an XML file that outlines its properties, such as device type, address, and driver. This file is saved to maintain a record of the VF-VM association for future reference, allowing for a seamless detach operation. Taking into account whether the domain is live (running) or not, virsh is then used to handle the actual attachment of the VF to the VM. For the detachment process, the properties of the VF and the VM it is attached to are retrieved from the corresponding XML file, and virsh is utilized to detach the device from the VM. Finally, interactions with the QDMA driver are mediated with the QDMA manager, a program developed to simplify the management of the drivers offering various functionalities, such as unbinding a PCI device from its driver, binding the VFIO driver to it, removing the device and its related VFs from the PCI bus, and rescanning the PCI bus to detect new devices (which is useful when initializing the FPGA after it has been attached to the host). It also includes security checks for the device ID and driver name, a recursive search for related VFs, and management of new device IDs for VFIO. V Evaluation and Results In this section, the evaluation methodology and the results of the experiments conducted on the proposed framework are presented. Since the SVFF leverages the same underlying SR-IOV technology provided by the QDMA introducing significant changes only at a software level, I/O performance measurements are left out as they would reflect the Xilinx QDMA reference values [19]. Consequently, the purpose of the evaluation is to assess the performance and overhead of the SVFF novel pause functionality. In this context, there are two scenarios: the standard SR-IOV detach-attach method on one side, and the newly introduced SVFF pause-unpause. The time needed to complete an SR-IOV re-configuration cycle is measured in both cases, aiming at assessing the overhead introduced by SVFF. More in detail, the measured re-configuration cycle assumes that a number of VFs is already attached to the same number of VMs (one VF per VM) and measures the time it takes to remove/pause all the VFs and attach/unpause them again to the corresponding VMs. Delays are measured from the host side since guests are unaware of when a VF is paused/unpaused using the default QDMA guest driver. V-A FPGA Design and Bitstream As mentioned above, nothing more than the QDMA IP is needed to enable the framework, leaving extreme flexibility to the user to implement custom blocks in the FPGA for any kind of application. For this paper’s benchmarks, the Xilinx Vivado 2022.1 toolset was used to generate the bitstream for a Xilinx Alveo U55C target. The FPGA design is a Vivado block design with the QDMA IP v4.0 connected to two BRAM controllers, one via the AXI and one via the AXI Lite interface, each with its corresponding memory. Additionally, a custom Function Level Reset (FLR) block implemented in VHDL has been included to assert FLR requests without actually performing any reset action. This is required by the QDMA which would otherwise wait indefinitely for the FLR response to arrive. The QDMA IP is configured with an 8 GT/s x16 PCIe link with a 512-bit AXI data interface and 512 queues. SR-IOV is also enabled providing 1 PF classified as a memory controller with 32 VF. From the host’s perspective, the PCIe PF and each VF that inherits its properties expose two memories: a fast 512KB used to mimic memory accesses and a slow 32KB for device-like operations. V-B Software Configuration The host system is a 32 cores, 128GB RAM x86_64 server running Red Hat Enterprise Linux (RHEL) 8.7 with Linux kernel 4.18 and hosting the Alveo FPGA card, managed with the Xilinx Runtime library (XRT) 2.13.466 branch 2022.1. Qemu 7.1.0 has been modified to add the pause functionality, compiled with GCC 8.5.0 and the --x86_64-softmmu and --enable-kvm parameters, and installed in the /usr/local prefix. SELinux is used in enforcing mode on the host, requiring the installation of QEMU binaries to the qemu_exec_t context. Libvirt 8.0.0 is used and the kernel is started with the intel_iommu=on command line option to enable the IOMMU. Each guest VM is a 2 cores, 2GB RAM x86_64 Ubuntu 22.04 with Linux kernel 5.15 based on a Q35+ICH9 machine. The QDMA drivers are compiled from the source and installed in both the host and the guest systems, which will use only the PF and the VF parts respectively. V-C Results TABLE I: VF detach-attach vs pause-unpause overhead, AVG of 100 runs | 1 | 4151 | 40 | 4068 | 56 | -2.00 | -83 | | --- | --- | --- | --- | --- | --- | --- | | 4 | 12988 | 183 | 12665 | 171 | -2.49 | -80 | | 10 | 31129 | 497 | 30285 | 505 | -2.71 | -84 | Table I shows the average delays on 100 runs for both configurations when operating on 1, 4, and 10 VF on as many VMs. The overhead values show that there is a minimal reduction in the delays from 2% to 2.71% with a reducing time of around 80ms per VF in all the scenarios. The delays are not linearly increasing with the number of VF, meaning that some operations are not dependent on it. To understand better the results, the duration of the different macro-operations performed in the two cases for a single run with 1, 4, and 10 VFs are inspected, showing the values in table II. It’s important to note that these timings represent one particular run, and the average values may differ across multiple runs or in different environments. The rescan operation of the PCI bus is performed to be sure to have discovered all the PF and VF on the bus, and its time is the same in both the Detach/Attach (D/A) and Pause/Unpause (P/U), not dependent on the number of VF involved. The removal (detach or pause) of the VF in step 2 takes on average the same time in both scenarios, although the pause skips some device removal operations performed by detach but spends some more time allocating and saving the device configuration data structures. Step 3 shows the delay for changing the number of VFs of a PF and it is quite similar in both cases, slightly increasing with the number of VF involved. In step 4, it is noticeable the main gain of the unpause operation with respect to the attach. This is justified by the fact that the former skips some of the realize operations of the device (because it does not detach it from the guest side), copying back the device configuration data instead. TABLE II: Timings of VF detach-attach and pause-unpause operations | 1. rescan 2. remove VF 3. change #VF | 138 1265 1256 | 138 1273 1295 | 144 5417 1460 | 141 5505 1412 | 139 14360 1817 | 139 13878 1730 | | --- | --- | --- | --- | --- | --- | --- | | 4. add VF | 1472 | 1346 | 5946 | 5653 | 15042 | 14448 | | total | 4131 | 4052 | 12967 | 12711 | 31358 | 30195 | It is also to mention that the timings reported are real timings (the actual time elapsed from the start to the end of the operation) and are mostly dependent on the SR-IOV operations performed on the hardware: for a 4 s reconfiguration of 1 VF, CPU time (user + kernel) is only around 350 ms, less than 9% (this stands also for the 4 VFs and 10 VFs cases tested). This benchmark analysis demonstrated that the pause functionality can be used as a suitable alternative to device removal, as it incurs no significant overhead and can even provide a slight performance improvement of a few percentage points, with the main advantage of avoiding device removals on the guest side. VI Conclusion and future work This paper presented the SR-IOV Virtual Function Framework (SVFF), a virtualization solution that provides a way to manage Virtual Functions on PCIe-attached FPGAs devices. The framework simplifies the management of VF by automating the assignment of VFs to different VMs also allowing re-configuration on the fly. The pause functionality allows for seamless VF reconfiguration from the VM side, where the guest does not see the device removed but is only unavailable for the process duration. Moreover, this approach slightly reduces the delay time by over 2%. Overall, the SVFF solution provides an efficient and effective method for managing FPGA resources in virtualized environments, particularly in data centers, cloud computing, and HPC environments, where device management can be a challenging task. Future work will focus on optimizing the performance of SVFF and implementing higher-level features. One area for improvement is the pause functionality, which could be optimized to enable faster recovery times and minimal interruption to FPGA-based workloads, also keeping track of the guest driver requests that are currently ignored when the device is paused. Another potential area for future work is the implementation of dynamic resource allocation for FPGAs based on workload demands to improve the efficiency of FPGA utilization and enable users to allocate and deallocate FPGA resources in real-time, enhancing the overall performance of cloud-based applications. Acknowledgment This work has received funding from the EU Horizon 2020 Programme, grant agreement No 957269 (EVEREST) [20]. References - [1] J. Shalf, “The future of computing beyond Moore’s law,” Philosophical Transactions of the Royal Society A, vol. 378, no. 20190061, 2020. - [2] W. Vanderbauwhede and K. Benkrid, High-performance computing using FPGAs. Springer, 2013, vol. 3. - [3] P. Kutch, “PCI-SIG SR-IOV Primer: An introduction to SR-IOV technology,” Intel Corporation, Tech. Rep. 321211-002, Rev 2.5, jan 2011. - [4] Intel Virtualization Technology for Directed I/O Architecture Specification, Intel Std. D51 397-015, Rev. 4.0, jun 2022. - [5] AMD I/O Virtualization Technology (IOMMU) Specification, Advanced Micro Devices Inc. Std. 48 882, Rev. 3.0, dec 2016. - [6] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, “kvm: the Linux virtual machine monitor,” in Proceedings of the Linux symposium, vol. 1, no. 8, 2007, pp. 225–230. - [7] C. Bobda, J. M. Mbongue, P. Chow, M. Ewais, N. Tarafdar, J. C. Vega, K. Eguro, D. Koch, S. Handagala, M. Leeser et al., “The future of FPGA acceleration in datacenters and the cloud,” ACM Transactions on Reconfigurable Technology and Systems (TRETS), vol. 15, no. 3, pp. 1–42, 2022. - [8] J. Guo, L. Zhang, J. Romero Hung, C. Li, J. Zhao, and M. Guo, “Fpga sharing in the cloud: a comprehensive analysis,” Frontiers of Computer Science, vol. 17, no. 5, p. 175106, 2023. - [9] F. Chen, Y. Shan, Y. Zhang, Y. Wang, H. Franke, X. Chang, and K. Wang, “Enabling FPGAs in the cloud,” in Proceedings of the 11th ACM Conference on Computing Frontiers, 2014, pp. 1–10. - [10] W. Wang, M. Bolic, and J. Parri, “pvFPGA: Accessing an FPGA-based hardware accelerator in a paravirtualized environment,” in 2013 International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS), 2013, pp. 1–9. - [11] J. Mbongue, F. Hategekimana, D. T. Kwadjo, D. Andrews, and C. Bobda, “FPGAVirt: A novel virtualization framework for FPGAs in the cloud,” in 2018 IEEE 11th International Conference on Cloud Computing (CLOUD), 2018, pp. 862–865. - [12] S. Chiotakis, S. Pinneterre, and M. Paolino, “vFPGAmanager: A hardware-software framework for optimal FPGA resources exploitation in network function virtualization,” in 2019 European Conference on Networks and Communications (EuCNC), 2019, pp. 47–51. - [13] Z. Ye, Y. Zhong, and Y. Wei, “A virtual network resource allocation framework based on SR-IOV,” Applied Sciences, vol. 9, no. 1, p. 137, 2019. - [14] J. F. Zazo, S. Lopez-Buedo, Y. Audzevich, and A. W. Moore, “A PCIe DMA engine to support the virtualization of 40 Gbps FPGA-accelerated network appliances,” in 2015 International Conference on ReConFigurable Computing and FPGAs (ReConFig), 2015, pp. 1–6. - [15] Y. Dong, X. Yang, J. Li, G. Liao, K. Tian, and H. Guan, “High performance network virtualization with sr-iov,” Journal of Parallel and Distributed Computing, vol. 72, no. 11, pp. 1471–1480, 2012. - [16] L. Zeng, Y. Wang, X. Fan, and C. Xu, “Raccoon: A novel network i/o allocation framework for workload-aware vm scheduling in virtual environments,” IEEE Transactions on Parallel and Distributed Systems, vol. 28, no. 9, pp. 2651–2662, 2017. - [17] X. Xu and B. Davda, “Srvm: Hypervisor support for live migration with passthrough sr-iov network devices,” ACM SIGPLAN Notices, vol. 51, no. 7, pp. 65–77, 2016. - [18] D. Kwon, J. Boo, D. Kim, and J. Kim, “FVM: FPGA-assisted virtual device emulation for fast, scalable, and flexible storage virtualization,” in Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation, 2020, pp. 955–971. - [19] A. M. D. Inc. (2021) Xilinx answer 71453 QDMA performance report. - [20] C. Pilato, S. Bohm, F. Brocheton, J. Castrillon, R. Cevasco, V. Cima, R. Cmar, D. Diamantopoulos, F. Ferrandi, J. Martinovic et al., “EVEREST: A design environment for extreme-scale big data analytics on heterogeneous platforms,” in 2021 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2021, pp. 1320–1325.