Computer equipment, driver systems and driver modules hot-upgrade methods, storage media and program products

Abstract

This application provides a computer device, a driver system and a method for hot-upgrading driver modules, a storage medium, and a program product. In this application, a novel user-mode driver system for enabling device pass-through is provided. The user-mode driver in this system is split into a routing module and a driver module. The routing module implements the function interfaces of functional functions, while the driver module is responsible for the code implementation of these functional functions. By exposing the function interfaces to virtualization instances and pointing them to the code implementation in the currently active driver module, the virtualization instances can achieve pass-through access to the device through the function interfaces. Because the code implementation of the functional functions and the externally accessible function interfaces are decoupled, and by controlling the function interfaces to always point to the currently active driver module, hot-upgrading of the user-mode driver is completed seamlessly without affecting the pass-through access of the virtualization instances to the device, thereby improving the system's availability, scalability, and maintainability.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a computer device, a driver system and a method for hot-upgrading driver modules, a storage medium and a program product. Background Technology

[0002] Input / output virtualization is one of the key technologies in cloud computing, and SR-IOV (Single Root I / O Virtualization) is a specific implementation of I / O virtualization. It virtualizes a single physical PCI (Peripheral Component Interconnect) device into multiple virtual PCI devices, and then bypasses the virtual PCI devices to each virtual machine, enabling a single physical PCI device to support multiple virtual machines in application scenarios.

[0003] Passthrough of PCI devices based on SR-IOV relies on the host machine providing a userspace driver framework suitable for PCI devices. VFIO (Virtual Function I / O) is a complete userspace driver solution that can safely expose the I / O, interrupt, and DMA (Direct Memory Access) capabilities of physical PCI devices to user space, and then passthrough the physical PCI devices to the virtual machine in user space.

[0004] However, the VFIO PCI driver does not support hot upgrade functionality, which requires service interruption and reduces system availability when kernel module updates or vulnerability fixes occur. Therefore, it is necessary to implement a user-space driver solution for PCI devices that supports hot upgrades. Summary of the Invention

[0005] This application provides a computer device, a driver system and a driver module hot-upgrade method, a storage medium and a program product, to provide a new user-mode driver system that enables device pass-through, supports hot upgrades, and thus improves system availability.

[0006] This application provides a computer device, including: a host machine, wherein a virtualization instance runs in the user mode of the host machine, and a first driver system is implemented in the kernel mode of the host machine. The first driver system includes at least a first user-mode driver, which includes a routing module and a first driver module, and the first driver module is hot-upgradeable to a second driver module. The routing module includes a function interface for at least one functional function, and the first driver module and the second driver module are different code implementations of the at least one functional function. The at least one functional function is used to directly connect a target hardware device of the host machine to the virtualization instance. The routing module is used to control the function interface to point to the first driver module before hot upgrade and to point to the second driver module after hot upgrade, and to expose the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade.

[0007] This application embodiment also provides a driver system, including: at least a first user-mode driver, the first user-mode driver including a routing module and a first driver module, and the first driver module being hot-upgradeable to a second driver module; the routing module including a function interface of at least one function, the first driver module and the second driver module being different code implementations of the at least one function, the at least one function being used to pass through the target hardware device of the host machine to the virtualization instance; the routing module being used to control the function interface to point to the first driver module before hot upgrade and to point to the second driver module after hot upgrade, and to expose the function interface to the virtualization instance, so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade.

[0008] This application also provides a method for hot-upgrading a driver module, used to hot-upgrade a user-mode driver. The user-mode driver includes a routing module and a first driver module. The first driver module can be hot-upgraded to a second driver module. The routing module includes a function interface for at least one functional function. The first driver module and the second driver module are different code implementations of the at least one functional function. The method includes: before hot-upgrading, controlling the function interface to point to the first driver module; controlling the function interface to change from pointing to the first driver module to pointing to the second driver module, so as to hot-upgrade the first driver module to the second driver module.

[0009] This application also provides an electronic device, including a memory and a processor. The memory is used to store a computer program, and the processor is coupled to the memory to execute the computer program to implement the steps in the various methods provided in this application.

[0010] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to perform the steps in the methods described above.

[0011] This application also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to implement the steps described in the above method embodiments.

[0012] This application provides a novel user-mode driver system for enabling device pass-through. The system includes at least the user-mode driver required for device pass-through. The user-mode driver is divided into a routing module and a driver module. The routing module implements the function interfaces of functional functions, while the driver module is responsible for the code implementation of these functions. By exposing the function interfaces to virtualization instances and pointing them to the code implementation in the currently active driver module, virtualization instances can achieve pass-through access to devices through the function interfaces. Because the code implementation of the functional functions and the externally accessible function interfaces are decoupled, and by controlling the function interfaces to always point to the currently active driver module, hot upgrades of the user-mode driver can be completed without the virtualization instances being aware of the process. The entire hot upgrade process does not affect the virtualization instances' pass-through access to devices, improving the system's availability, scalability, and maintainability. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0014] Figure 1a A schematic diagram of the structure of a computer device provided for an exemplary embodiment of this application;

[0015] Figure 1b A schematic diagram illustrating a first user-state driven hot upgrade process provided as an exemplary embodiment of this application;

[0016] Figure 1c This is a schematic diagram of the function interface structure of a routing module provided in another exemplary embodiment of this application;

[0017] Figure 1d This is a schematic diagram of the function structure of a first driving module provided in another exemplary embodiment of this application;

[0018] Figure 1e This is a schematic diagram illustrating a first user-state driven hot upgrade process provided in another exemplary embodiment of this application;

[0019] Figure 1f A schematic diagram of the structure of a first driving system provided for an exemplary embodiment of this application;

[0020] Figure 2a A schematic diagram of the structure of a second drive system provided for an exemplary embodiment of this application;

[0021] Figure 2b This application provides a schematic diagram of the structure of a first driving system and a second driving system sharing an address mapping driver, as provided in an exemplary embodiment.

[0022] Figure 2c A schematic diagram of a first user-mode driven hot upgrade process provided in yet another exemplary embodiment of this application;

[0023] Figure 3a A schematic diagram of the structure of a computer device provided for an exemplary embodiment of this application;

[0024] Figure 3b A schematic diagram illustrating a QAT user-mode driven hot upgrade process provided as an exemplary embodiment of this application;

[0025] Figure 3c A schematic diagram of the structure of a QAT driving system provided for an exemplary embodiment of this application;

[0026] Figure 3d This application provides a schematic diagram of a structure in which QAT driving system and VFIO driving system coexist, as shown in an exemplary embodiment.

[0027] Figure 4 A flowchart illustrating a method for hot-upgrading a driver module, provided as an exemplary embodiment of this application;

[0028] Figure 5 A schematic diagram of the structure of an electronic device provided as another exemplary embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0031] Figure 1a This is a schematic diagram of the structure of a computer device provided for an exemplary embodiment of this application. For example... Figure 1a As shown, the computer device 10 includes: a host machine 11, which can be any electronic device with computing, storage, and communication functions, such as computers, mobile phones, tablets, and other terminal devices, or traditional servers, cloud servers, server clusters, or workstations, without limitation. The host machine 11 includes a hardware layer 12, which includes various hardware devices, including a target hardware device 13. The target hardware device 13 refers to a user-mode hardware device that can directly connect to the host machine, and the type of target hardware device is not limited, such as including but not limited to NIC (Network Interface Card), GPU (Graphics Processing Unit), and storage media. The target hardware device can be interconnected with the host machine's CPU via a PCI (Peripheral Component Interconnect) bus or a PCIe (Peripheral Component Interconnect Express) bus. In this case, the target hardware device can also be referred to as a PCI device.

[0032] In this embodiment, the host machine 11 includes a kernel mode 14 and a user mode 15 above the hardware layer 12. In some embodiments of this application, the host machine's user mode 15 is referred to as the host machine's user space, and the host machine's kernel mode 14 is referred to as the host machine's operating system.

[0033] In this embodiment, the host machine includes a virtualization manager 16, which includes a virtualization management component 161 located in the host machine's user space 15 and a kernel-mode virtualization management component 162 located in the host machine's kernel space 14. The kernel-mode virtualization management component 162 enables the host machine's operating system to act as a virtual machine monitor and, in conjunction with the user-mode virtualization management component 161 located in the host machine's user space 15, provides a complete virtualization solution.

[0034] This embodiment does not limit the specific implementation of the kernel-mode virtualization management component 162 and the user-mode virtualization management component 161. For example, it can be implemented as a combination of kernel-mode KVM (Kernel-based Virtual Machine) and user-mode QEMU (Quick EMUlator), but is not limited to this. KVM is an open-source virtualization technology that can transform the kernel of the host operating system into a virtualization manager, providing virtualized instances with capabilities such as CPU virtualization and memory management. KVM can utilize hardware virtualization technology to improve the performance of virtualized instances. QEMU is a user-mode virtualization software, and KVM relies on QEMU to emulate hardware devices, such as virtual network cards, virtual disk controllers, etc.

[0035] In this embodiment, the virtualization manager allows users to run multiple virtualization instances on top of the host operating system and perform various management functions on the virtualization instances, including but not limited to: creating, pausing, starting, and shutting down. Figure 1a This example uses virtualized instances 1 through N as examples, where N is greater than 1 and is a natural number. This embodiment does not limit the number of virtualized instances, nor does it limit the type of virtualized instances; for example, it can be, but is not limited to, ECS (Elastic Compute Service), VM (Virtual Machine), containers, or container groups.

[0036] In this embodiment, based on passthrough technology, the target hardware device 13 of the host machine 11 is directly mapped to the virtualization instance for direct use by the virtualization instance. That is to say, through passthrough technology, the virtualization instance can directly access the target hardware device 13 of the host machine 11 through the virtualization manager 16, thereby avoiding the simulation and filtering by the virtualization manager 16 and reducing performance loss.

[0037] It should be noted that, in this embodiment, the granularity of access from the target pass-through device to the host machine in user mode is not limited. For example, it can be at the virtualization instance level: the target pass-through device acts as the pass-through device for the entire virtualization instance. Another example is at the process level: the target pass-through device acts as the pass-through device for a process running in user mode; yet another example is at the process level within the virtualization instance: the target pass-through device acts as the pass-through device for a process running within the virtualization instance.

[0038] In this embodiment, VFIO (Virtual Function I / O) technology can be used, but is not limited to, to achieve pass-through to the target hardware device. For example, such as Figure 1a As shown, SR-IOV (Single Root I / O Virtualization) passthrough technology can be used, but is not limited to. SR-IOV supports virtualizing multiple VF (Virtual Function) instances from the physical function (PF) of a target hardware device. The PF is the main function of the target hardware device, and the VF is a virtual instance of the PF. The process of virtualizing VFs from the PF includes the virtualization of the PF's base address register (BAR), configuration space (Config), and interrupt vector table (MSI-X). Each virtualized VF has its own BARs, Config, and MSI-X. Furthermore, multiple VFs can be assigned to different virtualization instances. In the process of hardware passthrough based on SR-IOV, a corresponding VF driver is implemented in the virtualization instance; and a corresponding PF driver is implemented in the host machine's kernel mode.

[0039] like Figure 1a As shown, the PF function of the target hardware device 13 is virtualized into VF1-VFm, where m is greater than 1 and m is a natural number. Further, the PF function includes PF BARS, PF Config, and PF MSI-X. Each VF function virtualized by the PF function has its own VF BARS, VF Config, and VF MSI-X. For example, VF1 includes VF1 BARS, VF1 Config, and VF1 MSI-X, and VFm includes VFm BARS, VFm Config, and VFm MSI-X. VF1 is then passed through to virtualization instance 1, and VFm is passed through to virtualization instance N.

[0040] In the process of achieving pass-through to the target hardware device, the host machine's kernel mode provides a driver system (also known as a driver framework) suitable for the target hardware device. Based on this, this application provides a new user-mode driver system for achieving device pass-through, namely the first driver system 17. The first driver system 17 can safely expose the I / O, interrupt, DMA (Direct Memory Access) capabilities of the target hardware device to the user space, and then pass-through the target hardware device to the virtualization instance in the user space.

[0041] The first driver system 17 includes at least a first user-mode driver 18, which is a unified encapsulation of the driver for the target hardware device and can work with the virtualization instance to directly access the target hardware device on the host machine. Optionally, the first driver system 17 also includes a first address mapping driver 19, which is an encapsulation of the IOMMU (Input / Output Memory Management Unit) driver and is used to map the virtual memory address used by the target hardware device to a physical memory address during the direct access of the target hardware device by the virtualization instance. Optionally, the first driver system 17 also includes a first driver interface 110, which provides an interface for accessing the first user-mode driver 18 and the first address mapping driver 19, at least to the user space (such as the virtualization instance) of the host machine.

[0042] In this embodiment, to ensure uninterrupted service during kernel module updates and vulnerability fixes, thereby improving system availability, the driver modules within the first driver system support hot upgrade functionality. Hot upgrade refers to independently upgrading the driver modules within the first driver system without shutting down the host kernel, thus ensuring high system availability. In this embodiment, the driver modules eligible for hot upgrades within the first driver system are not limited; for example, they can be hot-upgraded from the first user-mode driver, the first address mapping driver, or the first driver interface. Subsequent embodiments of this application focus on the hot upgrade of the first user-mode driver. It should be noted that while this embodiment focuses on the hot upgrade of the first user-mode driver, methods for hot-upgrading other driver modules within the first driver system can refer to the hot upgrade method for the first user-mode driver provided in this embodiment. Details can be found in the following embodiments.

[0043] In this embodiment, the first user-space driver includes the functional functions required to achieve device pass-through. The first user-space driver is split into a routing module and a driver module. The routing module implements the function interface of the functional functions, and the driver module is responsible for the code implementation of the functional functions. By exposing the function interface to the virtualization instance and pointing to the code implementation in the driver module, the virtualization instance can achieve device pass-through access through the function interface. Since the code implementation of the functional functions and the function interface for external access are decoupled, and by controlling the function interface to always point to the currently effective driver module, hot upgrades of the user-space driver can be completed without the virtualization instance's awareness. The entire hot upgrade process does not affect the virtualization instance's pass-through access to the device, improving the system's availability, scalability, and maintainability.

[0044] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0045] based on Figure 1a The structure of the computer device shown illustrates the hot-upgrade function of the first user-mode driver in the first driver system. The first user-mode driver includes at least one function, each function implementing a specific function, with different functions implementing different functions. In this embodiment, the function of the first user-mode driver is used to directly connect the target hardware device of the host machine to the virtualization instance. To achieve hot-upgrade of the first user-mode driver, the code implementation of the function and the function interface provided by the function are decoupled. The code implementation of the function refers to the program code required to implement the corresponding function; the program code is equivalent to the entity of the function (having attributes and behaviors), and it resides in the driver module. The function interface refers to the interface required by external objects (mainly the virtualization instance or various processes and programs within the virtualization instance) to access the function; the function interface is more like a signature of the function, without attributes or behaviors, and it resides in the routing module. By exposing function interfaces to virtualization instances, these instances can access corresponding functionalities through these interfaces. Furthermore, decoupling the code implementation of the functionalities from the function interfaces allows for hot upgrades of the code implementation. Moreover, by assigning routing capabilities to the function interfaces, they can route virtualization instances' access requests to either the driver module before or after the hot upgrade, without affecting the normal operation of the virtualization instances. In short, the function interface points to the currently active driver module; before a hot upgrade, the active driver module is the one prior to the hot upgrade, and after a hot upgrade, the active driver module is the one following the hot upgrade.

[0046] Based on the above, such as Figure 1bAs shown, in this embodiment, the first user-mode driver 18 is divided into a routing module 21 and a first driver module 22, and the first driver module 22 can be hot-upgraded to the second driver module 23. Hot-upgrading of the first user-mode driver 18 mainly refers to hot-upgrading the first driver module 22 to the second driver module 23. In this embodiment, for ease of distinction, the driver module before hot-upgrading is referred to as the first driver module 22, and the driver module after hot-upgrading is referred to as the second driver module 23. The first driver module 22 and the second driver module 23 are different code implementations of at least one functional function. It can be understood that, relative to the first driver module 22, the second driver module 23 can upgrade, optimize, or simplify one or more functional functions, specifically by adding, deleting, and / or modifying the code implementation of the functional functions, without limitation. Optionally, after the first driver module 22 is hot-upgraded to the second driver module 23, the first driver module 22 can be deleted or unloaded from the host machine's kernel state. With the deletion or unloading of the first driver module 22, the data generated by the first driver module during its operation will also be deleted.

[0047] In this embodiment, the routing module 21 implements at least one function interface corresponding to each functional function. A function interface refers to an interface exposed to the outside world for accessing that functional function. In this embodiment, the function interface is given routing functionality; that is, the routing module 21 exposes the function interface to the user-space virtualization instance. When the virtualization instance accesses a certain function interface, the function interface can redirect the access request to the corresponding functional function within the currently active driver module, thereby enabling the virtualization instance to directly access the target hardware device of the host machine.

[0048] like Figure 1c The diagram shown is a schematic representation of the function interface structure of a routing module provided in this embodiment. It should be understood that, for ease of description, Figure 1c The function interface structure of the routing module in [the document] is an example of a function interface structure for a routing module, and this example is a simplified one, merely an expression of the function interface structure; that is to say, Figure 1c The function interface structure of the routing module shown does not limit the function interface structure of the routing module in this embodiment.

[0049] further, Figure 1c This includes examples corresponding to function interfaces 24, 25, and 26, which correspond to vf_save_fops, vf_resume_fops, and vf_pci_mig_fops, respectively. The code implementation of the function corresponding to each function interface is in the driver module. In this embodiment, the implementation is not limited to... Figure 1cThe diagram shows the functionality and code implementation of the functions corresponding to the function interfaces vf_save_fops, vf_resume_fops, and vf_pci_mig_fops. Optionally, as shown... Figure 1c As shown, the routing module can also include code implementations for hot upgrades.

[0050] like Figure 1d The diagram shown illustrates the function structure and code implementation of each functional function included in the first driving module 22. For ease of description, Figure 1d The function structure of the first driving module in the example is merely an example, an expression of the function structure of the functional function, and does not constitute a limitation on the function structure of the first driving module in the embodiments of this application. Figure 1d The original intention was to provide examples of the code implementations of the functional functions corresponding to function interfaces 24, 25, and 26. However, in order not to constitute a limitation on this solution, Figure 1d The specific code implementation of these functionalities is not shown; only a brief description is provided in text. The functional function corresponding to each function interface can be indexed by its corresponding function name. For the function structure of the second driver module 23, please refer to the schematic diagram of the function structure of the first driver module.

[0051] In this embodiment, before the hot upgrade, the control function interface of the routing module 21 points to the first driver module 22; after the hot upgrade, the control function interface points to the second driver module 23. After the hot upgrade, when a virtualization instance accesses a function interface in the routing module 21, that function interface can redirect the access request to the corresponding function in the second driver module 23. This allows the virtualization instance to directly access the target hardware device through the function interface of the routing module 21 before and after the hot upgrade, thereby improving system availability.

[0052] In this embodiment, the first user-space driver is split into a routing module and a driver module. The routing module implements the function interface of the functional functions, while the driver module is responsible for the code implementation of the functional functions. By exposing the function interface to the virtualization instance and pointing it to the code implementation in the driver module, the virtualization instance can achieve pass-through access to the device through the function interface. Since the code implementation of the functional functions and the function interface for external access are decoupled, and by controlling the function interface to always point to the currently active driver module, hot upgrades of the user-space driver can be completed without the virtualization instance's awareness. The entire hot upgrade process does not affect the virtualization instance's pass-through access to the device, thereby improving the system's availability, scalability, and maintainability.

[0053] In various embodiments of this application, when performing a hot upgrade on the first driver module, it can be first determined whether the hot upgrade conditions are met; if the hot upgrade conditions are met, the hot upgrade is performed. In this embodiment, the hot upgrade conditions are not limited. In an optional embodiment, the hot upgrade conditions include a first hot upgrade condition and a second hot upgrade condition. The first hot upgrade condition is that the first driver module is in an idle state; the second hot upgrade condition is that the second driver module is loaded. The first hot upgrade condition is set so that hot upgrades are not performed while the first driver module is in use, thereby ensuring that services from other kernel modules or user processes are not interrupted and improving system availability. Therefore, if it is determined that the first driver module is in an idle state, the first hot upgrade condition is considered met. Furthermore, the second hot upgrade condition is set to ensure a smooth hot upgrade from the first driver module to the second driver module. If the second driver module is loaded into the host machine's kernel state, the second hot upgrade condition is considered met. Accordingly, one implementation method for determining whether the hot upgrade conditions are met includes: determining whether the first driver module is in an idle state, and determining whether the second driver module has been loaded into the kernel state of the host machine; when the first hot upgrade conditions and the second hot upgrade conditions are met, the first user-mode driver can be hot-upgraded.

[0054] To determine whether the first driving module is in an idle state, the following two implementation methods can be used, but are not limited to:

[0055] In one optional implementation, to prevent hot upgrades from being triggered when the first driver module is accessed by other kernel modules or user processes, a read-write lock protection mechanism is introduced for the first driver module. This allows multiple concurrent read operations but prohibits simultaneous write operations; in other words, read and write operations are mutually exclusive for the first driver module. Based on this, in this embodiment, a read lock can be allocated to the first driver module when it is accessed externally. The first driver module with a read lock is simultaneously prohibited from write operations, i.e., hot upgrade processing is also prohibited. This ensures that the routing module's function interface points to the currently active driver module, thereby guaranteeing the consistency of the function interface. Furthermore, during the hot upgrade process of the first driver module, a write lock can be allocated to it, preventing access until the hot upgrade is complete.

[0056] In this embodiment, the granularity of allocating read locks to the first driver module is not limited. For example, read locks can be allocated at the driver module level, directly assigning read locks to the first driver module. The first driver module includes at least one function. When any function is accessed, a read lock is allocated to the first driver module to prevent other operations from being performed on it. Correspondingly, if no function is accessed within the first driver module, the read lock on the first driver module can be released.

[0057] Alternatively, read locks can be allocated at the granularity of function calls within the driver module, assigning read locks to the accessed function call. That is, when any function call is accessed, a corresponding read lock can be assigned to that function. In this case, if any function call within the first driver module holds a read lock, the first driver module is considered to hold a read lock; if no function call within the first driver module holds a read lock, the first driver module is considered not to hold a read lock.

[0058] Alternatively, assigning a read lock to a function can also involve assigning a corresponding read lock to the function interface corresponding to the function. For example, if a read lock is assigned to each function interface, it can be identified whether each function interface holds a read lock. If any function interface holds a read lock, it is considered that the first driver module holds a read lock; if no function interface holds any read lock, it can be determined that the first driver module does not hold a read lock.

[0059] In any of the above methods of allocating read locks, if it is determined that the first driving module does not hold a read lock, it means that the first driving module is in an idle state; conversely, if it is determined that the first driving module holds a read lock, it means that the first driving module is in a used state (i.e., not idle).

[0060] In another alternative embodiment, reference counting can be used to determine whether the first driver module is in an idle state. For example, in the initial state, the access count value for the first driver module can be 0. Whenever a function in the first driver module is accessed, the access count value is incremented by 1; whenever an access to a function in the first driver module ends, the access count value is decremented by 1. Thus, when the access count value is 0, the first driver module can be considered to be unaccessed, i.e., in an idle state.

[0061] Furthermore, to determine that the second drive module meets the second hot upgrade conditions, the following two implementation methods can be adopted, but are not limited to.

[0062] In one optional implementation, the kernel module, upon being loaded into the host machine's kernel state, registers with the routing module; that is, the routing module can detect that the kernel module has been loaded into the kernel state. Based on this, an optional implementation for the routing module to determine that the second driver module has been loaded into the host machine's kernel state includes: upon receiving registration information from the second driver module, the routing module determines that the second driver module has been loaded into the host machine's kernel state.

[0063] In another alternative embodiment, the host machine's kernel state includes a management module. This management module coordinates and manages other kernel modules. It is able to detect whether the second driver module has been loaded into the kernel state and sends a notification message to the routing module. Upon receiving this notification message, the routing module can determine that the second driver module has been loaded into the host machine's kernel state.

[0064] Furthermore, under the condition of hot upgrade, the first driver module is hot-upgraded to the second driver module. The hot upgrade process is essentially changing the control function interface from pointing to the first driver module to pointing to the second driver module. Specifically, the first pointing relationship between the function interface in the routing module and the first driver module is first terminated. The first pointing relationship is used to redirect virtualization instance access requests to the function interface to the corresponding function in the first driver module for processing. Then, a second pointing relationship is established between the function interface in the routing module and the second driver module to complete the hot upgrade of the first driver module. The second pointing relationship is used to redirect virtualization instance access requests to the function interface to the corresponding function in the second driver module for processing. Both the first and second driver modules are code implementations of the function functions required for direct access from the target hardware device to the virtualization instance. Therefore, before and after the hot upgrade, the virtualization instance can directly access the target hardware device through the function interface, thus ensuring high system availability.

[0065] In this embodiment, the method of changing the control function interface from pointing to the first driver module to pointing to the second driver module is not limited. In an optional embodiment, the method of changing the structure variable pointer can be adopted. The routing module includes a structure variable pointer corresponding to the function interface, and the structure variable pointer is used to point to the currently effective driver module. During the process of changing the structure pointer, the structure variable pointer is updated from pointing to the structure variable of the first driver module to pointing to the structure variable of the second driver module, thereby establishing a second pointing relationship between the function interface and the second driver module.

[0066] In some optional embodiments, static data variables are declared in the routing module, not in the code implementation of the driver module. These static data variables can be considered global variables, meaning they do not change with changes in the code implementation, unlike variables declared in the code implementation. Before a hot upgrade, these static data variables may be referenced by the first driver module. To ensure that these static data variables are not lost or destroyed after the hot upgrade, it is necessary for the second driver module to inherit them. One possible way to allow the second driver module to inherit the static data variables referenced by the first driver module is to register the address pointers of the static data variables referenced by the first driver module in the routing module during the registration process of the first driver module. Here, the address pointer refers to the memory address of the variable value generated by the static data variable during the operation of the first driver module. By registering this address pointer in the routing module, these address pointers will not disappear when the first driver module is unloaded. Therefore, after the hot upgrade, the second driver module can inherit the static data variables referenced by the first driver module, thus ensuring that the static data variables before and after the hot upgrade are not lost or destroyed.

[0067] In this embodiment, the kernel modules in the host machine's kernel mode, excluding the first driver module, have function dependencies on the first user-mode driver. Optionally, to ensure the normal operation of other kernel modules, the function interface of the target function can be symbolically exported to other kernel modules for use, based on the function dependencies corresponding to the first user-mode driver. The target function is a function referenced by other kernel modules among at least one function functions within the first user-mode driver. One implementation of symbolically exporting the function interface of the target function to other kernel modules includes: adding a function for exporting symbols (referred to as a symbol export function) for the function interface of the target function. When the symbol export function is executed, it automatically exports the function interface of the target function to other kernel modules symbolically. The specific implementation of this symbol export function will vary depending on the host machine's operating system. For example, in some operating systems, this symbol export function can be implemented as EXPORT_SYMBOL, but it is not limited to this. EXPORT_SYMBOL is a macro used to export symbols so that they can be used in other kernel modules.

[0068] Optionally, the host machine's kernel provides an operation interface for users, through which users can adjust the hot upgrade logic. The operation interface provided in this embodiment can be a virtual file system, the purpose of which is to provide a method for accessing kernel data structures, thereby allowing user-mode programs / processes to view and control system devices and resources. In this embodiment, the focus is on facilitating user adjustments to the hot upgrade logic.

[0069] The above embodiments describe the hot upgrade process for the first user-space driver. The hot upgrade process will now be described in conjunction with the specific structural implementations of the routing module and driver module. It should be understood that the specific structural implementations of the routing module and driver module given below are merely examples and do not constitute a limitation on this embodiment.

[0070] like Figure 1e As shown, the example uses routing module 21, which includes multiple function interfaces, but is not limited to this. Routing module 21 includes function interface 24, function interface 25, and function interface 26, and sets corresponding read lock protection for the function corresponding to each function interface. Combined with... Figure 1c The provided function interfaces and examples of setting corresponding read lock protection for each function interface's corresponding function are explained. Figure 1c This includes examples corresponding to function interfaces 24, 25, and 26, which correspond to `vf_save_fops`, `vf_resume_fops`, and `vf_pci_mig_fops`, respectively. Each function interface has its own structure. Further, taking `vf_save_fops` as an example, in the locking example corresponding to `vf_save_fops`, when an external application accesses the function interface `vf_save_fops` in the currently active driver module, a read lock will be allocated to that function interface. For example, a function statement like "lock reader" can be used. Once the access to the function corresponding to that interface is complete, a function statement like "unlock reader" can be used to release the corresponding read lock. The process of allocating read locks for `vf_resume_fops` and `vf_pci_mig_fops` is similar to that for `vf_save_fops`, and will not be repeated here. The currently active driver module can be represented by a structure variable pointer `cur_impl`.

[0071] Based on a read lock protection mechanism, multiple concurrent read operations are supported. For each function interface, a read operation corresponding to a function can trigger the allocation of a corresponding read lock. When a function holds a read lock, the first driving module is considered to be in an occupied state. This continues until all read locks held by the function interfaces are released, at which point the first driving module is considered to be in an idle state. Furthermore, the routing module also includes a structure variable pointer 27 (such as...). Figure 1c In the cur_impl structure, the pointer 27 is used to point to the currently active driver module. As the driver module is hot-upgraded, the driver module pointed to by the pointer 27 will change.

[0072] In this embodiment, the first driving module 22 and the second driving module 23 are implemented as different structure variables. In one example, such as... Figure 1e The diagram shown illustrates the function structure of the structure variables of the first driving module 22 and the second driving module 23. (Combined with...) Figure 1d The first driving module is illustrated with an example, such as... Figure 1d The example shown includes function interfaces 24, 25, and 26, corresponding to vf_save_fops, vf_resume_fops, and vf_pci_mig_fops, respectively. The names of these function interfaces can be the same as the names of their corresponding function interfaces. Each function interface includes the same structure as its function interface. Figure 1d (as shown in the image) and the specific code implementation ( Figure 1d (Not shown in the image).

[0073] Since the function structures of the structure variables of the second driving module 23 and the structure variables of the first driving module 22 are similar, the following description will use the function structure of the structure variables of the first driving module 22 as an example. Figure 1e As shown, the structure variables of the first driving module 22 include the names of the function functions of function interface 24, function interface 25, and function interface 26. Furthermore, before hot upgrades, the structure variable pointer 27 corresponding to the function interface of the routing module 21 accesses the function functions within the first driving module 22 by pointing to their names. For example, the function functions of function interface 24 are accessed by pointing to their names. The access methods for the function functions corresponding to function interfaces 25 and 26 are similar to those for function interface 24 and will not be repeated here.

[0074] If any function corresponding to a function interface is accessed, a corresponding read lock can be assigned to that function. If any function within the first driver module holds a read lock, hot upgrade processing of the first driver module is prohibited until no function within the first driver module holds any read locks, at which point hot upgrade of the first driver module can be performed. Optionally, the code implementation for hot upgrade can be implemented in the routing module. In an example of the hot upgrade code implementation, a locking function like `lock writer()` can be used to assign a write lock to the first driver module, preventing access to it. Furthermore, in this hot upgrade code function, a function statement like `if cur_impl != tmp` can be used to indicate that the current structure variable pointer `cur_impl` does not point to the second driver module, and `tmp` is a temporary pointer used to point to the second driver module to be upgraded to. Further, in this function, an assignment statement can be used to assign `tmp` to `cur_impl`, making the structure variable pointer point to the second driver module, making the second driver module the currently effective driver module, thus completing the hot upgrade. Finally, an unlocking function like `unlockwriter()` can be used to release the write lock after the hot upgrade is complete. Here it is noted that, regarding Figure 1c and Figure 1d The code examples provided are for illustrative purposes only and do not constitute further explanation or limitation.

[0075] Furthermore, in this embodiment, the hot upgrade from the first driver module 22 to the second driver module 23 can be viewed as updating the structure variable pointer 27 of the routing module 21 from pointing to the structure variable of the first driver module 22 to pointing to the structure variable of the second driver module 23, thereby establishing a second pointing relationship between the function interface and the second driver module 23 to complete the hot upgrade. This second pointing relationship is used to redirect the virtualization instance's access requests to the function interface to the corresponding function in the second driver module for processing.

[0076] In the above embodiments, the hot upgrade process of the first user-mode driver in the first driving system was described. Furthermore, based on the above-described content related to the first user-mode driver, the structure of the first driving system is described.

[0077] Figure 1f This is a schematic diagram of the structure of a first driving system provided for an exemplary embodiment of this application. (See diagram below.) Figure 1f As shown, the first driver system 17 includes at least a first user-mode driver 18. The first user-mode driver 18 is a unified encapsulation of the driver for the target hardware device, which can work together with the virtualization instance to complete direct access to the target hardware device of the host machine.

[0078] In this embodiment, the first user-space driver 18 includes a routing module 21 and a first driver module 22, and the first driver module 22 can be hot-upgraded to a second driver module 23. The routing module 21 includes a function interface for at least one functional function, and the first driver module 22 and the second driver module 23 are different code implementations of the at least one functional function, which is used to pass through the target hardware device of the host machine to the virtualization instance.

[0079] In this embodiment, the routing module 21 is used to control the function interface to point to the first driver module 22 before the hot upgrade, and to point to the second driver module 23 after the hot upgrade, and to expose the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device 13 through the function interface before and after the hot upgrade.

[0080] Optionally, such as Figure 1f As shown, the first driver system further includes a first address mapping driver 19 and a first driver interface 110. The first address mapping driver 19 is used to map the virtual memory address used by the target hardware device to a physical memory address during the process of the virtualization instance directly accessing the target hardware device. The first driver interface 110 is used to provide an interface for accessing the first user-mode driver 18 and the first address mapping driver 19, at least for the host machine's user space (such as the virtualization instance).

[0081] Further optional, such as Figure 1f As shown, the first driver system 17 also includes a first hardware device driver 28, which is the driver for the PF function implemented by the target hardware device, i.e., the driver for the target hardware device, and is responsible for managing the resources of the target hardware device. Correspondingly, the first user-mode driver is responsible for exposing the target hardware device to the host machine's user mode, thereby realizing the VF function of the target hardware device.

[0082] Figure 2a This is a schematic diagram of a second driver system provided for an exemplary embodiment of this application. The second driver system 31 is another user-mode driver system for implementing pass-through to the target hardware device. Based on this driver system, the device I / O, interrupt, DMA, and other capabilities of the target hardware device can also be securely presented to the host machine's user space, allowing the virtualized instance in user space to directly access the target hardware device on the host machine. The second driver system 31 is compatible with the first driver system 17, meaning they can coexist in the host machine's kernel mode, or one can be used selectively. The main difference between the second driver system 31 and the first driver system 17 is that the second driver system 31 does not support hot upgrades. The following section, in conjunction with the appendix... Figure 2a The second drive system will be introduced.

[0083] like Figure 2aAs shown, the second driver system 31 includes: a second user-mode driver 32, a second address mapping driver 33, and a second driver interface 34. The second user-mode driver 32 is used to pass through the target hardware device 13 of the host machine 11 to the virtualization instance, enabling the virtualization instance to directly access the target hardware device 13. The second user-mode driver 32 needs to be upgraded while the system is offline. The second address mapping driver 33 is used to map the virtual memory address used by the target hardware device 13 to a physical memory address during the process of the virtualization instance directly accessing the target hardware device 13. The second driver interface 34 is used to provide an interface for the virtualization instance to access the second user-mode driver 32 and the second address mapping driver 33.

[0084] Optionally, the second driver system 31 further includes a second hardware device driver 35, which is the driver for the PF function implemented by the target hardware device, i.e., the driver for the target hardware device, and is responsible for managing the resources of the target hardware device. Correspondingly, the second user-mode driver is responsible for exposing the target hardware device to the host machine's user mode, thereby realizing the VF function of the target hardware device.

[0085] Regarding the implementation method of enabling the target hardware device 13 to pass through to the virtualization instance, the first driver system 17 can be selected; or the second driver system 31 can be selected, without any restriction.

[0086] Further optionally, the first drive system 17 and the second drive system 31 can reuse the address mapping drive, such as Figure 2b The diagram illustrates the reuse of the address mapping driver 36 by the first driver system 17 and the second driver system 31. Reusing the address mapping driver reduces code development costs. Optionally, the first driver system 17 can reuse the existing address mapping driver 36 in the second driver system 31, thereby reducing the code development cost of the first driver system 17.

[0087] Furthermore, such as Figure 2c The diagram shown illustrates the hot-upgrade process of the first user-mode driver in the first driving system. The upgrade process for the first user-mode driver can be found in the foregoing embodiments and will not be repeated here.

[0088] In the above embodiments, the first driver system provided in this application and the hot upgrade process of the first user-mode driver in the first driver system are described in detail. The first driver system can be used to pass through any type of PCI device to the virtualization instance of the host machine. In some application scenarios, the motherboard where the host machine's processor is located includes a QAT (Quick Assist Technology) device. QAT is a hardware acceleration technology launched for network security and data storage. In terms of network security applications, QAT supports symmetric data encryption (such as AES), asymmetric public-key encryption (such as RSA, elliptic curves, etc.), and data integrity (SHA1 / 2 / 3, etc.), accelerating data encryption, decryption, and digital signature operations. In terms of data compression, QAT supports DEFLATE (a lossless compression algorithm) and LZ4 (a lossless compression algorithm) data compression and decompression algorithms. Using QAT can significantly accelerate data compression and decompression, improving data processing throughput and latency.

[0089] In this scenario, to enable users to use QAT devices normally within the virtualization instance, a first driver system is used to expose the QAT devices to the virtualization instance. In this scenario, the first driver system can also be called the QAT driver system, suitable for passing QAT devices directly to the virtualization instance. The QAT driver system also supports hot upgrades, which can be implemented by referring to the hot upgrade process of the first driver system. This improves the scalability and maintainability of the virtualization instance, as well as the maintainability of the QAT device driver module code, and ensures that hot upgrades of the QAT device driver module do not affect the existing functionality and performance of the virtualization instance. The following is based on... Figure 1b The structure of the computer equipment, combined with the attached Figures 3a-3b This section introduces the QAT driver system.

[0090] Figure 3a This is a schematic diagram of a computer device provided for an exemplary embodiment of this application. The QAT device refers to a hardware device that can directly access the host machine's user-mode interface. The QAT device can interconnect with the host machine's processor via the PCI bus.

[0091] In this embodiment, based on passthrough technology, the QAT device 43 of the host machine 11 is directly mapped to the virtualization instance for direct use by the virtualization instance. That is to say, through passthrough technology, the virtualization instance can directly access the QAT device 43 of the host machine 11 through the virtualization manager 16, thereby avoiding the emulation and filtering by the virtualization manager 16 and reducing performance loss.

[0092] In this embodiment, as Figure 3aAs shown, SR-IOV passthrough technology can be used, but is not limited to, in which PF function is the main function of QAT device, and VF function is a virtualized functional instance derived from PF function. In the process of implementing hardware passthrough based on SR-IOV, the VF driver of QAT device is implemented in the virtualization instance; and the PF driver of QAT device is implemented in the kernel mode of the host machine.

[0093] In this embodiment, during the process of implementing QAT device passthrough, the QAT driver system 47 provided by the host machine kernel is relied upon. The QAT driver system 47 can safely expose the I / O, interrupt, DMA (Direct Memory Access) capabilities of the QAT device to the user space, and then passthrough the QAT device to the virtualization instance in the user space.

[0094] The QAT driver system 47 includes at least a QAT user-space driver 48. The QAT user-space driver 48 is a unified encapsulation of the QAT device driver, which can work with the virtualization instance to directly access the host machine's QAT device. Optionally, the QAT driver system 47 also includes a QAT address mapping driver 49. The QAT address mapping driver 49 is an encapsulation of the IOMMU driver, used to map the virtual memory address used by the QAT device to a physical memory address during direct access to the QAT device by the virtualization instance. Optionally, the QAT driver system 47 also includes a QAT driver interface 410, used to provide an interface for accessing the QAT user-space driver 48 and the QAT address mapping driver 49, at least to the host machine's user space (such as the virtualization instance).

[0095] like Figure 3b As shown, in this embodiment, the QAT user-space driver is divided into a QAT routing module 51 and a first QAT driver module 52, and the first QAT driver module 52 can be hot-upgraded to a second QAT driver module 53. Hot-upgrading of the QAT user-space driver mainly refers to hot-upgrading the first QAT driver module 52. In this embodiment, for ease of distinction, the driver module included in the QAT user-space driver before the hot upgrade is referred to as the first QAT driver module 52, and the driver module included in the QAT user-space driver after the hot upgrade is referred to as the second QAT driver module 53. The first QAT driver module 52 and the second QAT driver module 53 are different code implementations of at least one functional function, which is used to pass through the host machine's QAT device to the virtualization instance. It is understood that, compared to the first QAT driver module 52, the second QAT driver module 53 may upgrade, optimize, or simplify the functionality of at least one functional function, for example, by adding, deleting, and / or modifying the code of at least one functional function.

[0096] Furthermore, the QAT routing module 51 implements a function interface corresponding to at least one function. The function interface refers to the access interface of the function exposed to the outside world. The QAT routing module 51 exposes the function interface to the virtualization instance so that when the virtualization instance accesses the function interface, it can be directed to the function in the currently effective QAT driver module to achieve direct access to the QAT device of the host machine.

[0097] In this embodiment, before the hot upgrade, the QAT routing module 51 controls the function interface to point to the first QAT driver module 52. Furthermore, by redirecting the access of the function interface in the QAT routing module 51 to the first QAT driver module 52 to the second QAT driver module 53, when accessing the function interface of the QAT routing module 51, it can be redirected to the corresponding function in the second QAT driver module 53. This allows the virtualization instance to directly access the QAT device through the function interface of the QAT routing module 51 before and after the hot upgrade, thereby realizing the hot upgrade of the first QAT driver module 52.

[0098] Further optional, such as Figure 3c As shown, the QAT driver system 47 also includes a QAT PF driver 411, which is the driver for the PF function, i.e., the driver for the target hardware device, and is responsible for managing the resources of the target hardware device. Based on the QAT PF driver 411, the target hardware device interconnected with the PCI bus can implement the PF function, thereby providing support for the VF function. Correspondingly, the QAT user-space driver 48 is responsible for exposing the target hardware device to the host machine's user space, thereby implementing the VF function.

[0099] Further optionally, the second driver system in this embodiment can be implemented as a VFIO driver system. A VFIO driver system is a pass-through system for target hardware devices. Based on this driver system, the device I / O, interrupt, DMA, and other capabilities of the target hardware device can be securely presented to the host machine's user space, allowing the virtualized instance in user space to directly access the host machine's target hardware device. The VFIO driver system can be compatible with the QAT driver system 47, meaning they can coexist in the host machine's kernel mode; alternatively, one can be used. The main difference between the VFIO driver system and the QAT driver system 47 is that the VFIO driver system does not support hot upgrades. The following is a detailed explanation in conjunction with the appendix... Figure 3d The second drive system will be introduced.

[0100] In this embodiment, the VFIO driver system includes: a vfio-pci driver 62, a vfio-iommu driver 63, and a vfio driver interface 61. The vfio-pci driver 62 is a unified encapsulation of the target hardware device driver, used to pass the target hardware device 13 from the host machine 11 directly to the virtualization instance, enabling the virtualization instance to directly access the target hardware device 13. The vfio-pci driver 62 needs to be upgraded while the system is offline. The vfio-iommu driver 63 is an encapsulation of the IOMMU driver, used to map the virtual memory address used by the target hardware device 13 to a physical memory address during the process of the virtualization instance directly accessing the target hardware device 13. The vfio driver interface 61 provides an interface for the virtualization instance to access the vfio-pci driver 62 and the vfio-iommu driver 63.

[0101] Optionally, the VFIO driver system also includes a VFIO PF driver 64. The VFIO PF driver 64 is the driver for the PF function, i.e., the driver for the target hardware device, and is responsible for managing the resources of the target hardware device. Based on the VFIO PF driver 64, the target hardware device interconnected with the PCI bus can implement the PF function, thereby providing support for the VF function. Correspondingly, the vfio-pci driver 62 is responsible for exposing the target hardware device to the host machine's user space, thereby implementing the VF function.

[0102] For the implementation of passing the target hardware device 13 directly to the virtualization instance, the QAT driver system can be selected; or the VFIO driver system can be selected, without any restriction.

[0103] Further optional, such as Figure 3d As shown, the QAT driver system and the VFIO driver system can share the vfio-iommu driver 63, which is a schematic diagram of the QAT driver system and the VFIO driver system sharing the vfio-iommu driver.

[0104] Figure 4 This is a flowchart illustrating a method for hot-upgrading a driver module, provided as another exemplary embodiment of this application. The method is used to hot-upgrade a user-mode driver, which includes a routing module and a first driver module. The first driver module can be hot-upgraded to a second driver module. The routing module includes a function interface for at least one functional function. The first driver module and the second driver module are different code implementations of the at least one functional function. The user-mode driver can be the first user-mode driver described in the above embodiments, but is not limited thereto. Figure 4 As shown, the method includes:

[0105] S401: Before hot upgrade, control the function interface to point to the first driver module;

[0106] S402: The control function interface is changed from pointing to the first driver module to pointing to the second driver module, so as to hot-upgrade the first driver module to the second driver module.

[0107] In this embodiment, the function is not limited to any particular purpose. For example, the function described in the above embodiment may be used to pass through the target hardware device of the host machine to the virtualization instance, but it is not limited to this.

[0108] In an optional embodiment, the aforementioned user-mode driver may be the first user-mode driver in the first driver system of the above embodiments. At least one function is used to pass through the target hardware device of the host machine to the virtualization instance. The virtualization instance runs in the user mode of the host machine, the target pass-through device is located in the hardware layer of the host machine, and the host machine also includes the host machine's kernel mode and user mode. Here, the target hardware device refers to a hardware device that can pass through to the user mode of the host machine. The method further includes: exposing the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device through the function interface before and after a hot upgrade; and, if an access request for the function interface from the virtualization instance is received after a hot upgrade, redirecting the access request to the corresponding function in the second driver module pointed to by the function interface for processing.

[0109] In one optional embodiment, determining that the hot upgrade conditions are met includes: determining that the hot upgrade conditions are met when it is determined that the second driver module has been loaded into the kernel state of the host machine and the first driver module is in an idle state.

[0110] In an optional embodiment, the routing module further includes: a structure variable pointer corresponding to the function interface, the structure variable pointer being used to point to the currently active driver module; wherein the first driver module and the second driver module are implemented as different structure variables; when controlling the function interface to change from pointing to the first driver module to pointing to the second driver module, the method includes: updating the structure variable pointer from the structure variable pointing to the first driver module to the structure variable pointing to the second driver module.

[0111] In an optional embodiment, the method further includes: the routing module declares static data variables, and during the registration process with the routing module, the first driver module registers the address pointer of the static data variables referenced by the first driver module to the routing module, so that the second driver module can inherit the static data variables referenced by the first driver module; and / or, according to the function dependency relationship corresponding to the user-mode driver, the function interface of the target function is exported symbolically to other kernel modules for use, wherein the target function is a function referenced by the other kernel modules among the at least one function, and the other kernel modules are kernel modules in the kernel mode of the host machine that are different from the user-mode driver.

[0112] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0113] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 401 to 402 can be device A; or the execution subject of step 401 can be device A, and the execution subject of step 402 can be device B; and so on.

[0114] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 401, 402, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0115] Figure 5 This is a schematic diagram of the structure of an electronic device provided as another exemplary embodiment of this application. For example... Figure 5 As shown, the electronic device includes a memory 54 and a processor 55.

[0116] Memory 54 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0117] The memory 54 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0118] The processor 55, coupled to the memory 54, is configured to execute a computer program in the memory 54 for: controlling the function interface to point to the first driver module before a hot upgrade; and controlling the function interface to change its pointing point from the first driver module to the second driver module, so as to hot upgrade the first driver module to the second driver module.

[0119] In an optional embodiment, the at least one function is used to pass through the target hardware device of the host machine to the virtualization instance, the virtualization instance running in the user mode of the host machine; the processor 55 is further used to: expose the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade; and, if an access request for the function interface from the virtualization instance is received after hot upgrade, redirect the access request to the corresponding function in the second driver module pointed to by the function interface for processing.

[0120] In an optional embodiment, when the processor 55 determines that the hot upgrade conditions are met, it is specifically configured to: determine that the hot upgrade conditions are met when it is determined that the second driver module has been loaded into the kernel state of the host machine and the first driver module is in an idle state.

[0121] In an optional embodiment, the routing module further includes: a structure variable pointer corresponding to the function interface, the structure variable pointer being used to point to the currently active driver module; wherein the first driver module and the second driver module are implemented as different structure variables; when the processor 55 controls the function interface to change from pointing to the first driver module to pointing to the second driver module, it is specifically used to: update the structure variable pointer from the structure variable pointing to the first driver module to the structure variable pointing to the second driver module.

[0122] In an optional embodiment, the routing module declares static data variables, and the processor 55 is further configured to: register the address pointer of the static data variable referenced by the first driver module to the routing module during the registration process of the first driver module to the routing module, so that the second driver module can inherit the static data variable referenced by the first driver module; and / or, according to the function dependency relationship corresponding to the user-mode driver, export the function interface of the target function symbolically to other kernel modules for use, wherein the target function is a function referenced by the other kernel module among the at least one function, and the other kernel module is a kernel module in the kernel mode of the host machine that is different from the user-mode driver.

[0123] Furthermore, such as Figure 5 As shown, the electronic device also includes other components such as a communication component 56, a display 57, a power supply component 58, and an audio component 59. Figure 5 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 5 The components shown. Additionally... Figure 5 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 5 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, it may be omitted. Figure 5 The component within the dashed box.

[0124] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the methods described above.

[0125] This application also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, enable the processor to implement the steps described in the above method embodiments.

[0126] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0127] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0128] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0129] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0130] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0131] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0132] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0133] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0134] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0135] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0136] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0137] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0138] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0139] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A computer device, characterized in that, include: The host machine has a virtualization instance running in its user space and a first driver system implemented in its kernel space. The first driver system includes at least a first user-space driver, which includes a routing module and a first driver module. The first driver module can be hot-upgraded to a second driver module. The routing module includes a function interface for at least one functional function. The first driver module and the second driver module are different code implementations of the at least one functional function. The at least one functional function is used to pass through the target hardware device of the host machine to the virtualization instance. The routing module is used to control the function interface to point to the first driver module before hot upgrade, and to point to the second driver module after hot upgrade, and to expose the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade.

2. The device according to claim 1, characterized in that, The routing module is specifically used for: If the conditions for hot upgrade are met, the first pointing relationship between the function interface and the first driving module is terminated, and a second pointing relationship between the function interface and the second driving module is established. The second pointer relationship is used to redirect the virtualization instance's access request to the function interface to the corresponding function in the second driver module for processing.

3. The device according to claim 2, characterized in that, The routing module is also used for: If it is determined that the second driver module has been loaded into the kernel state of the host machine and the first driver module is in an idle state, then the hot upgrade condition is satisfied.

4. The device according to claim 3, characterized in that, The routing module determines that the second driver module has been loaded into the host machine's kernel state, including: Upon receiving the registration information of the second driver module, it is determined that the second driver module has been loaded into the kernel state of the host machine; the second driver module registers with the routing module while being loaded into the kernel state of the host machine.

5. The device according to claim 3, characterized in that, The routing module determines that the first driver module is in an idle state, including: If it is detected that the first drive module does not hold any read lock, it is determined that the first drive module is in an idle state; The routing module is further configured to: when it is determined that a function in the first driver module is accessed, allocate a read lock to the first driver module, and reclaim the read lock after the access is completed, so that the first driver module is in an idle state.

6. The device according to claim 2, characterized in that, The routing module further includes: a structure variable pointer corresponding to the function interface, the structure variable pointer being used to point to the currently active driver module; wherein, the first driver module and the second driver module are implemented as different structure variables; The routing module is specifically used to: update the structure variable pointer from a structure variable pointing to the first driver module to a structure variable pointing to the second driver module, so as to remove the first pointing relationship and establish the second pointing relationship.

7. The device according to claim 1, characterized in that, The routing module declares static data variables; The first driver module is further configured to: during the registration process with the routing module, register the address pointer of the static data variable referenced by the first driver module to the routing module, so that the second driver module can inherit the static data variable referenced by the first driver module.

8. The device according to claim 1, characterized in that, The routing module is also used for: Based on the function dependencies corresponding to the first user-mode driver, the function interface of the target function is exported symbolically for use by other kernel modules. The target function is a function referenced by the other kernel modules among the at least one function. The other kernel modules are kernel modules in the kernel mode of the host machine that are different from the first user-mode driver.

9. The device according to any one of claims 1-8, characterized in that, The first drive system also includes: The first address mapping driver is used to map the virtual memory address used by the hardware device to a physical memory address during the process of the virtualization instance directly accessing the hardware device. The first driver interface is used to provide an interface for accessing the first user-mode driver and the first address mapping driver, at least to the virtualization instance.

10. The device according to claim 9, characterized in that, The host machine's kernel state also includes: a second driver system, which includes: The second user-mode driver is used to pass through the hardware devices of the host machine to the virtualization instance, so that the virtualization instance can directly access the hardware devices, and the second user-mode driver can be upgraded in a shutdown state; The second address mapping driver is used to map the virtual memory address used by the hardware device to a physical memory address during the process of the virtualization instance directly accessing the hardware device. The second driver interface is used to provide an interface for accessing the second user-mode driver and the second address mapping driver, at least to the virtualization instance.

11. The device according to claim 10, characterized in that, The first address mapping driver reuses the second address mapping driver.

12. The device according to any one of claims 1-8, characterized in that, The target hardware device is a Quick Assist Technology (QAT) device.

13. A drive system, characterized in that, include: It includes at least a first user-space driver, which includes a routing module and a first driver module, and the first driver module can be hot-upgraded to a second driver module; The routing module includes a function interface for at least one functional function. The first driver module and the second driver module are different code implementations of the at least one functional function. The at least one functional function is used to pass through the target hardware device of the host machine to the virtualization instance. The routing module is used to control the function interface to point to the first driver module before hot upgrade and to point to the second driver module after hot upgrade, and to expose the function interface to the virtualization instance so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade.

14. The drive system according to claim 13, characterized in that, Also includes: The first address mapping driver is used to map the virtual memory address used by the hardware device to a physical memory address during the process of the virtualization instance directly accessing the hardware device. The first driver interface is used to provide an interface for accessing the first user-mode driver and the first address mapping driver, at least to the virtualization instance.

15. The drive system according to claim 14, characterized in that, The host machine's kernel state also includes: a second driver system, which includes: The second user-mode driver is used to pass through the hardware devices of the host machine to the virtualization instance, so that the virtualization instance can directly access the hardware devices, and the second user-mode driver needs to be upgraded in a shutdown state; The second address mapping driver is used to map the virtual memory address used by the hardware device to a physical memory address during the process of the virtualization instance directly accessing the hardware device. The second driver interface is used to provide an interface for accessing the second user-mode driver and the second address mapping driver, at least to the virtualization instance.

16. A method for hot-upgrading a driver module, characterized in that, For hot-upgrading a user-mode driver, the user-mode driver includes a routing module and a first driver module, the first driver module being hot-upgradeable to a second driver module, the routing module including a function interface for at least one functional function, the first driver module and the second driver module being different code implementations of the at least one functional function, the method including: Before hot upgrade, the function interface is controlled to point to the first driver module; the function interface is then controlled to change from pointing to the first driver module to pointing to the second driver module, so as to hot upgrade the first driver module to the second driver module.

17. The method according to claim 16, characterized in that, The at least one function is used to pass through the target hardware device of the host machine to the virtualization instance, the virtualization instance running in the user space of the host machine; The method further includes: exposing the function interface to the virtualization instance, so that the virtualization instance can directly access the target hardware device through the function interface before and after hot upgrade; and If an access request for the function interface from the virtualization instance is received after a hot upgrade, the access request is redirected to the corresponding function in the second driver module pointed to by the function interface for processing.

18. The method according to claim 16, characterized in that, The routing module further includes: a structure variable pointer corresponding to the function interface, the structure variable pointer being used to point to the currently active driver module; wherein, the first driver module and the second driver module are implemented as different structure variables; Controlling the function interface to change its pointer from the first driver module to the second driver module includes: The structure variable pointer is updated from pointing to the structure variable of the first driver module to pointing to the structure variable of the second driver module.

19. The method according to any one of claims 16-18, characterized in that, The method further includes: The routing module declares static data variables. During the registration process with the routing module, the first driver module registers the address pointer of the static data variable referenced by the first driver module into the routing module, so that the second driver module can inherit the static data variable referenced by the first driver module. and / or Based on the function dependencies corresponding to the user-mode driver, the function interface of the target function is exported symbolically for use by other kernel modules. The target function is a function referenced by the other kernel modules among the at least one function. The other kernel modules are kernel modules in the kernel mode of the host machine that are different from the user-mode driver.

20. A computer device, characterized in that, include: A memory and a processor, the memory for storing a computer program, the processor coupled to the memory for executing the computer program to implement the steps of the method of any one of claims 16-19.

21. A computer-readable storage medium storing computer programs / instructions, characterized in that, When the computer program / instructions are executed by the processor, the processor is enabled to perform the steps of the method according to any one of claims 16-19.

22. A computer program product, characterized in that, include: A computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 16-19.

Images