Heterogeneous I / O device discovery and handshaking

Abstract

The VF driver receives an indication of a BAR exposed by an I / O device, the I / O device providing virtual hardware resources for use by the VF driver. The VF driver performs internal probing and / or analysis to determine a target adaptation for at least one of the BARs exposed by the I / O device. The PF driver receives a request message from the VF driver to adapt at least one of the BARs exposed by the I / O device. The BAR exposed by the I / O device is adapted by the PF driver based on the request message. A confirmation message is provided to the VF driver indicating the adaptation of the BAR exposed by the I / O device. The VF driver accesses a memory area allocated to the adapted BAR exposed by the I / O device.

Description

Background Art

[0001] In some embodiments, the present invention relates to virtual machines (VMs), and more particularly, but not exclusively, to communication between VMs and virtualized resources of physical hardware devices.

[0002] Hardware resources, especially I / O devices such as storage devices, accelerator hardware, and network interfaces, can be virtualized. Virtualization of hardware resources allows multiple VMs to share the same hardware resources. Summary of the invention

[0003] The object of the present invention is to provide a computing device, method and computer-readable storage medium for virtualizing hardware resources of an input / output (I / O) device.

[0004] The above and other objects are achieved by the features of the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0005] According to a first aspect, a computing device communicates with a device input / output (I / O) device that provides virtual hardware resources for use by multiple virtual function (VF) drivers of multiple virtual machines (VMs), wherein the computing device executes a virtual machine manager (VMM) that implements a physical function (PF) driver and multiple base address registers (BARs) exposed by the I / O device, the PF driver corresponding to the multiple VF drivers implemented by the multiple VMs, the PF driver being used to: receive a request message from a VF driver among the multiple VF drivers, wherein the request message includes a request to adapt at least one of the BARs exposed by the I / O device; adapt at least one of the BARs exposed by the I / O device according to the request message; and provide a confirmation message to the VF driver indicating the adaptation of at least one of the BARs exposed by the I / O device.

[0006] According to a second aspect, a VF driver is executed on a VM, the VF driver corresponding to a PF driver and an input / output (I / O) device that provides virtualized hardware resources, the VF driver being used to: receive an indication of a plurality of BARs exposed by the I / O device; perform internal detection and / or analysis to determine a target adaptation for at least one of the BARs exposed by the I / O device; send a request message to the PF driver, wherein the request message includes a request to perform the target adaptation for at least one of the BARs exposed by the I / O device; receive a confirmation message from the PF driver indicating the target adaptation for at least one of the BARs exposed by the I / O device; and access a memory area allocated to the plurality of BARs exposed by the I / O device and adapted according to the adaptation.

[0007] According to a third aspect, a method includes: a PF driver receiving a request message from a VF driver among the multiple VF drivers, wherein the request message includes a request to adapt at least one of the BARs exposed by the I / O device; the PF driver adapts at least one of the BARs exposed by the I / O device according to the request message; and the VF driver provides a confirmation message indicating the adaptation of at least one of the BARs exposed by the I / O device.

[0008] According to a fourth aspect, a method includes: a VF driver receives an indication of multiple BARs exposed by an I / O device; performs internal detection and analysis to determine a target adaptation for at least one of the BARs exposed by the I / O device; the VF driver sends a request message to the PF driver, wherein the request message includes a request to perform the target adaptation of at least one of the BARs exposed by the I / O device; receives a confirmation message from the PF driver indicating that the target adaptation of at least one of the BARs exposed by the I / O device has been achieved; and accesses a memory area allocated to the multiple BARs exposed by the I / O device and adapts according to the adaptation.

[0009] At least some of the computing devices, methods and / or code instructions described herein solve the technical problem of allocating virtualized resources of I / O devices to VMs. At least some of the computing devices, methods and / or code instructions described herein improve the standard method of allocating virtualized resources of I / O devices to VMs. Using the standard method, each VF driver of each VM is informed of the BAR exposed by the I / O device. The exposed BAR of the VF driver is fixed. In fact, the VF driver is "locked" to a specific I / O device setting. Changes to the exposed BAR are performed on the side of the I / O device itself and require a new installation of a new version of the VF driver that is compatible with the I / O device changes. This problem is particularly evident in data centers such as cloud services, where a large number of VMs (e.g., thousands) are executed. In addition, the code executed on the VM can be imported by external customers using cloud services. Therefore, the fixed I / O device BAR setting may not be suitable for the different requirements of many different VF drivers of the VF.

[0010] In contrast, at least some embodiments described herein solve the above technical problems and / or provide the above improvements by enabling the VF driver to request adaptation of the BAR exposed by the I / O device. For example, in order to improve the performance of applications and / or features running on the VM, and / or enable applications and / or features to run on the VM (wherein, when the adaptation of the BAR is not performed, the applications and / or features cannot run on the VM machine). For example, specific applications and / or functions that cannot run effectively using the standard 16KB memory space, for example, when the memory space is used for MSI-X interrupts, if many queues use the same vector, when the VF uses more queues and wants each queue to have its own interrupt vector, more delays may be generated. The VF driver may request to increase the memory space to 2MB, which may increase the number of MSI-X vectors. In another example, the VM provides remote direct memory access (RDMA) service. The VF driver may request additional BARs and / or larger BARs in order to have enough memory to isolate different areas of memory.

[0011] At least some embodiments described herein enable the BAR exposed by the I / O to be adapted according to the requirements of each VF driver running on the corresponding VM. Since different VMs may run different VF drivers, such as different versions of the VF driver with different characteristics and / or functions, the configuration of the BAR exposed by the I / O device may not be efficient or even suitable for all VF drivers. Using standard methods, the VF driver needs to be upgraded, which is unrealistic and / or requires great efforts in a cloud-based environment running thousands of VMs. At least some embodiments described herein enable each VF driver to adapt the BAR exposed by the I / O device according to its own requirements, so that different versions of the same VF driver and / or different VF drivers can be connected to the same I / O device through an interface. In addition, different versions of the same I / O device can be released without re-upgrading the VF driver. The new I / O hardware can adapt to the expected functions of the old VF driver I / O device BAR by displaying its expected BAR space to the VF driver during negotiation. The VF driver may adapt its functionality to multiple I / O devices, which may have different I / O device BAR space configurations.

[0012] In another implementation of the first, second, third and fourth aspects, the request to adapt at least one of the BARs exposed by the I / O device includes at least an operation selected from the following group: increasing the memory size corresponding to a specific BAR, increasing the number of specific BARs, and adapting the structure of a specific BAR.

[0013] The VF driver may request to change the structure of the BAR, ie, change the memory size corresponding to one or more BARs, and / or change (eg, increase) the number of BARs.

[0014] In another implementation of the first, second, third and fourth aspects, the PF device is further used to: in response to receiving the request message from the VF driver, transmit data to the VM that triggers the unloading of the VF driver; in response to the VF driver unloading, adapt at least one of the BARs exposed by the I / O device according to the request message; in response to completing the adaptation of at least one of the BARs exposed by the I / O device, send an instruction to the VM to perform a hot swap by reloading the VF driver without restarting the VM, wherein, after completing the re-enumeration and / or rescanning (hot swap) performed by the VM, the loaded VF driver identifies the adapted at least one BAR exposed by the I / O device.

[0015] The VF driver can be "hot-swapped" and / or act as a "hot-swap" by unloading and reloading again what the VF driver appears as a new I / O device, which is actually an existing I / O device adapted according to the request of the VF driver. The hot-swapped VF exposes the adaptation BAR of the VF driver.

[0016] In another implementation of the first, second, third and fourth aspects, the request to adapt at least one of the BARs exposed by the I / O device includes at least one operation selected from the following group: adapting an existing role of a specific BAR to a new role and adapting the structure of the specific BAR.

[0017] The VF driver may request to change the role of an existing BAR.

[0018] In another implementation of the first, second, third and fourth aspects, the VF driver uses the specific BAR to assume the new role during its operation without going through an unload and reload cycle.

[0019] Said VF driver does not need to be unloaded and reloaded to effectively change roles, but can continue to run.

[0020] In another implementation of the first, second, third and fourth aspects, the request to adapt at least one of the BARs exposed by the I / O device includes a first request, in response to which the VF driver is instructed to unload and reload as a reloaded VF driver, the first request including at least an operation selected from the following group consisting of: increasing a memory size corresponding to a specific BAR, and increasing the number of specific BARs; the VF driver provides a second request, the second request including a request to adapt at least one of the BARs exposed by the I / O device, including at least one operation selected from the following group consisting of: adapting an existing role of a specific BAR to a new role, in response, the reloaded VF driver uses the specific BAR to assume the new role during its operation without undergoing an unload and reload cycle.

[0021] In another implementation of the first, second, third and fourth aspects, the PF device is further used to: provide the VF driver with an indication of an initial configuration of the BAR exposed by the I / O device, the initial configuration representing a minimum configuration supporting a set of basic capabilities negotiated between the VF driver and the PF driver, wherein the adaptation request includes a request to extend the minimum configuration to support a set of advanced capabilities negotiated between the VF driver and the PF driver.

[0022] The scalable initial configuration improves the utilization and / or computing efficiency generated by the configuration of the BAR. The initial configuration may represent the minimum requirements for running basic functions, providing the maximum initial utilization and / or computing efficiency by allocating minimum resources. The initial configuration may include a minimum number of BARs and / or a minimum memory usage BAR, such as enabling a basic capability set. The initial configuration may be expanded as needed based on the request of the VF driver, for example, by increasing the number of BARs and / or increasing the memory size corresponding to the BAR. Different VF drivers may expand the initial configuration based on their respective requirements.

[0023] At least some embodiments provide enhanced capabilities for discovery and negotiation of capabilities between the VF driver and I / O devices, whereas in standard approaches, negotiation of capabilities is limited to fixed BARs exposed by the I / O devices.

[0024] In another implementation of the first, second, third and fourth aspects, the PF device is further used to: negotiate with the VF driver an adaptation set of at least one of the BARs exposed by the I / O device for implementation, wherein the adaptation includes adapting the at least one BAR according to the negotiated adaptation set.

[0025] The VF driver and the PF driver may negotiate which adaptation to implement, thereby providing the VF driver and the PF driver with flexibility in selecting and implementing the BAR adaptation.

[0026] In another implementation of the first, second, third and fourth aspects, the negotiation includes: analyzing the request message to determine which of the requested adaptations of at least one of the BARs exposed by the I / O device are achievable; providing a negotiation message to the VF driver, indicating which of the adaptations of at least one of the BARs exposed by the I / O device are achievable; receiving a response to the negotiation message from the VF driver, indicating that the VF driver selects which of the achievable adaptations of at least one of the BARs exposed by the achievable I / O device to implement, wherein the adaptation includes adapting at least one of the BARs exposed by the I / O device according to the response to the negotiation message.

[0027] In another implementation of the first, second, third and fourth aspects, the PF driver is further used to adapt at least one BAR of the I / O device through a hardware mailbox process according to the request.

[0028] A mailbox may be part of an interoperation that uses an initial configuration of a BAR designed to provide common functionality for basic functionality.

[0029] In another implementation of the first, second, third and fourth aspects, the I / O device implements a protocol for virtualizing its hardware resources according to the Peripheral Component Interconnect Express (PCIe) standard.

[0030] In another implementation of the first, second, third and fourth aspects, PCIe implements single-root input / output virtualization (SR-IOV).

[0031] In another implementation of the first, second, third and fourth aspects, multiple instances of an adaptive VF (AVF) and / or an assignable device interface (ADI) are implemented as the multiple VF drivers, the multiple instances of the AVF are mapped to a PF driver implemented as a single common PF driver, wherein the at least one BAR exposed by the I / O device is used by multiple VMs that implement the multiple instances of the AVF and / or ADI.

[0032] In another implementation of the second aspect and the fourth aspect, the internal detection and analysis for determining the target adaptation of at least one of the BARs exposed by the I / O device is performed during startup of the VF driver and during a negotiation phase in which the VF driver negotiates basic and / or advanced capabilities with the PF driver.

[0033] In another implementation of the second aspect and the fourth aspect, the internal detection and analysis for determining the target adaptation of at least one of the BARs exposed by the I / O device is dynamically performed during operation of features and / or applications and / or loading of the features and / or applications executed using the BARs exposed by the I / O device, and the target adaptation is selected to improve performance and / or enable operation of the features and / or applications.

[0034] The method according to the third aspect may be executed by a computer-readable storage medium storing program codes, wherein the program codes include instructions. When the instructions are executed on a computer, the instructions cause the computer to execute the method according to the third aspect.

[0035] The method according to the fourth aspect may be executed by a computer-readable storage medium storing program code, wherein the program code comprises instructions, and when executed on a computer, the instructions cause the computer to execute the method according to the fourth aspect.

[0036] Unless otherwise defined, all technical and / or scientific terms used herein have the same meaning as those known to those of ordinary skill in the art. Although methods and materials similar or equivalent to the methods and materials described herein can be used in the practice or testing of embodiments of the present invention, exemplary methods and / or materials are described below. In the event of a conflict, the patent specification including the definition shall prevail. In addition, these materials, methods and examples are merely illustrative and are not necessarily restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Some embodiments of the present invention are described herein by way of example only in conjunction with the accompanying drawings. Now with specific reference to the accompanying drawings, it should be emphasized that the details shown are only for the purpose of illustration and illustrative discussion of the embodiments of the present invention. In this regard, it will be apparent to those skilled in the art how to practice the embodiments of the present invention based on the accompanying drawings.

[0038] In the attached picture:

[0039] Figure 1 A block diagram of components of a computing device in which a PF driver is provided for some embodiments to dynamically adapt one or more BARs exposed by an I / O device providing virtualized hardware resources based on a request from a VF driver executing on a VM;

[0040] Figure 2 References to some examples Figure 1 A schematic diagram of an exemplary data flow between components of the computing device 104 is described;

[0041] Figure 3 A data flow diagram depicting exemplary data flows between a PF driver, a VF driver, and a VM of the VF driver dynamically adapting one or more BARs providing I / O device exposures of virtualized hardware resources based on requests from the VF driver executing on the VM, provided for some embodiments;

[0042] Figure 4 A two-step dynamic adaptation process for a BAR exposed by an I / O device is provided for some embodiments, wherein in a first step, the VF driver is unloaded and reloaded, and in a second step, the VF driver is not unloaded and reloaded;

[0043] Figure 5The mapping between BAR roles of virtual functions and I / O device BARs provided for some embodiments is a schematic diagram of an exemplary virtualization environment based on the mapping values ​​stored in the global CSR. DETAILED DESCRIPTION

[0044] In some embodiments, the present invention relates to virtual machines (VMs), and more particularly, but not exclusively, to communication between virtual machines and virtualized resources of physical hardware devices.

[0045] One aspect of some implementations of the system methods, apparatuses and / or code instructions described herein involves dynamically adapting one or more base address registers (BARs) exposed by an I / O device providing virtualized hardware resources by a physical function (PF) driver, based on a request from a virtual function (VF) driver executed on a virtual machine (VM) to perform target adaptation. Exemplary target adaptations include: increasing the memory size corresponding to a specific BAR, increasing the number of specific BARs, and adapting the structure of a specific BAR. For some BAR adaptations, the VM can perform a hot swap by reloading the VF driver without restarting the virtual machine. The re-enumeration and / or rescanning performed by the loaded and hot-swapped VF driver identifies the adapted BARs exposed by the I / O device. The VF driver can "hot swap" and / or act as a "hot swap" by unloading and reloading the VF driver again to display the content of a new I / O device, which is actually an existing I / O device adapted according to the request of the VF driver. Hot-swapping a VF exposes the adapter BAR for the VF driver.

[0046] The VF driver may receive an initial indication of a BAR exposed by an I / O device. The VF driver may perform internal probing and / or analysis to determine a target adaptation for the BAR exposed by the I / O device and send a request to perform the target adaptation for the PF adaptation. In response to receiving a confirmation message from the PF driver indicating that the target adaptation for the BAR exposed by the I / O device is achieved, the VF driver accesses a memory area allocated to the BAR exposed by the I / O device and adapts according to the target adaptation.

[0047] At least some of the computing devices, methods and / or code instructions described herein solve the technical problem of allocating virtualized resources of I / O devices to VMs. At least some of the computing devices, methods and / or code instructions described herein improve the standard method of allocating virtualized resources of I / O devices to VMs. Using the standard method, each VF driver of each VM is informed of the BAR exposed by the I / O device. The exposed BAR of the VF driver is fixed. In fact, the VF driver is "locked" to a specific I / O device setting. Changes to the exposed BAR are performed on the side of the I / O device itself and require a new version of the VF driver to be installed that is compatible with the I / O device changes. This problem is particularly evident in data centers such as cloud services, where a large number of VMs (e.g., thousands) are executed. In addition, the code executed on the VM can be imported by external customers using cloud services. Therefore, the fixed I / O device BAR setting may not be suitable for the different requirements of many different VF drivers of the VF.

[0048] In contrast, at least some embodiments described herein solve the above technical problems and / or provide the above improvements by enabling the VF driver to request adaptation of the BARs exposed by the I / O device. For example, to improve the performance of applications and / or features running on the VM, and / or to enable applications and / or features to run on the VM (wherein, when the adaptation of the BARs is not performed, the applications and / or features cannot run on the VM machine). For example, specific applications and / or functions that cannot run effectively using the standard 16KB memory space, for example, when the memory space is used for MSI-X interrupts, if many queues use the same vector, when the VF uses more queues and wants each queue to have its own interrupt vector, more delays may be generated. The VF driver may request to increase the memory space to 2MB, which may increase the number of MSI-X vectors. In another example, the VM provides remote direct memory access (RDMA) services. The VF driver may request additional BARs and / or larger BARs in order to have enough memory to isolate different areas of memory.

[0049] At least some embodiments described herein can adapt the BAR exposed by the I / O according to the requirements of each VF driver running on the corresponding VM. Since different VMs may run different VF drivers, such as different versions of VF drivers with different features and / or functions, the configuration of the BAR exposed by the I / O device may not be efficient or even suitable for all VF drivers. Using standard methods, the VF driver needs to be upgraded, which is unrealistic and / or requires great efforts in a cloud-based environment running thousands of VMs. At least some embodiments described herein enable each VF driver to adapt the BAR exposed by the I / O device according to its own requirements, so that different versions of the same VF driver and / or different VF drivers can be connected to the same I / O device through an interface. In addition, different versions of the same I / O device can be released without re-upgrading the VF driver. The new I / O hardware can adapt to the expected functions of the old VF driver I / O device BAR by showing its expected BAR space to the VF driver during negotiation. A VF driver can adapt its functionality to multiple I / O devices, which may have different I / O device BAR space configurations.

[0050] Before explaining at least one embodiment of the present invention in detail, it should be understood that the present invention is not necessarily limited to the details of the construction and arrangement of the components and / or methods described in the following description and / or drawings and / or examples when applied. The present invention can have other embodiments or can be practiced or implemented in various ways.

[0051] The present invention may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions, which cause a processor to perform various aspects of the present invention.

[0052] A computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer readable storage medium may be, but is not limited to, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above devices.

[0053] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network.

[0054] The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the final scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN); or connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), etc., may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electronic circuits, thereby performing various aspects of the present invention.

[0055] Various aspects of the present invention are described herein in conjunction with flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of boxes in the flowchart illustration and / or block diagram can be implemented by computer-readable program instructions.

[0056] The flow chart and block diagram in the figure have been described the structure, function and operation of the possible implementation of the system, method and computer program product provided by various embodiments of the present invention. In this regard, each square block in the flow chart or block diagram can represent the part of a module, section or instruction, including one or more executable instructions for realizing a specified logical function. In some alternative implementations, the function described in the square block may not be performed in the order described in the figure. For example, in fact, the two square blocks shown in succession can be performed almost simultaneously, or sometimes, the square blocks can be performed in the opposite order, determined according to the functions involved. It should also be noted that each square block in the block diagram and / or flow chart and the combination of square blocks in the block diagram and / or flow chart can be performed by a system based on special-purpose hardware, which performs a specific function or action, or performs a combination of special-purpose hardware and computer instructions.

[0057] Reference now Figure 1 , is a block diagram of components of a computing device 104 for dynamically adapting one or more BARs 126 exposed by an I / O device 114 providing virtualized hardware resources, according to a request from a VF driver 112 executing on a VM 110, provided by some embodiments. Also refer to Figure 2 , which is a reference provided by some embodiments Figure 1 Schematic diagram of an exemplary data flow between components of the computing device 104 described herein. Figure 3 , is a data flow diagram provided by some embodiments depicting exemplary data flows between a PF driver, a VF driver, and a VM of the VF driver that dynamically adapts one or more BARs exposed by an I / O device providing virtualized hardware resources and / or changes its number based on a request from the VF driver executing on the VM. Also refer to Figure 4 , is a flowchart of two-step dynamic adaptation of a BAR exposed by an I / O device provided by some embodiments, wherein in the first step, the VF driver is unloaded and reloaded, and in the second step, the VF driver is not unloaded and reloaded. Also refer to Figure 5 , is a schematic diagram of an exemplary virtualization environment 502 provided by some embodiments. Figures 3 to 5 The features described can be referenced by Figure 1 and / or Figure 2 The components of the computing device 104 described are implemented, for example, by the processor 102 of the computing device 104 executing code instructions (eg, code 106A) stored in the memory 106 .

[0058] For example, computing device 104 can be implemented as a computing cloud, a single computing device (e.g., a client terminal), a group of computing devices arranged in parallel, a network server, a local server, a remote server, a client terminal, a mobile device, a fixed device, an information kiosk, a smartphone, a laptop computer, a tablet computer, a wearable computing device, an eyeglass computing device, a watch computing device, and a desktop computer.

[0059] For example, the processor 102 is implemented as a central processing unit (CPU), a graphics processing unit (GPU), a field programmable gate array (FPGA), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a custom circuit, a processor connected to other units, and / or a dedicated hardware accelerator. The processor 102 can be implemented as a single processor, a multi-core processor, and / or a processor cluster for parallel processing (which can include homogeneous and / or heterogeneous processor architectures).

[0060] The memory 106 stores code instructions that can be implemented by the processor 102. For example, the memory 106 is implemented as a random access memory (RAM), a read-only memory (ROM), and / or a storage device, such as a non-volatile memory, a magnetic medium, a semiconductor memory device, a hard disk drive, a removable memory, and an optical medium (such as a DVD or CD-ROM).

[0061] The memory 106 may store a virtual machine manager (VMM) 108 that manages and / or runs one or more virtual machines (VMs) 110. The VMM 108 may be implemented as a virtual machine manager. The VMM 108 may be implemented in hardware, software, firmware, and / or a combination thereof.

[0062] Each VM 110 executes one or more virtual function (VF) drivers 112 .

[0063] The computing device 104 includes and / or communicates with one or more I / O devices 114. The I / O devices 114 may be input / output (I / O) devices such as universal serial buses, network adapters (for wired and / or wireless networks), network interface cards, accelerators, graphics devices, and storage devices.

[0064] I / O device 114 exposes BAR 126, which is dynamically adapted by PF driver 116 as described herein.

[0065] Each I / O device 114 is associated with one or more physical function (PF) drivers 116 .

[0066] The computing device 104 may include and / or communicate with one or more data devices 118. For example, the data storage device 118 may store different versions of VMs, VF drivers, PF drivers, and / or VMMs and / or other data. It should be noted that code instructions may be selectively loaded from the data storage device 118 into the memory 106 for execution by the processor 102. For example, the data storage device 118 may be implemented as a memory, a local hard drive, a removable storage unit, an optical disk, a storage device, and / or a remote server and / or a computing cloud (e.g., accessed via a network connection).

[0067] The computing device 104 may communicate with a network 152 , such as the Internet, a local area network, a virtual network, a wireless network, a cellular network, a local bus, a point-to-point link (eg, wired), and / or combinations thereof.

[0068] The computing device 104 may include a network interface for communicating with a network 152. The network interface may be implemented as one or more of the I / O devices 114 having an associated PF driver 116. The network interface may be virtualized for use by multiple VMs 110 through corresponding execution of VF drivers 112. For example, different VMs 110 may access the network 152 through a VF driver 112 communicating with the PF driver 116 of the network interface.

[0069] The computing device 104 may include and / or communicate with one or more physical user interfaces 150 that include mechanisms for user interaction, such as entering data (e.g., selecting a version of a VF to load) and / or viewing data (e.g., viewing an adaptation BAR exposed by an I / O device).

[0070] For example, the exemplary physical user interface 150 includes one or more of a touch screen, a display, a gesture-activated device, a keyboard, a mouse, voice-activated software using a speaker and a microphone, and a coordinator that sends data through a network interface.

[0071] Now back to Figure 2 , the I / O device 114 is virtualized through a PF driver 116. The physical resources of the I / O device 114 are partitioned and made accessible and usable by multiple VMs 110A to 110D through corresponding execution of VF drivers 112A to 112D. Each VF driver 112A to 112D communicates with a PF 116 associated with the I / O device 114. The VF drivers 112A to 112D may be independent of the actual underlying I / O device 114 being used.

[0072] For example, the VF driver 112 and the PF driver 116 are defined by the PCI standard (PCI express, PCIe) format, in particular the single root input / output (I / O) virtualization (SR-IOV) feature of PCIe. SR-IOV enables the allocation of resources of an I / O device 114 (e.g., a network adapter) to be used by multiple VMs 110A to 110D. For example, the memory and / or network port of the I / O device 114 of the network adapter is partitioned and shared by the VF drivers 112A to 112D. The network traffic flows flowing between each VF 112A to 112D and PF 116 can be distinguished and identified, allowing memory and / or interrupt conversion to be applied between the corresponding VF 112A to 112D and PF 116. The network traffic flow can flow between PF 116 and each corresponding VF 112A to 112D without affecting the VF. Network traffic can achieve performance close to bare metal (ie, non-virtualized) performance.

[0073] Optionally, the VF drivers 112A to 112D are implemented as adaptive virtual function (AVF) drivers and / or assignable device interfaces (ADI). As used herein, the term AVF may sometimes refer to the term ADI, and / or may be interchangeable with the term ADI. Multiple instances of AVF and / or ADI are implemented on multiple VMs 110. Instances of AVF and / or ADI VFs are mapped to a single common PF driver 116. Instances of AVF and / or ADI are performed simultaneously and adapted in a similar manner. AVF adapts to changes in the physical function driver (PF) functions associated therewith. Using AVF, PF can be updated without having to update all associated VF drivers. AVF has a single public device ID and brand string. The adaptive virtual function (AVF) can be implemented as an SR-IOV virtual function with the same device ID on different vendor I / O devices 114. In some implementations, the AVF driver is the VF driver that supports all future vendor devices without requiring VM updates. For the AVF driver, each new drop of the VF driver adds additional advanced features that may be activated in the VM in a device-independent manner without compromising basic functionality when the underlying hardware device supports them.

[0074] Reference now Figure 3, depicts an illustrative data flow between a PF driver 350, a VF driver 352, and a VM 354 executing the VF driver 352 for the PF driver 350 to dynamically adapt one or more BARs exposed by an I / O device providing virtualized hardware resources based on a request from the VF driver 352 executing on the VM, provided by some embodiments.

[0075] The computing device executes a VF driver 352 running on a VM 354. The VF driver 352 corresponds to the PF driver 350. The I / O device provides virtualized hardware resources for use by multiple VF drivers of multiple VMs. The VF driver 352 described here is an example of one of the multiple VF drivers. The features described with reference to the VF driver 352 can be implemented by any of the multiple VF drivers, optionally independently by each of the multiple VF drivers. The computing device executes a VMM that implements the PF driver 350 and the BAR exposed by the I / O device. The PF driver 350 corresponds to multiple VF drivers implemented by multiple VMs.

[0076] Optionally, the VF driver is implemented as multiple instances of an adaptive VF (AVF) and / or an assignable device interface (ADI). Instances of the AVF are mapped to a PF driver 350 implemented as a single common PF driver. The adaptation BARs exposed by the I / O devices are used by the VM that implements the AVF and / or ADI instances. It should be noted that ADI does not use BARs such as VF. In the case of ADI, the driver can request more resources, as described in this article with reference to VF, which causes the PF to perform some adaptation and mapping based on the PF's BARs (for example, ADI uses page slices on the PF BARs and uses PASIDs to completely isolate between them).

[0077] Optionally, the I / O device implements a protocol for virtualizing its hardware resources according to the Peripheral Component Interconnect Express (PCIe) standard. PCIe can implement single-root input / output virtualization (SR-IOV).

[0078] In 302, the PF driver provides the VF driver with an indication of an initial configuration of the BARs exposed by the I / O device. The initial configuration of the I / O device may be set (e.g., by the manufacturer) to represent a minimum configuration that supports a set of basic capabilities that may be negotiated between the VF driver and the PF driver. The initial configuration of the I / O may be set in anticipation of the VF driver requesting an adaptation of the initial minimum configuration of the BARs to extend the minimum configuration to support a set of advanced capabilities negotiated between the VF driver and the PF driver.

[0079] The scalable initial configuration improves the utilization and / or computing efficiency resulting from the configuration of the BARs. The initial configuration may represent the minimum requirements for running basic functions, providing maximum initial utilization and / or computing efficiency by allocating minimum resources. The initial configuration may include a minimum number of BARs and / or minimum memory occupancy BARs, such as enabling a basic set of capabilities. The initial configuration may be expanded as needed based on a request from a VF driver, for example, by increasing the number of BARs and / or increasing the memory size corresponding to the BARs. Different VF drivers may expand the initial configuration based on their respective requirements. At least some embodiments provide an enhanced ability to discover and negotiate capabilities between a VF driver and an I / O device, whereas in standard methods, the negotiation of capabilities is limited by the fixed BARs exposed by the I / O device.

[0080] In 304, the VF driver receives an indication of the initial configuration of the BARs exposed by the I / O device from the PF driver. Alternatively, when the VM is executed, the VF driver with the initial configuration of the BARs exposed by the I / O device is already in a given state. The BAR count and / or size may be defined before the VM is executed, otherwise the BARs will not be mapped for the kernel and user applications.

[0081] At 306 , the VF driver may perform internal probing and / or analysis to determine a target adaptation for the BARs exposed by the I / O device.

[0082] Internal probing and / or analysis to determine target adaptation for at least one of the BARs exposed by the I / O device may be performed during startup of the VF driver and / or during a negotiation phase in which the VF driver negotiates basic and / or advanced capabilities with the PF driver.

[0083] For example, internal probing and / or analysis may be performed by comparing the requirements of the VF driver to perform its tasks with the initial configuration of the BARs exposed by the I / O device. The internal probing and / or analysis may identify a target adaptation of the initial BARs exposed by the I / O device to obtain the requirements of the VF driver.

[0084] The VF driver sends a request message to the PF driver at 308. The request message includes a request to perform target adaptation of the BARs exposed by the I / O device, optionally the target adaptation identified by the initial probing and / or analysis.

[0085] The VF driver may request to change the structure of the BAR, ie, change the memory size corresponding to one or more BARs, and / or change (eg, increase) the number of BARs.

[0086] Optionally, the request is sent from the VF driver to the PF driver via a hardware mailbox process. The mailbox can be part of an interoperation that uses the initial configuration of the BARs that are intended to provide common functionality for basic functionality.

[0087] In 310, the PF driver receives a request message from the VF driver, the request message including a request to adapt at least one of the BARs exposed by the I / O device.

[0088] The request message may include an adaptation, a reload of the VF driver being indicated as a reloaded VF driver unloading and reloading in order to use an adapted BAR exposed by the I / O device, and / or the VF driver not necessarily being indicated as a reloaded VF driver unloading and reloading in order to use an adapted BAR exposed by the I / O device.

[0089] An exemplary adaptation of a BAR exposed by an I / O device, the VF driver is instructed to unload and reload as a reloaded VF driver to use the adaptation (e.g., by implementing 314 to 320 and 324 to 326) including changes to the BAR structure, such as increasing the memory size corresponding to a particular BAR, increasing the number of particular BARs, adapting the structure of a particular BAR.

[0090] Exemplary adaptations of BARs exposed by an I / O device that the VF driver can use to continue operating without necessarily going through an unload / reload cycle (e.g., by excluding 314 to 320 and 324 to 326) include, for example, adapting an existing role of a particular BAR to a new role, and adapting a structure of a particular BAR to the new role. The VF driver can request a change in role of an existing BAR, wherein the VF driver uses the particular BAR to assume the new role during its operation without going through an unload and reload cycle. The VF driver does not need to unload and reload to effectively change roles, but can continue to operate.

[0091] The request to adapt the BAR exposed by the I / O device may include an adaptation that instructs the VF driver to undergo an unload and reload cycle and / or an adaptation that instructs the VF driver not to undergo an unload and reload cycle. There may be two separate requests, the first request instructing the VF driver to undergo an unload and reload cycle, and the second request instructing the VF driver to undergo an unload and reload cycle. Alternatively, there is a request that the VF driver is instructed to undergo an unload and reload cycle. Alternatively, there is a request that the VF driver is not instructed to undergo an unload and reload cycle.

[0092] Optionally, before implementing the adaptation, the adaptation is analyzed to determine if any adaptation requires reloading the VF driver. In one implementation, all adaptations that require an unload / reload cycle and that do not require an unload / reload cycle are performed, and the VF driver undergoes an unload and reload cycle. In another implementation, first, for example, adaptations that do not require an unload / reload cycle are implemented based on a first request or in a single request. Once the first set of adaptations is executed and the VF driver is using the BARs that are adapted based on the first adaptation, a second set of adaptations that require an unload / reload cycle is implemented, for example, based on a second request or in a single request. The VF driver undergoes an unload / reload cycle and uses the BARs that are adapted based on the second adaptation. The processes described herein describe all described situations.

[0093] Alternatively, the request to adapt the BARs exposed by the I / O device includes a first request in response to which the VF driver is instructed to unload and reload as a reloaded VF driver. The VF driver provides a second request, which can be provided after the VF driver completes the unload and reload cycle and / or provided as part of the initial first request. The second request includes an adaptation that does not require an unload and reload cycle. In response to implementation of the second request, the reloaded VF driver assumes a new role during its operation using the adapted BARs without undergoing another unload and reload cycle.

[0094] In 312, the PF driver and the VF driver negotiate on the adaptation set of the BAR exposed by the I / O device for implementation. Then, the BAR exposed by the I / O is adapted according to the negotiated adaptation set. The request sent from the VF driver to the PF driver can serve as an initial baseline for negotiation. The VF driver and the PF driver can negotiate which adaptation to implement, providing the VF driver and the PF driver with the flexibility to select and implement BAR adaptation.

[0095] The negotiation process may include the PF driver analyzing features of the request message to determine which of the requested adaptations of the BARs exposed by the I / O device are implementable by the PF driver and / or the I / O driver. For example, whether the VF driver requires a reasonable request that can be satisfied, whether the VF driver's request will affect other VMs (e.g., other customers), and / or whether the customer is eligible (e.g., has paid) for the adaptation requested by the VF driver. The PF driver may provide a negotiation message to the VF driver, indicating which adaptations of the BARs exposed by the I / O device are implementable. The VF driver may send a response to the negotiation message to the PF driver, indicating which of the implementable adaptations of the BARs exposed by the I / O device the VF driver chooses to implement. The PF driver may adapt the BARs exposed by the I / O device based on the response to the negotiation message.

[0096] In 314, when the request from the VF driver includes that the VF driver needs to adapt the unloading and reloading cycle, the PF driver transmits data to the VM to trigger the unloading of the VF driver. For example, the PF driver sends an instruction to the VM to unload the VF driver.

[0097] At 316 , the VM uninstalls the VF driver.

[0098] In 318, the VF driver is uninstalled.

[0099] In 320, a message instructing the VF driver to uninstall may be provided to the PF driver.

[0100] In 322, the PF driver may adapt the BAR exposed by the I / O device based on the response to the negotiation message.

[0101] When the adaptation is performed by a reloaded VF driver that undergoes an unload and reload cycle, the PF driver adapts the BAR in response to receiving an indication that the VF driver is unloaded. When the adaptation is performed by a VF driver that does not require an unload and reload cycle, the PF driver may perform the adaptation in response to receiving a request from the VF driver.

[0102] In 324 , when the VF driver is in the unloaded state, and in response to the PF driver completing the adaptation of the BAR exposed by the I / O device, the VM receives a send instruction from the PF driver or the VMM to perform hot swap by rescanning the bus without restarting the VM.

[0103] In 326, the VF driver in the uninstalled state is hot-swapped by reloading without restarting the VM. Before reloading the VF driver, the VM may perform a re-enumeration and / or re-scan on the bus (e.g., PCIe). Once the re-enumeration and / or re-scan (hot-swap) is complete, the VF driver identifies the adapter BAR exposed by the I / O device.

[0104] At 328, an acknowledgement message may be sent from the PF to the VF driver indicating that adaptation of the BARs exposed by the I / O device has been completed.

[0105] In 330, a confirmation message from the PF driver, indicating that the target adaptation of the BAR exposed by the I / O is achieved, is received by the VF driver. It should be noted that before receiving the confirmation message, the VF driver may undergo the detection described herein for initializing the mailbox. Once the VF driver is loaded and initialized, the confirmation message may be received.

[0106] The VF driver is using the adapted BAR in 332. The VF driver may use the adapted BAR in response to receiving the confirmation message and / or when the reloaded and hot-swapped VF driver completes re-enumeration and / or rescanning.

[0107] The VF driver can access the memory region allocated to the BAR exposed by the I / O device, which is adapted as described herein.

[0108] The VF driver may use the adapter BAR exposed by the I / O device to operate features and / or apply and / or load features. The application and / or feature may be executed using the adapter BAR exposed by the I / O device.

[0109] In 334, features 306 to 332 may be dynamically iterated during operation of the VF driver. For example, the VF driver dynamically re-performs internal probing and / or analysis (e.g., as described with reference to 306) during operation of a feature and / or application executed using an adapted BAR exposed by an I / O device and / or loading a feature and / or application to determine another target adaptation of a previously adapted BAR exposed by the I / O device. Another target adaptation may be selected to improve performance and / or enable operation of the feature and / or application.

[0110] At 336, the process exits, ie, completes the driver load flow or terminates.

[0111] Now back to Figure 4 As used herein, a VF driver is sometimes interchangeable with an AVF or ADI driver.

[0112] In 402, a VF driver detection function is performed.

[0113] In 404, the VF driver is initialized. Communication between the VF driver and the PF driver is established. The VF driver and the PF driver may perform a handshake process to negotiate basic and / or advanced features.

[0114] At 406 , a first analysis session of the two analysis sessions is performed.

[0115] A first analysis is performed to determine whether the VF driver needs to adapt the configuration of the BAR exposed by the I / O device (optionally a PCIe I / O device). The changes in the BAR structure exposed by the I / O device can be used by the VF driver after undergoing an unload and reload cycle.

[0116] A first request defining a first target adaptation of a BAR exposed by the I / O device may be generated based on the first analysis.The first request is provided by the VF driver to the PF driver.

[0117] For example, the analysis may be accomplished by the VF driver performing internal probing and / or analysis to determine a target adaptation for at least one of the BARs exposed by the I / O device.

[0118] In 408, the VF driver is unloaded, optionally by the VM. In response to the unloading of the VF driver, adaptation of the BAR structure exposed by the I / O device is optionally performed by the PF driver. The adaptation can be defined by a first request issued by the VF driver to the PF driver. An example of adaptation of the BAR structure exposed by the I / O device, wherein an unloading and reloading cycle of the VF driver is performed so that the reloaded VF driver can use the adapted BARs including increasing the memory size corresponding to one or more BARs in the BARs exposed by the I / O device, and increasing the number of BARs for the I / O device. In response to completing the adaptation of the BAR structure exposed by the I / O device, the VF driver is reloaded. Iterate features 402 to 406 to reload the VF driver and determine whether additional adaptation of the BAR structure exposed by the I / O device is required.

[0119] At 410, a second analysis session is performed when no additional adaptation of the structure of the BAR exposed by the I / O device is required.

[0120] A second analysis is performed to determine whether the VF driver needs to adapt the configuration of the BARs exposed by the I / O device. Changes to the configuration of the BARs exposed by the I / O device can be used by the VF driver after undergoing the change or without undergoing an unload and reload cycle.

[0121] A second request defining a second target adaptation of the BAR exposed by the I / O device may be generated based on the second analysis. The second request is provided by the VF driver to the PF driver.

[0122] For example, the analysis may be accomplished by the VF driver performing internal probing and / or analysis to determine a target adaptation for at least one of the BARs exposed by the I / O device, e.g., as described above with reference to Figure 3 As described in 306.

[0123] In response to the unloading of the VF driver, an adaptation of the BAR configuration exposed by the I / O device is optionally performed by the PF driver in 412. The adaptation may be defined by a second request issued by the VF driver to the PF driver. In the example of the adaptation of the BAR structure exposed by the I / O device, the VF driver may use the adapted BAR without unloading and reloading, including adapting an existing role of a particular BAR to a new role.

[0124] In 414, when the structure and / or configuration of the BAR exposed by the I / O device has been adapted, the VF driver may use the adapted BAR, for example, to access a memory region allocated to the adapted BAR exposed by the I / O device.

[0125] Now back to Figure 5 , a scalable IVO setting (S-IOV) can be implemented in a virtualized environment 502. The PF driver 512 can dynamically map one or more BARs 526 exposed by an I / O device 522 implemented as a network card (NETC) 522 providing virtualized hardware resources based on a request from a virtual network interface controller (vNic) 508 executed on a VM 506.

[0126] The virtualized environment 502 includes one or more of the following exemplary components:

[0127] The user space 504 includes one or more VMs 506, each of which implements a vNic driver 508 that communicates with an ADI 516. It should be noted that VF is not implemented in the scalable IOV virtualization environment 502. ADI is used instead.

[0128] A virtual machine manager / host kernel space 510 includes a PF driver 512, a virtual device (VDEV) 514 that implements one or more assignable device interfaces (ADIs) 516, and a virtual device composition module (VDCM) 518. The virtual device composition module 518 can provide software-managed resource mapping between the VDEV 514 and the ADI 516.

[0129] An input / output memory management unit (IOMMU) 550 and direct memory access (DMA) with a Process Address Space ID (PASID) remapping code 520 implement one or more ADIs 516 and PF 520. Each ADI 516 is labeled with a unique PASID.

[0130] The NETC 522 may be PCIe compliant. The hardware resources of the NETC 522 are virtualized through the ADI 516 so that each of the multiple VMs 506 accesses its own assigned ADI 516 to receive and / or send traffic through the connected network, for example, through one or more corresponding queues (Q) 524.

[0131] NETC 522 exposes PF base address registers (BARs) 526 that are mapped to ADI 516, which are dynamically adapted as described herein. Each ADI 516 can access a different isolated portion of PF BAR 526 and cannot access other portions of PF BAR 526. NETC 522 may include additional registers, such as PF configuration (Conf) registers 528 and MSI-X registers 530.

[0132] Virtualizing the resources of the NETC 522 using software can provide near-host-metal performance.

[0133] The virtual device component module 518 can provide slow path enumeration (represented by dashed line 532) and fast path enumeration (represented by solid line 534) pass-through. Slow path enumeration (represented by dashed line 532) is performed by software. Fast path enumeration (represented by solid line 534) is provided by hardware deployed for direct access. DMA provides isolation between fast paths. Each vNic driver 508 is provided with an isolated fast path to the partitioned resources of the NETC 522 through DMA, and the ADI 516 allocated by it uses the corresponding unique PASID.

[0134] Other systems, methods, features and advantages of the present invention will be or become apparent to those skilled in the art after studying the following drawings and detailed description. It is intended that all such other systems, methods, features and advantages be included in this description, within the scope of the present invention, and protected by the accompanying claims.

[0135] The description of various embodiments of the present invention is for illustrative purposes only, and these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles, practical applications, or technological advances of the present embodiments, or to enable other persons skilled in the art to understand the embodiments disclosed herein, compared to the technology available on the market.

[0136] It is anticipated that many related drivers will be developed during the life of the patent expiring on this application, and the scope of the term driver is intended a priori to include all such new technologies.

[0137] As used herein, the term "about" refers to ± 10%.

[0138] The terms "including," "having," and variations thereof mean "including but not limited to." This term encompasses the terms "consisting of" and "consisting essentially of.

[0139] The phrase "consisting essentially of means that the composition or method may include additional ingredients and / or steps, but only if the additional ingredients and / or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

[0140] As used herein, the singular forms "a", "an" and "the" include plural references unless the context clearly indicates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

[0141] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any “exemplary” embodiment is not necessarily to be construed as preferred or advantageous over other embodiments, and / or does not exclude the incorporation of features of other embodiments.

[0142] The word “optionally” is used herein to mean “provided in some embodiments and not provided in other embodiments.” Any particular embodiment of the present invention may include a number of “optional” features, unless such features are mutually incompatible.

[0143] In the present application, various embodiments of the present invention can be presented in range format. It should be understood that the description of the range format is only for convenience and brevity, and should not be interpreted as a fixed limitation on the scope of the present invention. Therefore, the description of the range should be considered to have specifically disclosed all possible sub-ranges and individual numerical values ​​within the range. For example, the description of the range from 1 to 6 should be considered to have specifically disclosed sub-ranges from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6, etc. and single numbers such as 1, 2, 3, 4, 5 and 6 within the range. No matter how wide the range is, this applies.

[0144] When a numerical range is indicated herein, it is intended to include any number (fractional or integer) listed within the indicated range. The phrases "a range between a first indicated number and a second indicated number" and "a range from a first indicated number to a second indicated number" are used interchangeably herein to include the first indicated number and the second indicated number and all fractions and integers therebetween.

[0145] It should be understood that, for the sake of brevity of description, certain features of the present invention described in the context of a separate embodiment may also be provided in combination in a single embodiment. Conversely, for the sake of brevity of description, the various features of the present invention described in the context of a single embodiment may also be provided individually or in any suitable sub-combination or as any suitable other embodiment of the present invention. Certain features described in the context of various embodiments are not considered essential features of those embodiments, unless the embodiments described are invalid without these elements.

[0146] All publications, patents and patent specifications mentioned in this specification are hereby incorporated by reference into this specification, and likewise, each individual publication, patent or patent application is specifically and individually incorporated herein. In addition, the citation or identification of any reference in this application shall not be construed as allowing such reference to take precedence over the present invention in the prior art. To the extent that section headings are used, they should not be construed as necessarily limiting.

Claims

1. A computing device (104), It is characterized in that The computing device is configured to communicate with an input / output (I / O) device (114) that provides virtualized hardware resources for use by a plurality of virtual function (VF) drivers (112) of a plurality of virtual machines (VMs) (110), the computing device executing a virtual machine manager (VMM) (108) that implements a physical function (PF) driver (116) and a plurality of base address registers (BARs) (126) exposed by the I / O device, wherein the PF driver corresponds to the plurality of VF drivers implemented by the plurality of VMs, the PF driver being configured to: receiving a request message from a VF driver among the plurality of VF drivers, wherein the request message comprises a request to adapt at least one of the BARs exposed by the I / O device; In response to receiving the request message from the VF driver, transmitting data to the VM that triggers the VF driver to be uninstalled; In response to the VF driver uninstallation, adapting at least one of the BARs exposed by the I / O device according to the request message; In response to completing the adaptation of at least one of the BARs exposed by the I / O device, sending an instruction to the VM to perform a hot swap so as to perform the hot swap by reloading the VF driver without restarting the VM, wherein after completing the hot swap performed by the VM, the loaded VF driver identifies the adapted at least one BAR exposed by the I / O device; A confirmation message is provided to the VF driver indicating adaptation of at least one of the BARs exposed by the I / O device.

2. The computing device according to claim 1, It is characterized in that The request to adapt at least one of the BARs exposed by the I / O device includes at least an operation selected from the group consisting of: increasing a memory size corresponding to a specific BAR, increasing a number of specific BARs, and adapting a structure of a specific BAR.

3. The computing device according to claim 1, It is characterized in that The request to adapt at least one of the BARs exposed by the I / O device comprises at least one operation selected from the group consisting of: adapting an existing role of a specific BAR to a new role and adapting a structure of a specific BAR.

4. The computing device according to claim 3, It is characterized in that The VF driver uses the specific BAR to assume the new role during its operation without going through an unload and reload cycle.

5. The computing device according to claim 4, It is characterized in that The request to adapt at least one of the BARs exposed by the I / O device includes a first request, in response to which the VF driver is instructed to unload and reload as a reloaded VF driver, the first request including at least an operation selected from the group consisting of: increasing a memory size corresponding to a specific BAR, and increasing the number of specific BARs; the VF driver provides a second request, the second request including a request to adapt at least one of the BARs exposed by the I / O device, including at least one operation selected from the group consisting of: adapting an existing role of a specific BAR to a new role, in response, the reloaded VF driver uses the specific BAR to assume the new role during its operation without undergoing an unload and reload cycle.

6. A computing device according to any one of claims 1 to 5, It is characterized in that The PF device is also used to: providing an indication of an initial configuration of the BAR exposed by the I / O device to the VF driver, the initial configuration representing a minimum configuration supporting a set of basic capabilities negotiated between the VF driver and the PF driver, wherein the adaptation request includes a request to extend the minimum configuration to support a set of advanced capabilities negotiated between the VF driver and the PF driver.

7. A computing device according to any one of claims 1 to 5, It is characterized in that The PF device is also used to: negotiating with the VF driver an adaptation set of at least one of the BARs exposed by the I / O device for implementation, The adapting comprises adapting the at least one BAR according to the negotiated adaptation set.

8. The computing device according to claim 7, It is characterized in that Negotiations include: analyzing the request message to determine which of the requested adaptations of at least one of the BARs exposed by the I / O device are achievable; providing a negotiation message to the VF driver indicating which of the adaptations of at least one of the BARs exposed by the I / O device are achievable; receiving a response to the negotiation message from the VF driver, indicating that the VF driver selects which of the implementable adaptations of at least one of the BARs exposed by the implementable I / O device to implement, Wherein the adapting comprises adapting at least one of the BARs exposed by the I / O device according to the response to the negotiation message.

9. A computing device according to any one of claims 1 to 5, It is characterized in that The PF driver is further configured to adapt at least one BAR of the I / O device through a hardware mailbox process according to the request.

10. The computing device according to any one of claims 1 to 5, It is characterized in that The I / O device implements a protocol for virtualizing its hardware resources according to the Peripheral Component Interconnect Express (PCIe) standard.

11. The computing device according to claim 10, It is characterized in that The PCIe implements single-root input / output virtualization (SR-IOV).

12. A computing device according to any one of claims 1 to 5, It is characterized in that Multiple instances of adaptive VF (AVF) and / or assignable device interface (ADI) are implemented as the multiple VF drivers, the multiple instances of the AVF are mapped to a PF driver implemented as a single common PF driver, wherein the at least one BAR exposed by the I / O device is used by multiple VMs implementing the multiple instances of the AVF and / or ADI.

13. A computing device (104), It is characterized in that A VF driver (112) running on a VM (110) is executed, the VF driver corresponding to a PF driver (116) and an input / output (I / O) device (114) providing virtualized hardware resources, wherein: The VF driver is configured to receive an indication of a plurality of BARs exposed by the I / O device (126); the VF driver to perform internal probing and / or analysis to determine target adaptation for at least one of the BARs exposed by the I / O device; The VF driver is configured to send a request message to the PF driver, wherein the request message includes a request to perform the target adaptation of at least one of the BARs exposed by the I / O device; The VM is used to receive data transmitted by the PF to uninstall the VF driver; The VM is configured to receive an instruction sent by the PF to perform a hot swap so as to reload the VF driver without restarting the VM; the reloaded VF driver to receive, after completion of the hot swap performed by the VM, a confirmation message from the PF driver indicating the target adaptation of at least one of the BARs exposed by the I / O device; and accessing a memory region allocated to the plurality of BARs exposed by the I / O device and adapted according to the adaptation.

14. The computing device according to claim 13, It is characterized in that The internal probing and analysis for determining the target adaptation for at least one of the BARs exposed by the I / O device is performed during startup of the VF driver and during a negotiation phase in which the VF driver negotiates basic and / or advanced capabilities with the PF driver.

15. A computing device according to claim 13 or 14, It is characterized in that The internal probing and analysis for determining the target adaptation for at least one of the BARs exposed by the I / O device is dynamically performed during operation of a feature and / or application and / or loading of the feature and / or application executed using the BAR exposed by the I / O device, the target adaptation being selected to improve performance and / or enable operation of the feature and / or application.

Images