Virtual input / output device queue online management method, device, product and medium

Abstract

The present invention discloses a virtual input / output device queue online management method, device, product and medium, relates to the field of virtualization technology, is used to realize the online addition of virtual IO device queue, and aims at the problem that queue online addition is not currently supported, provides a virtual input / output device queue online management method, by extending the VirtIO general transport layer, to additionally support the management queue, the management queue is provided with a used list for back-end QEMU to directly read data, and realizes the instruction interaction between the front-end driver and the back-end QEMU. After completing the queue configuration work required by the front-end driver, the front-end driver can notify the back-end QEMU and return the memory address information of the newly added queue, so that the back-end QEMU can complete the queue configuration operation required by the back-end, thereby realizing the coordination between the front-end driver and the back-end QEMU to complete the online addition of the queue.

Description

Technical Field

[0001] The present invention relates to the field of virtualization technology, and in particular to a virtual input / output device queue online management method, device, product and medium. Background Art

[0002] With the development of cloud computing technology, businesses in many fields are being moved to the cloud. This includes industries such as finance and communications that have strict requirements for business continuity. One solution to ensure business continuity is to implement hot-swappable capabilities for hardware and virtual hardware devices, which can achieve zero downtime maintenance.

[0003] At present, the industry has proposed a KVM virtual machine (Kernel-based Virtual Machine, an open source system virtualization module) that supports hot-swap technology for virtual processors (vCPU), memory, network cards and hard disks (network cards and hard disks are collectively referred to as virtualized input and output (IO) devices). However, since virtualized IO devices do not support online addition of queues, the performance of virtualized IO devices (mainly data throughput here) does not increase linearly with the horizontal expansion of the number of virtual machine vCPUs, which is still a key point restricting the online improvement of the overall IO performance of virtual machines.

[0004] Therefore, technicians in this field are in urgent need of a virtual input and output device queue online management method to solve the performance bottleneck problem caused by the current virtual IO device not supporting queue online addition. Summary of the invention

[0005] The purpose of the present invention is to provide a virtual input and output device queue online management method, device, product and medium to solve the performance bottleneck problem caused by the current virtual IO device not supporting queue online addition.

[0006] In order to solve the above technical problems, the present invention provides a virtual input and output device queue online management method, which is applied to the front-end driver side, comprising:

[0007] When receiving a queue adding request, parsing the queue adding request to determine the number of newly added queues;

[0008] Adding a corresponding number of data transmission queues according to the number of newly added queues, and performing front-end configuration work on the newly added data transmission queues;

[0009] The memory address information allocated to the newly added data transmission queue during the front-end configuration work is written into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

[0010] In a possible embodiment, the front-end configuration of the newly added data transmission queue includes:

[0011] Memory space, queue number and interrupt number are allocated to the newly added data transmission queue, and an interrupt processing callback function is bound to the data transmission queue.

[0012] In a possible embodiment, after allocating memory space, queue number and interrupt number for the newly added data transmission queue, and binding an interrupt processing callback function, the method further includes:

[0013] Set the device status in the multi-queue general configuration register to the state of adjusting the number of queues;

[0014] The queue quantity adjustment state is a state pre-defined in the VirtIO device state machine protocol; when the device state is the queue quantity adjustment state, the corresponding data transmission queue is prohibited from use.

[0015] In a possible embodiment, after setting the device state in the multi-queue general configuration register to the state of adjusting the number of queues, the method further includes:

[0016] If the back-end device executes the interrupt processing callback function successfully, the device state in the multi-queue general configuration register is set to the driver loading completion state; otherwise, the device state in the multi-queue general configuration register is set to the error state.

[0017] In a possible embodiment, the method further includes:

[0018] If the steps of adding a corresponding number of data transmission queues according to the number of newly added queues, allocating memory space and interrupt numbers for the newly added data transmission queues, and binding interrupt processing callback functions fail, the device status in the multi-queue general configuration register is set to an error status.

[0019] In a possible embodiment, the method further includes:

[0020] When receiving a queue deletion request, parsing the queue deletion request to determine a first target queue to be deleted;

[0021] Suspending the first target queue to prohibit the first target queue from accepting requests sent by the driver;

[0022] After confirming that the messages in the first target queue have been consumed by the backend device, unbinding the interrupt processing callback function of the first target queue, and releasing the interrupt number and memory space corresponding to the first target queue;

[0023] The device state in the multi-queue general configuration register is set to a queue quantity adjusting state, so that the back-end device knows that the first target queue has been completely deleted by the front-end driver.

[0024] In a possible embodiment, the method further includes:

[0025] When receiving an interrupt affinity tuning request, calling an operating system interrupt interface to obtain a list of interrupt numbers associated with each of the data transmission queues;

[0026] For each of the interrupt numbers, the mapping relationship is re-determined and refreshed in the virtual file system interface based on the latest virtual processor scheduling range.

[0027] In a possible embodiment, the method further includes:

[0028] When a queue status query request is received, the total number of queues of the data transmission queue, the number of used slots of each data transmission queue and the queue status information are obtained; and all the obtained information is encapsulated into the response data of the queue status query request and written into the used list.

[0029] In a possible embodiment, the management queue is a standard VirtIO queue structure, the queue structure includes the used list and the available list that can be written by the back-end device, and the management queue is bound to a queue management request processing function and an interrupt number;

[0030] The queue management request processing function is an interrupt processing callback function, which is triggered by a virtual machine interrupt containing a bound interrupt number;

[0031] When the queue management request processing function is triggered, execute:

[0032] Parsing the queue management requests in the available list; wherein the queue management requests include: queue addition request, queue deletion request, interrupt affinity tuning request and queue status query request;

[0033] When the queue management request is a queue adding request, a first function is executed; wherein the first function is used to execute the steps of: parsing the queue adding request to determine the number of newly added queues; adding a corresponding number of data transmission queues according to the number of newly added queues, and allocating memory space and interrupt numbers for the newly added data transmission queues, and binding interrupt processing callback functions; and writing the memory address information of the newly added data transmission queue into the used list of the management queue;

[0034] When the queue management request is a queue deletion request, a second function is executed; wherein the second function is used to execute: parsing the queue deletion request to determine the first target queue to be deleted; suspending the first target queue and prohibiting the first target queue from accepting requests issued by the driver; after confirming that the messages in the first target queue have been consumed by the back-end device, unbinding the interrupt processing callback function of the first target queue, and releasing the interrupt number and memory space corresponding to the first target queue; setting the device status in the multi-queue general configuration register to the queue quantity adjustment status, so that the back-end device can know that the first target queue has been deleted by the front-end driver;

[0035] When the queue management request is an interrupt affinity tuning request, a third function is executed; wherein the third function is used to execute: calling an operating system interrupt interface to obtain a list of interrupt numbers associated with each of the data transmission queues; for each of the interrupt numbers, re-determining the mapping relationship and refreshing it in the virtual file system interface based on the latest virtual processor scheduling range;

[0036] The fourth function is executed when the queue management request is a queue status query request; wherein the fourth function is used to execute: obtaining the total number of queues of the data transmission queue, and the number of used slots and queue status information of each data transmission queue; and encapsulating all the obtained information into response data of the queue status query request, and writing it into the used list.

[0037] In order to solve the above technical problems, the present invention also provides a virtual input and output device queue online management method, which is applied to the back-end device side, comprising:

[0038] When a queue adding request is received, the memory address information is read from the used list of the management queue; wherein the memory address information is allocated when the front-end driver side receives and parses the queue adding request to determine the number of newly added queues, adds a corresponding number of data transmission queues according to the number of newly added queues, and performs queue front-end configuration work for the newly added data transmission queue;

[0039] Allocating corresponding queue memory for the newly added data transmission queue on the host side;

[0040] A mapping relationship between the queue memory and the memory address information is established.

[0041] In a possible embodiment, the management queue is a standard VirtIO queue structure, and the queue structure includes the used list and an available list that can be written by the backend device;

[0042] The method further comprises:

[0043] Whenever a queue management request is received, the queue management request is delivered to the available list of the management queue, and an interrupt containing an interrupt number bound to the management queue is injected into the virtual machine;

[0044] The queue management request includes the queue adding request; the management queue is bound to the interrupt number, and the virtual machine interrupt containing the interrupt number triggers the queue management request processing function bound to the management queue.

[0045] In a possible embodiment, the method further includes:

[0046] When receiving a queue deletion request, parsing the queue deletion request to determine the number of queues to be deleted;

[0047] Determine the target queue to be deleted according to the number of the deletion queues and the total number of the current data transmission queues;

[0048] Adding the target queue to the queue deletion request, and delivering the queue deletion request to the available list;

[0049] Prioritizing processing of data in the target queue;

[0050] After all the data in the target queue has been processed, the mapping relationship corresponding to the target queue is unbound, and the memory space of the target queue is released; the interrupt number corresponding to the target queue whose data has been processed is written into the available list, and an interrupt containing the interrupt number bound to the management queue is injected into the virtual machine, so that the front-end driver knows that the messages in the target queue have been consumed by the back-end device;

[0051] After confirming that the target queue has been completely deleted by the front-end driver, the number of queues in the multi-queue general configuration register is updated.

[0052] In a possible embodiment, the queue number of the management queue is 0, and the queue numbers of the remaining data transmission queues are allocated sequentially from 1;

[0053] Then, according to the number of the deletion queues and the total number of the current data transmission queues, determining the first target queue to be deleted includes:

[0054] Determining a deletion target value according to a difference between the number of deletion queues and the total number of current data transmission queues;

[0055] Based on the order of the queue numbers from large to small, the data transmission queues whose number is the deletion target value are selected as the first target queues to be deleted.

[0056] In a possible embodiment, the method further includes:

[0057] When receiving an interrupt affinity tuning request, delivering the interrupt affinity tuning request to the available list;

[0058] After the front-end driver completes the mapping and refreshing of all the existing data transmission queue interrupt numbers, it returns a response result indicating that the interrupt affinity tuning request is successful.

[0059] In a possible embodiment, the method further includes:

[0060] The interrupt processing callback function bound to the backend device is extended so that the interrupt processing callback function bound to the backend device is also used to determine whether the device state in the multi-queue general configuration register is in the queue quantity adjustment state after receiving the virtual machine exit event, and if so, then:

[0061] When the received queue management request is a queue adding request, executing the steps of reading the memory address information in the used list, allocating corresponding queue memory for the newly added data transmission queue on the host side, and establishing a mapping relationship between the queue memory and the memory address information;

[0062] When the received queue management request is the queue deletion request, the step of parsing the queue deletion request to determine the number of queues to be deleted is performed; the step of determining the first target queue to be deleted is performed according to the number of queues to be deleted and the total number of the current data transmission queues; the step of adding the first target queue to the queue deletion request and delivering the queue deletion request to the available list is performed; the data in the first target queue is processed first; after all the data in the first target queue is processed, the mapping relationship corresponding to the first target queue is unbound and the memory space of the first target queue is released; the interrupt number corresponding to the first target queue whose data has been processed is written into the available list, and the interrupt containing the management queue binding interrupt number is injected into the virtual machine, so that the front-end driver can know that the messages in the first target queue have been consumed by the back-end device; after confirming that the first target queue has been deleted by the front-end driver, the step of updating the number of queues in the multi-queue general configuration register is performed;

[0063] When the received queue management request is the interrupt affinity tuning request, the steps of delivering the interrupt affinity tuning request to the available list are executed; after the front-end driver completes the mapping refresh of all the existing data transmission queue interrupt numbers, returning a response result indicating that the interrupt affinity tuning request is successful;

[0064] The virtual machine exit event is triggered when the device state in the multi-queue general configuration register changes.

[0065] In a possible embodiment, the method further includes:

[0066] When receiving a queue status query request, delivering the queue status query request to the available list;

[0067] After the front-end driver writes the response data into the used list, the response data is read and returned as a response result of the queue status query request;

[0068] The response data includes: the total number of the data transmission queues, the number of used slots of each of the data transmission queues, and queue status information.

[0069] In order to solve the above technical problems, the present invention also provides a virtual input and output device queue online management device, which is applied to the front-end driver side, comprising:

[0070] A request parsing module, configured to parse a queue adding request upon receiving the queue adding request to determine the number of newly added queues;

[0071] A front-end configuration module, used to add a corresponding number of data transmission queues according to the number of newly added queues, and perform front-end configuration work on the newly added data transmission queues;

[0072] The address return module is used to write the memory address information allocated to the newly added data transmission queue during the front-end configuration work into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

[0073] In order to solve the above technical problems, the present invention also provides a virtual input and output device queue online management device, which is applied to the back-end device side, comprising:

[0074] An address receiving module is used to read memory address information from a used list of a management queue when a queue adding request is received; wherein the memory address information is allocated when the front-end driver side receives and parses the queue adding request to determine the number of newly added queues, adds a corresponding number of data transmission queues according to the number of newly added queues, and performs queue front-end configuration work for the newly added data transmission queue;

[0075] A memory allocation module, used for allocating corresponding queue memory for the newly added data transmission queue on the host side;

[0076] The address mapping module is used to establish a mapping relationship between the queue memory and the memory address information.

[0077] To solve the above technical problem, the present invention also provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned virtual input and output device queue online management method when executed by a processor.

[0078] In order to solve the above technical problems, the present invention also provides a virtual input and output device queue online management device, comprising:

[0079] Memory for storing computer programs;

[0080] The processor is used to implement the steps of the above-mentioned virtual input and output device queue online management method when executing the computer program.

[0081] To solve the above technical problem, the present invention also provides a non-volatile storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the virtual input and output device queue online management method as described above are implemented.

[0082] The present invention provides a virtual input / output device queue online management method, which extends the universal transport layer of VirtIO in the operating system kernel so that it can support management queues in addition to the original data transmission queues. Among them, the data transmission queues originally supported by the universal transport layer of VirtIO include an available list and a used list. The requests to be processed will be placed in the available list by the front-end driver, and the back-end device (QEMU) will place the processed requests in the used list. That is, for the data transmission queue, the front-end driver can directly access the available list of the queue, and the back-end QEMU can directly access the used list of the queue. Based on this mechanism, the management queue in the present invention is also provided with a used list for the back-end QEMU to directly read data. By placing the data required or output by the front-end driver and the back-end QEMU during the queue addition process into a specific list, the instruction interaction between the front-end driver and the back-end QEMU is realized. That is, the front-end driver and the back-end QEMU can cooperate with each other. After completing the queue configuration work required by the front-end driver, the front-end driver can notify the back-end QEMU and return the memory address information of the newly added queue (that is, the necessary information required for the back-end to complete the queue configuration work), so that the back-end QEMU can complete the queue configuration operation required by the back-end, thereby achieving the cooperation between the front-end driver and the back-end QEMU to complete the online addition of the queue.

[0083] From the above, it can be seen that this method can realize the online addition of queues for virtual IO devices, so that when the number of virtual machine vCPUs is horizontally expanded, the number of queues can be increased accordingly, so that the virtual IO devices can linearly increase the data throughput, breaking through the performance bottleneck of hot expansion of virtual machine vCPUs while the throughput of virtual IO devices does not increase.

[0084] The virtual input / output device queue online management device and the non-volatile storage medium provided by the present invention correspond to the above method and have the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] In order to more clearly illustrate the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0086] Figure 1 A flowchart of a virtual input / output device queue online management method applied to a front-end driver side provided by an embodiment of the present invention;

[0087] Figure 2 A schematic diagram of a queue data structure provided by an embodiment of the present invention;

[0088] Figure 3 A schematic diagram of a principle of implementing online queue management based on a management queue provided by an embodiment of the present invention;

[0089] Figure 4 A flowchart of a method for online management of a virtual input / output device queue applied to a backend QEMU side provided by an embodiment of the present invention;

[0090] Figure 5 A schematic diagram of an extended VirtIO device state machine provided by an embodiment of the present invention;

[0091] Figure 6 A flowchart of queue interrupt affinity tuning provided by an embodiment of the present invention;

[0092] Figure 7 A structural diagram of an online management device for a virtual input / output device queue provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0093] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0094] The core of the present invention is to provide a virtual input and output device queue online management method, device, product and medium.

[0095] In order to enable those skilled in the art to better understand the scheme of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0096] At present, KVM virtual machines (Kernel-based Virtual Machine, an open source system virtualization module) already support hot-swapping of virtual processors (vCPU), memory, network cards and hard disks (network cards and hard disks are collectively referred to as virtualized input and output (IO) devices). However, there are still some legacy issues, such as the performance of virtualized IO devices (mainly data throughput here) does not increase linearly with the horizontal expansion of the number of virtual machine vCPUs, and it still becomes a key point that restricts the online improvement of the overall IO performance of virtual machines. The reason is that at the beginning of the creation of the virtual machine, the virtualization layer initializes multiple virtual IO device queues that are consistent with the number of virtual machine vCPUs to achieve 1:1 binding of virtual IO device queues and virtual machine vCPU interrupts. This not only achieves load balancing of IO device data processing, but also has the ability to linearly increase IO throughput with the horizontal expansion of the number of vCPUs.

[0097] However, the number of queues in the virtualized IO device cannot be increased online (i.e. hot-swapped) like the vCPU. Currently, the number of queues in the virtualized IO device can only be expanded in the following ways: uninstall the virtualized IO device from the virtual machine at the virtualization layer, edit and update the number of virtualized IO device queues, and re-mount the virtualized IO device (or restart the virtual machine).

[0098] The above solution aims to renegotiate and reconstruct multiple queues between the virtualized IO device driver (front-end driver) and the virtualized IO device (back-end device) in the virtual machine. However, the virtualized IO device will be temporarily disconnected, and the business will inevitably be interrupted or even abnormal (such as IO errors in the operating system and abnormal exit of the business process), which is unacceptable for industries such as finance and communications that have strict requirements on business continuity.

[0099] Therefore, in order to solve the above problems, the present invention provides a virtual input and output device queue online management method, which is used to implement the online management of queues in the transmission layer of the operating system kernel VirtIO (an abstract layer located above the device in the semi-virtualized virtual machine monitor (hypervisor)) (including queue addition, and the queue managed here generally refers to the data transmission queue. Unless otherwise specified in the following embodiments, the queues for management operations such as addition and deletion are all data transmission queues). VirtIO is a front-end and back-end architecture, including a front-end driver, a back-end device (QEMU, a virtual operating system simulator) and a transmission protocol (vring). Therefore, the configuration of the data transmission queue needs to be implemented separately in the front-end driver and the back-end QEMU. This method also needs to be implemented on both the front-end driver and the back-end QEMU.

[0100] First, Figure 1 As shown, applied to the front-end driving side, the method includes:

[0101] S111: When a queue adding request is received, the queue adding request is parsed to determine the number of newly added queues.

[0102] S112: Add a corresponding number of data transmission queues according to the number of newly added queues, and perform front-end configuration work on the newly added data transmission queues.

[0103] S113: Write the memory address information allocated to the newly added data transmission queue in the front-end configuration work into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

[0104] Before describing the specific embodiments of the present method, the principle of the present method is described first:

[0105] If you want to add a device queue online, you need to configure and use the newly added queue online. Specifically, the front-end driver needs to build a queue, allocate a queue number, memory space (host side) and interrupt number to the queue, and bind an interrupt processing callback function to the queue. Considering the universality of the data structure of the data transmission queue, such as Figure 2 As shown, it is a standard VirtIO queue structure in the VirtIO general transport layer, including an available list (avail), a used list (used) and a descriptor list (desc_table), so the present invention will not be repeated here. The back-end QEMU needs to allocate queue memory for the queue (virtual machine side), and then establish a mapping between the virtual machine side management queue memory space GPA (virtual machine physical address) and the host side management queue memory space HVA (host virtual address). At present, it is precisely because the above-mentioned instructions and information interaction cannot be realized between the front-end driver and the back-end QEMU that the online addition of the queue cannot be realized.

[0106] To solve this problem, the present invention utilizes the data structure of the existing data transmission queue, including a used list that can be directly read by the back-end QEMU, to realize the instruction and information interaction from the front-end driver to the back-end QEMU, so that the front-end driver and the back-end QEMU can cooperate to realize the online addition of the queue.

[0107] In the above step S111, it is only required that the data structure of the newly added management queue in this method contains a used list that can be read by the back-end QEMU. That is, in a most basic queue online addition process, the queue addition is triggered from the front-end driver side. After the configuration work on the front-end driver side is completed, the back-end QEMU is notified and the data (i.e., memory address information) required for the back-end to complete the configuration work is provided. In this scenario, the queue addition request of step S111 must be sent by the user to the front-end driver. At this time, it is only required that the management queue include a used list that can be read by the back-end QEMU, and the memory address information allocated by the front-end driver for the newly added queue can be delivered to the used list.

[0108] However, in a possible embodiment, the management queue can directly use the data structure of the existing data transmission queue, that is, a standard VirtIO queue structure, so as to conveniently and quickly achieve the purpose of "containing a used list that can be read by the back-end QEMU", that is, to achieve the necessary condition for this method to add queues online.

[0109] In addition, based on the management queue provided by this embodiment, the management queue also includes an avail list that can be read by the front-end driver. If the management queue can also deliver the request of the back-end QEMU to the avail list, the queue addition request in the above step S111 can also be issued by the back-end QEMU. After receiving the queue addition request issued by the user, the back-end QEMU delivers the request to the avail list for the front-end driver to receive. Based on this, the instruction interaction between the front and back ends can be realized, which is more suitable for the user's operating habit of issuing instructions on the back-end QEMU side.

[0110] Furthermore, Figure 3 As shown, the present invention supports additional management queues by extending the VirtIO transport layer in the operating system kernel. Because the main VirtIO devices are designed based on the VirtIO-PCI (Peripheral Component Interconnect, a standard for defining local buses) framework for driver design: (1) The upper layer is operations and attributes closely related to the device type, such as virtio-blk is a virtual hard disk driver. Virtio-net is a virtual network card driver, including device probe (device discovery, parsing characteristics, initialization, etc.) and device characteristic definition, device attribute parsing operation function, device registration function, etc. (2) The lower layer is the VirtIO general transport layer, which provides data transmission capabilities based on the direct memory access (DMA) mechanism for virtio-* drivers, mainly including building queues, allocating interrupt numbers (IRQ num), and binding interrupt processing callback functions. Therefore, the present invention supports management queues by extending the VirtIO general transport layer, and can automatically enable all virtio-* drivers and their devices to add and delete IO queues online.

[0111] As for how to implement the management queue, since the management queue adopts the same queue structure as the original data transmission queue, its implementation plan can also refer to the original data transmission queue implementation plan, which mainly includes initialization, interrupt number allocation and binding of interrupt processing callback function.

[0112] The initialization of the management queue is mainly divided into two parts: the front-end and the back-end. The first is the initialization of the front-end driver side: the front-end driver assigns a queue number to the management queue. In a possible embodiment, the management queue is fixed to number 0, and the number of data transmission queues parsed by virtio-* is N (for example, N=4), and they are numbered from 0 (1 to N). The second is the design of the queue structure and space allocation. Considering that the data transmission queue structure itself is already universal, and in order to simplify the management of multiple queues, the management queue adopts the same structure as the data transmission queue, and allocates space according to the number of queues (i.e. 1).

[0113] The second step is the initialization of the backend QEMU side. When QEMU simulates the device, it will also allocate the host side memory and interrupt number according to the number of queues (N data transmission queues + 1 management queue) and queue structure. After the virtual machine driver allocates the management queue memory space, the driver will set the multi-queue general configuration register ( Figure 3 ) marks the management queue as the queue currently being initialized, and writes the address and length of the queue memory space into the "Queue Configuration" ( Figure 3 ) and notifies the backend QEMU. QEMU then establishes a mapping between the virtual machine side management queue memory space GPA (virtual machine physical address) and the host side management queue memory space HVA (host virtual address). QEMU can identify the avail, used, and desc_table spaces of the management queue based on the agreed standard VirtIO queue structure, and then can encapsulate and place requests, obtain and parse response results, etc.

[0114] After that, for the allocation of interrupt numbers for the management queue, an additional interrupt number can be allocated to the management queue when the VirtIO device queue (originally only refers to the data transmission queue) is allocated. The allocation of interrupt numbers for the management queue is no different from that for the data transmission queue, so it will not be repeated here.

[0115] Finally, the corresponding interrupt processing callback function is bound to the management queue. For the original data transmission queue, the bound interrupt processing callback function is the queue data processing function. The management queue is different from the data transmission queue. Its function is to implement queue management. Therefore, the bound interrupt processing callback function is the function that implements the queue management function, which should at least include the function part that can implement the above steps S11~S13.

[0116] Returning to step S112, the process of adding and configuring the queue is completed on the front-end driver side. As can be seen from the above description, there is currently a general process specification for adding and configuring the queue, so this embodiment will not be repeated. However, in a possible embodiment, the front-end configuration work of the above step S12 specifically includes: allocating memory space, queue number and interrupt number for the newly added data transmission queue, and binding the interrupt processing callback function to the data transmission queue.

[0117] Step S113 is a step of delivering the memory address information obtained by the front-end driver configuration queue to the back-end QEMU. As can be seen from the above, the delivery of the memory address information depends on the management queue implementation, and the memory address information is delivered to the used list in the management queue, so that the back-end QEMU can obtain it and perform the back-end queue configuration work.

[0118] Similarly, for the backend configuration work implemented by the backend QEMU side, specifically, the corresponding queue memory is allocated to the newly added data transmission queue on the host side, and then a mapping relationship between the queue memory and the memory address information is established.

[0119] That is, for the backend QEMU side, such as Figure 4 As shown, the method includes:

[0120] S211: When a queue adding request is received, the memory address information is read from the used list of the management queue.

[0121] S212: Allocate corresponding queue memory for the newly added data transmission queue on the host side.

[0122] S213: Establish a mapping relationship between the queue memory and the memory address information.

[0123] The method applied to the back-end QEMU side can realize the online addition of queues, and its principle is the same as above, so it will not be repeated. In summary, the online management method of a virtual input and output device queue provided by the present invention is applied to both the front-end driver and the back-end QEMU of the VirtIO architecture. By utilizing the mechanism that the queue structure of the data transmission queue contains a used list that can be read by the back-end QEMU, the VirtIO general transport layer is extended to support the management queue that also contains the used list. Furthermore, when it is necessary to add a queue online, the instruction and information interaction between the front-end driver and the back-end QEMU can be realized through the management queue, so that the front-end and back-end can collaboratively realize the addition and configuration of the queue, complete the entire queue addition process, and thus realize the online addition of the queue. Based on this method, the virtual machine can adapt to the online addition of the virtual machine vCPU, realize the synchronous online addition of the virtual IO device queue, so that the performance of the virtual IO device can be elastically expanded, breaking through the performance bottleneck of hot expansion of the virtual machine vCPU and the non-increase of the throughput of the virtual IO device.

[0124] On the other hand, this embodiment also provides another further implementation scheme. After allocating memory space, queue number and interrupt number for the newly added data transmission queue and binding the interrupt processing callback function in step S112, the above method further includes:

[0125] S121: Set the device state in the multi-queue general configuration register to a state of adjusting the number of queues.

[0126] The queue quantity adjustment state is a state pre-defined in the VirtIO device state machine protocol. When the device state is the queue quantity adjustment state, the corresponding data transmission queue is prohibited from being used.

[0127] like Figure 5 As shown, this embodiment extends the VirtIO driver device initialization state machine, and introduces the queue quantity adjustment state (DEVICE_RST_VQ) on the basis of the original states: discovered state (ACKNOWLEDGE), driver found state (DRIVER), negotiation completed state (FEATURES_OK), driver loading completed state (DRIVER_OK), error state (FAILED) and reset state (DEVICE_NEEDS_RESET). Based on the newly extended device state, the management queue can be used to add queues online. For queues that have been added but have not completed all queue configuration operations and cannot be used, the use of these queues can be restricted to ensure that the service is not interrupted. Specifically, that is, when a queue is added to the virtual VirtIO device, the device state of the device is set to the DEVICE_RST_VQ state. At this time, the device is prohibited from using these newly added queues (for example, limiting subsequent requests that need to use the data transmission queue, etc.), thereby ensuring that the service is not interrupted due to the use of queues that have not been configured and cannot realize functions. That is, based on the expansion of the VirtIO driver device initialization state machine in this embodiment, online queue addition without interruption can be achieved, which is well adapted to industries and application scenarios such as finance and communications that have strict requirements on business continuity.

[0128] In addition, based on the above embodiment implementing state machine expansion and managing queues using a standard VirtIO queue structure, the queue structure including a used list and an avail list that can be written by the back-end device, this embodiment also provides another possible embodiment. The corresponding state processing logic is implemented on the front-end driver of the virtual VirtIO device and the back-end QEMU side.

[0129] First of all, it should be noted that although the management queue uses the standard VirtIO queue structure, the structure of the management queue and the data transmission queue are the same. However, the processing logic of the avail and used queues in the management queue is different. This difference is reflected in the fact that the interrupt processing callback function bound to the management queue is different from that of the data transmission queue (the management queue is bound to the queue management request processing function, and the data transmission queue is bound to the queue data processing function). Because on the data plane of the VirtIO device, all read or write requests are initiated by the driver (virtio-*), and the requests to be processed are placed in avail by the front-end driver, and the requests that have been processed by the back-end QEMU are placed in used, and then the driver updates avail to release the queue space. However, in this scenario, both the front-end driver and the back-end QEMU may be the initiators of the request. For example, the back-end QEMU initiates a request to add a queue online, and when the front-end driver notifies the back-end QEMU after the online queue addition is completed, the driver acts as the request initiator. Therefore, it is agreed that the avail queue in the management queue stores the requests from the back-end QEMU to the front-end driver, and the used queue stores the requests from the front-end driver to the QEMU driver. As can be seen from the above embodiments, the backend QEMU has obtained the addresses of avail, used, and desc_table based on the standard VirtIO queue structure. Therefore, in this embodiment, the queue management request processing function needs to comply with a basic management strategy: as a consumer, it takes messages from avail for request processing, and as a producer, it puts the messages to be processed by the backend QEMU into used.

[0130] Based on this most basic management strategy, this embodiment also proposes a corresponding implementation plan for the back-end driver side after the DEVICE_RST_VQ state is introduced:

[0131] The interrupt processing callback function bound to the backend device is extended so that the interrupt processing callback function bound to the backend device implements the above steps S211 to S213.

[0132] It should be noted that, because in actual applications, the back-end QEMU has registered the multi-queue general configuration register to KVM when simulating the device. Therefore, once the data in the multi-queue general configuration register is modified by the front-end driver (for example, changing the device status), the virtual machine exit event (VMExit) will be triggered. This event will be captured by KVM and notified to the back-end QEMU, and then trigger the interrupt processing callback function bound to the back-end QEMU. This interrupt processing callback function is dedicated to processing device state change events, and based on the state machine expansion of the above embodiment, when the device state enters the DEVICE_RST_VQ state, it means that a new queue has been added (based on the current embodiment, the DEVICE_RST_VQ state in subsequent embodiments will also correspond to other queue management scenarios). Therefore, by expanding this function, this embodiment can realize that the back-end QEMU automatically responds to the queue addition task, and after the front-end driver completes the corresponding queue configuration work, it automatically triggers and performs the back-end queue configuration work.

[0133] The above embodiment can realize the process triggering from the front-end driver to the back-end QEMU. Further, this embodiment also provides an implementation scheme for triggering the front-end driver by the back-end QEMU, which is applied to the back-end QEMU side. The method also includes:

[0134] S22: Whenever a queue management request is received, the queue management request is delivered to the available list of the management queue, and an interrupt containing an interrupt number bound to the management queue is injected into the virtual machine.

[0135] The queue management request at least includes a queue adding request (the current embodiment only involves a queue adding request, and subsequent embodiments will also include a queue deleting request, an interrupt affinity tuning request, and a queue status query request). The management queue is bound to an interrupt number, and the virtual machine interrupt containing the interrupt number triggers the queue management request processing function bound to the management queue.

[0136] That is, in this embodiment, queue management requests (especially queue addition requests) do not need to be limited to the front-end driver. After receiving the queue management request, the back-end QEMU will deliver the queue management request to the used list of the management queue, and inject an interrupt containing the management queue bound interrupt number into the virtual machine, thereby triggering the interrupt processing callback function of the management queue to perform the corresponding queue management operation on the front-end driver side. Based on the implementation scheme provided in this embodiment, the user can inject queue management requests on either side of the front-end driver and the back-end QEMU, and both ends can trigger the queue management process on the other end, ensuring automatic and continuous queue management.

[0137] On the other hand, for the extension of the VirtIO device state machine in the above embodiment, this embodiment further provides a corresponding state management solution, which is applied to the driver front-end side. After step S121, the method further includes:

[0138] S122: If the backend device executes the interrupt processing callback function successfully, the device state in the multi-queue general configuration register is set to the driver loading completion state; otherwise, the device state in the multi-queue general configuration register is set to the error state.

[0139] like Figure 5 As shown, after extending the VirtIO device state machine and introducing the DEVICE_RST_VQ state, this embodiment provides a management solution for the transition from the DEVICE_RST_VQ state to other states. As can be seen from the above embodiment, the device state enters the DEVICE_RST_VQ state triggered by the front-end driver completing the queue configuration work. At this time, only the back-end QEMU needs to complete the queue configuration work, and the newly added queue can be put into use, that is, the transition to the driver loading completion (DRIVER_OK) state.

[0140] Furthermore, this embodiment also provides another state machine management solution, and the above method further includes:

[0141] S123: If the steps of adding a corresponding number of data transmission queues according to the number of newly added queues, allocating memory space and interrupt numbers for the newly added data transmission queues, and binding the interrupt processing callback function fail, the device state in the multi-queue general configuration register is set to an error state.

[0142] Based on this embodiment and the previous embodiment, transition management between the newly introduced DEVICE_RST_VQ state and other original states can be implemented, ensuring that the state management in the VirtIO device state machine realizes a closed loop and avoiding the occurrence of errors.

[0143] On the other hand, in addition to queue addition, the virtual input / output device queue online management method provided by the present invention can also implement other queue management requests. For example, in a possible application scenario, there is also a need to delete the queue online. Based on this, this embodiment provides a possible implementation scheme, which is applied to the front-end driver side. The method also includes:

[0144] S131: When a queue deletion request is received, the queue deletion request is parsed to determine a first target queue to be deleted.

[0145] S132: Suspend the first target queue, and prohibit the first target queue from accepting requests sent by the driver.

[0146] S133: After confirming that the messages in the first target queue have been consumed by the backend device, unbind the interrupt processing callback function of the first target queue, and release the interrupt number and memory space corresponding to the first target queue.

[0147] S134: Setting the device state in the multi-queue general configuration register to a queue quantity adjusting state, so that the back-end device knows that the first target queue has been completely deleted by the front-end driver.

[0148] Similar to queue addition, queue deletion also requires the coordination between the front-end driver and the back-end QEMU to achieve the purpose of online queue deletion. Therefore, this embodiment also provides a queue deletion solution on the back-end QEMU side, and the above method also includes:

[0149] S231: When a queue deletion request is received, the queue deletion request is parsed to determine the number of queues to be deleted.

[0150] S232: Determine the target queue to be deleted according to the number of deletion queues and the total number of current data transmission queues.

[0151] S233: Add the target queue to the queue deletion request, and deliver the queue deletion request to the available list.

[0152] S234: Process the data in the target queue first.

[0153] S235: After all the data in the target queue has been processed, the mapping relationship corresponding to the target queue is unbound and the memory space of the target queue is released; the interrupt number corresponding to the target queue whose data has been processed is written into the available list, and an interrupt containing the interrupt number bound to the management queue is injected into the virtual machine, so that the front-end driver can know that the messages in the target queue have been consumed by the back-end device.

[0154] S236: After confirming that the target queue has been completely deleted by the front-end driver, the number of queues in the multi-queue general configuration register is updated.

[0155] Based on the queue deletion scheme provided on both sides of the driver front-end and back-end QEMU in the above-mentioned embodiment, the overall process of online deletion of the queue is: QEMU encapsulates the queue deletion request (VQ_DEL message) and delivers the request to the avail queue. According to the total number of queues (recorded on the back-end QEMU side or the queue information query in the subsequent embodiment) and the number of queues to be deleted for this request, the back-end QEMU can determine the list of queues to be deleted. Therefore, all the data to be processed in the target queues are processed first. At the same time, the back-end QEMU injects an interrupt into the KVM based on the interrupt number bound to the management queue to trigger the management queue interrupt processing callback function of the front-end driver. The target queue to be deleted is suspended and no longer accepts requests issued by virti-*. Until it is confirmed that the messages in the queue have been consumed by the back-end QEMU, step S133 (that is, the reverse operation required for adding the queue to the front-end driver configuration) is executed to move the target queue out of the data processing plane, release the interrupt vector number and the queue memory space. Then update the device status of the multi-queue general configuration register to DEVICE_RST_VQ status, trigger the interrupt processing callback function of the backend QEMU, and notify the backend QEMU to update the device status and the number of queues in the multi-queue general configuration register. After the backend QEMU is completed, the response message of this request can be written to the management queue, that is, the online deletion process of a queue is completed.

[0156] That is, this embodiment also provides an implementation scheme for online deletion of queues, which expands the scenarios of online queue management and can realize other online management requests of users in addition to online queue addition. Based on the online addition and deletion of virtual IO device queues, in coordination with the online addition and deletion capabilities of virtual machine vCPU, the elastic expansion of virtualized IO device performance under zero interruption of virtual machine business is realized, breaking through the performance bottleneck of hot expansion of virtual machine vCPU without increasing IO device throughput.

[0157] Furthermore, this embodiment also provides a possible implementation scheme for how the backend QEMU determines the target queue to be deleted: the queue number of the management queue is 0, and the queue numbers of the remaining data transmission queues are allocated sequentially from 1.

[0158] The above step S232 is specifically as follows: determining the deletion target value according to the difference between the number of deletion queues and the total number of current data transmission queues; selecting the data transmission queue with the number equal to the deletion target value as the first target queue to be deleted based on the order of queue numbers from large to small.

[0159] It is easy to know that queues are assigned queue numbers for easy management. In a general application scenario, the management queue, as the only special queue, can fix the queue number by setting its queue number to 0, that is, no matter how many queues there are, the queue number of the management queue can be guaranteed to be known and unchanged, so as to facilitate subsequent management. Based on this, when it is necessary to delete the data transmission queue, the queue number range of the data transmission queue is selected from 1 to N. In actual applications, for the convenience of queue management, the numbers of each queue are generally continuous numbers, that is, it is usually not desired to have "jump numbers". Therefore, based on this, this embodiment selects the corresponding number of queues ranked in the order of queue numbers from large to small as the target queue to be deleted. On the one hand, it ensures that the queue to be deleted must be a data transmission queue, and on the other hand, it also ensures that the numbers of each queue after deletion are still continuous, and there is no "jump number", which is convenient for subsequent management of the queue.

[0160] On the other hand, this embodiment also provides another online queue management solution, which is applied to the front-end driver side. The method further includes:

[0161] S141: When an interrupt affinity tuning request is received, the operating system interrupt interface is called to obtain a list of interrupt numbers associated with each data transmission queue.

[0162] S142: For each interrupt number, re-determine and refresh the mapping relationship in the virtual file system interface based on the latest virtual processor scheduling range.

[0163] Similarly, applied to the backend QEMU side, this method also includes:

[0164] S241: When receiving an interrupt affinity tuning request, delivering the interrupt affinity tuning request to an available list.

[0165] S242: After the front-end driver completes the mapping and refreshing of all existing data transmission queue interrupt numbers, a response result indicating that the interrupt affinity tuning request is successful is returned.

[0166] This embodiment is based on the extension of management requests to achieve online and non-invasive update of queue interrupt affinity. Specifically, after receiving the interrupt affinity tuning request (VQ_AFFIN message), the backend QEMU delivers the request to the avail queue. As in the above embodiment, the interrupt is injected into the KVM to trigger the management queue interrupt processing callback function to parse the interrupt affinity tuning request on the driver front end. Call the operating system interrupt interface (interrupt API) to obtain a list of interrupt vector numbers associated with each queue of this device. Then, for each interrupt vector number, reset the vCPU scheduling range for it in the virtual file system (sysfs) interface. Figure 6As shown in the figure, the interrupt vector numbers of the newly added queues (vqn) and the existing queues are refreshed with reference to the latest range of vCPU (originally 0-15, and the range is changed to 0-16 by online expansion of one vCPU). This means that all queues can be re-load balanced according to the number of vCPUs, achieving 1:1 online horizontal expansion between queues and vCPUs.

[0167] On the other hand, this embodiment also provides another online queue management solution, which is applied to the front-end driver side. The method further includes:

[0168] S15: When a queue status query request is received, the total number of queues of the data transmission queues, the number of used slots of each data transmission queue and queue status information are obtained; and all the obtained information is encapsulated into response data of the queue status query request and written into the used list.

[0169] Similarly, applied to the backend QEMU side, this method also includes:

[0170] S251: When a queue status query request is received, the queue status query request is delivered to an available list.

[0171] S252: After the front-end driver writes the response data into the used list, the response data is read and returned as a response result of the queue status query request.

[0172] The response data includes: the total number of data transmission queues, the number of used slots of each data transmission queue, and queue status information.

[0173] This embodiment implements queue status information query based on the extension of management requests. Specifically, after receiving the queue status query request (VQ_STAT message), the backend QEMU delivers the queue status query request to the avail queue. As in the above embodiment, after receiving any queue management request and delivering the request to the avail queue, the backend QEMU injects an interrupt into the KVM to trigger the management queue interrupt processing callback function to parse the queue status query request. The front-end driver obtains the total number of queues, the number of used slots in each queue, and the queue status information of the data transmission queue, and encapsulates it into the data (DATA) of the VQ_STAT response message and delivers it to the used queue. Afterwards, the backend QEMU parses the data in the used queue to obtain the above queue information, which is convenient for virtualization R&D engineers or operation and maintenance personnel to analyze the device queue depth and queue slot usage to determine whether the multi-queue performance has reached a bottleneck. If so, expand the vCPU and the number of queues in a timely manner to perform system tuning.

[0174] It should be noted that in the above embodiment, a total of 4 online queue management requests are proposed. The implementation of these queue management requests requires the extension of the message protocol in the backend QEMU. The main work is to define a set of protocols for the backend QEMU and the front-end driver to communicate based on the management queue. The protocol fields, field offsets and lengths, and field meanings are shown in Table 1 below.

[0175] Table 1 VirtIO control queue message protocol

[0176]

[0177] It is easy to understand that the above Table 1 only shows the four queue management requests mentioned in the above embodiment. However, the queue management request can also be extended. Based on the message protocol definition method in the above Table 1, the message protocol of other queue management requests can be extended based on the same principle.

[0178] On the other hand, it has been explained in the above embodiment that the various queue management operation steps mentioned in the above embodiment can be implemented by managing the queue and the interrupt processing callback function bound to the backend QEMU. Specifically, for the front-end driver side, this embodiment provides a specific interrupt processing callback function extension solution:

[0179] The management queue is a standard VirtIO queue structure. The queue structure includes a used list and an available list that can be written by the back-end device. The management queue is bound to a queue management request processing function and an interrupt number. The queue management request processing function is an interrupt processing callback function triggered by a virtual machine interrupt containing a bound interrupt number.

[0180] When the queue management request processing function is triggered, execute:

[0181] S161: Parse the queue management request in the available list.

[0182] The queue management requests include: queue adding request, queue deleting request, interrupt affinity tuning request and queue status query request.

[0183] S162: Execute the first function when the queue management request is a queue adding request.

[0184] The first function is used to execute steps S111 to S113 mentioned in the above embodiment.

[0185] S163: Execute the second function when the queue management request is a queue deletion request.

[0186] The second function is used to execute steps S131 to S133 mentioned in the above embodiment.

[0187] S164: When the queue management request is an interrupt affinity tuning request, execute the third function.

[0188] The third function is used to execute steps S141 to S143 mentioned in the above embodiment.

[0189] S165: When the queue management request is a queue status query request, execute the fourth function.

[0190] The fourth function is used to execute steps S151 to S153 mentioned in the above embodiment.

[0191] Similarly, for the backend QEMU side, this embodiment also provides a specific interrupt processing callback function extension solution:

[0192] S261: Expand the interrupt processing callback function bound to the backend device so that the interrupt processing callback function bound to the backend device is also used to determine whether the device status in the multi-queue general configuration register is in the queue quantity adjustment state after receiving the virtual machine exit event. If so, execute the following steps S262~S264.

[0193] S262: When the received queue management request is a queue adding request, execute steps S211 to S213 mentioned in the above embodiment.

[0194] S263: When the received queue management request is a queue deletion request, execute steps S231 to S233 mentioned in the above embodiment.

[0195] S264: When the received queue management request is an interrupt affinity tuning request, execute steps S241 to S243 mentioned in the above embodiment.

[0196] It should be noted that since the queue status query mainly requires the front-end driver to obtain specific information, the back-end QEMU plays a more important role in delivering and responding to requests. Therefore, the function extension of the back-end QEMU for the queue status query is easy to implement, as shown in steps S251 and S252 of the above embodiment, which will not be repeated in this embodiment.

[0197] Based on the function expansion of this embodiment, the method is specifically implemented in the front-end driver and the back-end QEMU. And the method is implemented based on the interrupt processing callback function, which can ensure the automatic triggering of the process between the front-end and the back-end, and ensure the continuity and efficiency of the method.

[0198] In the above embodiment, a virtual input / output device queue online management method is described in detail, and the present invention also provides a corresponding embodiment of a virtual input / output device queue online management device. It should be noted that the present invention also describes the embodiment of the device part from both the front-end driver and the back-end QEMU.

[0199] Applied to the front-end driver side, this embodiment provides an online management device for a virtual input / output device queue, including:

[0200] The request parsing module is used to parse the queue adding request when receiving the queue adding request to determine the number of newly added queues.

[0201] The front-end configuration module is used to add a corresponding number of data transmission queues according to the number of newly added queues, and perform front-end configuration work on the newly added data transmission queues.

[0202] The address return module is used to write the memory address information allocated to the newly added data transmission queue in the front-end configuration work into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

[0203] Applied to the backend QEMU side, this embodiment provides an online management device for a virtual input and output device queue, including:

[0204] The address receiving module is used to read the memory address information from the used list of the management queue when a queue adding request is received; wherein the memory address information is allocated when the front-end driver side receives and parses the queue adding request to determine the number of new queues, adds a corresponding number of data transmission queues according to the number of new queues, and performs the front-end configuration work of the queue for the newly added data transmission queue.

[0205] The memory allocation module is used to allocate corresponding queue memory for the newly added data transmission queue on the host side.

[0206] The address mapping module is used to establish a mapping relationship between queue memory and memory address information.

[0207] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, which will not be repeated here.

[0208] In addition to the embodiment of a virtual input / output device queue online management method provided in the above embodiment, the present invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the virtual input / output device queue online management method described in any of the above embodiments can be implemented.

[0209] Since the embodiments of the computer program product part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the computer program product part, which will not be repeated here.

[0210] Figure 7 A structural diagram of a virtual input / output device queue online management device provided by another embodiment of the present invention, such as Figure 7 As shown, a virtual input and output device queue online management device comprises: a memory 10, for storing a computer program;

[0211] The processor 11 is used to implement the steps of a virtual input / output device queue online management method in the above embodiment when executing a computer program.

[0212] The virtual input / output device queue online management apparatus provided in this embodiment may include but is not limited to a mobile terminal, a personal computer, a workstation, etc.

[0213] Among them, the processor 11 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 11 can be implemented in at least one hardware form of a digital signal processor (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 11 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 11 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 11 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0214] The memory 10 may include one or more computer-readable storage media, which may be non-transitory. The memory 10 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 10 is at least used to store the following computer program 101, wherein, after the computer program is loaded and executed by the processor 11, it can implement the relevant steps of a virtual input-output device queue online management method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 10 may also include an operating system 102 and data 103, etc., and the storage method may be short-term storage or permanent storage. Among them, the operating system 102 may include Windows, Unix, Linux, etc. Data 103 may include, but is not limited to, a virtual input-output device queue online management method, etc.

[0215] In some embodiments, a virtual input / output device queue online management apparatus may further include a display screen 12 , an input / output interface 13 , a communication interface 14 , a power supply 15 , and a communication bus 16 .

[0216] Those skilled in the art will understand that Figure 7 The structure shown in the figure does not constitute a limitation on a virtual input and output device queue online management device, and may include more or less components than those shown in the figure.

[0217] An embodiment of the present invention provides an online management device for a virtual input / output device queue, comprising a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a method for online management of a virtual input / output device queue.

[0218] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. A computer program is stored on the non-volatile storage medium, and when the computer program is executed by the processor, the steps described in the above method embodiment (which may be a method corresponding to the front-end drive side, or a method corresponding to the back-end QEMU side, or a method corresponding to both the front-end drive side and the back-end QEMU side) are implemented.

[0219] It is understandable that if the method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc. Various media that can store program codes.

[0220] The above is a detailed introduction to a virtual input and output device queue online management method, device, product and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the embodiments can be referenced to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the present invention.

[0221] It should also be noted that, in this specification, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

Claims

1. A virtual input and output device queue online management method, characterized in that: Applied to the front-end drive side, including: When receiving a queue adding request, parsing the queue adding request to determine the number of newly added queues; Add a corresponding number of data transmission queues according to the number of newly added queues, allocate memory space, queue numbers and interrupt numbers for the newly added data transmission queues, and bind an interrupt processing callback function to the data transmission queues; set the device state in the multi-queue general configuration register to a state where the number of queues is being adjusted; wherein the state where the number of queues is being adjusted is a state newly defined in advance in the VirtIO device state machine protocol; when the device state is the state where the number of queues is being adjusted, the corresponding data transmission queue is prohibited from use; The memory address information allocated to the newly added data transmission queue during the front-end configuration work is written into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

2. The virtual input / output device queue online management method according to claim 1, characterized in that: After setting the device state in the multi-queue general configuration register to the state of adjusting the number of queues, the method further includes: If the back-end device executes the interrupt processing callback function successfully, the device state in the multi-queue general configuration register is set to the driver loading completion state; otherwise, the device state in the multi-queue general configuration register is set to the error state.

3. The virtual input / output device queue online management method according to claim 2, characterized in that: The method further comprises: If the steps of adding a corresponding number of data transmission queues according to the number of newly added queues, allocating memory space and interrupt numbers for the newly added data transmission queues, and binding interrupt processing callback functions fail, the device status in the multi-queue general configuration register is set to an error status.

4. The virtual input / output device queue online management method according to claim 3, characterized in that: The method further comprises: When receiving a queue deletion request, parsing the queue deletion request to determine a first target queue to be deleted; Suspending the first target queue to prohibit the first target queue from accepting requests sent by the driver; After confirming that the messages in the first target queue have been consumed by the backend device, unbinding the interrupt processing callback function of the first target queue, and releasing the interrupt number and memory space corresponding to the first target queue; The device state in the multi-queue general configuration register is set to a queue quantity adjusting state, so that the back-end device knows that the first target queue has been completely deleted by the front-end driver.

5. The online management method for virtual input / output device queue according to claim 4, characterized in that: The method further comprises: When receiving an interrupt affinity tuning request, calling an operating system interrupt interface to obtain a list of interrupt numbers associated with each of the data transmission queues; For each of the interrupt numbers, the mapping relationship is re-determined and refreshed in the virtual file system interface based on the latest virtual processor scheduling range.

6. The online management method for virtual input / output device queue according to claim 5, characterized in that: The method further comprises: When a queue status query request is received, the total number of queues of the data transmission queue, the number of used slots of each data transmission queue and the queue status information are obtained; and all the obtained information is encapsulated into the response data of the queue status query request and written into the used list.

7. The online management method for virtual input / output device queue according to claim 6, characterized in that: The management queue is a standard VirtIO queue structure, the queue structure includes the used list and the available list that can be written by the back-end device, and the management queue is bound to a queue management request processing function and an interrupt number; The queue management request processing function is an interrupt processing callback function, which is triggered by a virtual machine interrupt containing a bound interrupt number; When the queue management request processing function is triggered, execute: Parsing the queue management requests in the available list; wherein the queue management requests include: queue addition request, queue deletion request, interrupt affinity tuning request and queue status query request; When the queue management request is a queue adding request, a first function is executed; wherein the first function is used to execute the steps of: parsing the queue adding request to determine the number of newly added queues; adding a corresponding number of data transmission queues according to the number of newly added queues, and allocating memory space and interrupt numbers for the newly added data transmission queues, and binding interrupt processing callback functions; and writing the memory address information of the newly added data transmission queue into the used list of the management queue; When the queue management request is a queue deletion request, a second function is executed; wherein the second function is used to execute: parsing the queue deletion request to determine the first target queue to be deleted; suspending the first target queue and prohibiting the first target queue from accepting requests issued by the driver; after confirming that the messages in the first target queue have been consumed by the back-end device, unbinding the interrupt processing callback function of the first target queue, and releasing the interrupt number and memory space corresponding to the first target queue; setting the device status in the multi-queue general configuration register to the queue quantity adjustment status, so that the back-end device can know that the first target queue has been deleted by the front-end driver; When the queue management request is an interrupt affinity tuning request, a third function is executed; wherein the third function is used to execute: calling an operating system interrupt interface to obtain a list of interrupt numbers associated with each of the data transmission queues; for each of the interrupt numbers, re-determining the mapping relationship and refreshing it in the virtual file system interface based on the latest virtual processor scheduling range; The fourth function is executed when the queue management request is a queue status query request; wherein the fourth function is used to execute: obtaining the total number of queues of the data transmission queue, and the number of used slots and queue status information of each data transmission queue; and encapsulating all the obtained information into response data of the queue status query request, and writing it into the used list.

8. A virtual input and output device queue online management method, characterized in that: Applied to the backend device side, including: When a queue adding request is received, the memory address information is read from the used list of the management queue; wherein the memory address information is allocated when the front-end driver side receives and parses the queue adding request to determine the number of newly added queues, adds a corresponding number of data transmission queues according to the number of newly added queues, and performs queue front-end configuration work for the newly added data transmission queues; the management queue is a standard VirtIO queue structure, and the queue structure includes the used list and the available list that can be written by the back-end device; Allocating corresponding queue memory for the newly added data transmission queue on the host side; Establishing a mapping relationship between the queue memory and the memory address information; Whenever a queue management request is received, the queue management request is delivered to the available list of the management queue, and an interrupt containing the interrupt number bound to the management queue is injected into the virtual machine; wherein the queue management request includes the queue add request; the management queue is bound to the interrupt number, and the virtual machine interrupt containing the interrupt number triggers the queue management request processing function bound to the management queue.

9. The online management method for virtual input / output device queue according to claim 8, characterized in that: The method further comprises: When receiving a queue deletion request, parsing the queue deletion request to determine the number of queues to be deleted; Determine the target queue to be deleted according to the number of the deletion queues and the total number of the current data transmission queues; Adding the target queue to the queue deletion request, and delivering the queue deletion request to the available list; Prioritizing processing of data in the target queue; After all the data in the target queue has been processed, the mapping relationship corresponding to the target queue is unbound, and the memory space of the target queue is released; the interrupt number corresponding to the target queue whose data has been processed is written into the available list, and an interrupt containing the interrupt number bound to the management queue is injected into the virtual machine, so that the front-end driver knows that the messages in the target queue have been consumed by the back-end device; After confirming that the target queue has been completely deleted by the front-end driver, the number of queues in the multi-queue general configuration register is updated.

10. The online management method for virtual input / output device queue according to claim 9, characterized in that: The queue number of the management queue is 0, and the queue numbers of the remaining data transmission queues are allocated sequentially from 1; Then, according to the number of the deletion queues and the total number of the current data transmission queues, determining the first target queue to be deleted includes: Determining a deletion target value according to a difference between the number of deletion queues and the total number of current data transmission queues; Based on the order of the queue numbers from large to small, the data transmission queues whose number is the deletion target value are selected as the first target queues to be deleted.

11. The online management method for virtual input / output device queue according to claim 9, characterized in that: The method further comprises: When receiving an interrupt affinity tuning request, delivering the interrupt affinity tuning request to the available list; After the front-end driver completes the mapping and refreshing of all the existing data transmission queue interrupt numbers, it returns a response result indicating that the interrupt affinity tuning request is successful.

12. The online management method for virtual input / output device queue according to claim 11, characterized in that: The method further comprises: The interrupt processing callback function bound to the backend device is extended so that the interrupt processing callback function bound to the backend device is also used to determine whether the device state in the multi-queue general configuration register is in the queue quantity adjustment state after receiving the virtual machine exit event, and if so, then: When the received queue management request is a queue adding request, executing the steps of reading the memory address information in the used list, allocating corresponding queue memory for the newly added data transmission queue on the host side, and establishing a mapping relationship between the queue memory and the memory address information; When the received queue management request is the queue deletion request, the step of parsing the queue deletion request to determine the number of queues to be deleted is performed; the step of determining the first target queue to be deleted is performed according to the number of queues to be deleted and the total number of the current data transmission queues; the step of adding the first target queue to the queue deletion request and delivering the queue deletion request to the available list is performed; the data in the first target queue is processed first; after all the data in the first target queue is processed, the mapping relationship corresponding to the first target queue is unbound and the memory space of the first target queue is released; the interrupt number corresponding to the first target queue whose data has been processed is written into the available list, and the interrupt containing the management queue binding interrupt number is injected into the virtual machine, so that the front-end driver can know that the messages in the first target queue have been consumed by the back-end device; after confirming that the first target queue has been deleted by the front-end driver, the step of updating the number of queues in the multi-queue general configuration register is performed; When the received queue management request is the interrupt affinity tuning request, the steps of delivering the interrupt affinity tuning request to the available list are executed; after the front-end driver completes the mapping refresh of all the existing data transmission queue interrupt numbers, returning a response result indicating that the interrupt affinity tuning request is successful; The virtual machine exit event is triggered when the device state in the multi-queue general configuration register changes.

13. The online management method for virtual input / output device queue according to any one of claims 8 to 12, characterized in that: The method further comprises: When receiving a queue status query request, delivering the queue status query request to the available list; After the front-end driver writes the response data into the used list, the response data is read and returned as a response result of the queue status query request; The response data includes: the total number of the data transmission queues, the number of used slots of each of the data transmission queues, and queue status information.

14. A virtual input and output device queue online management device, characterized in that: Applied to the front-end drive side, including: A request parsing module, configured to parse a queue adding request upon receiving the queue adding request to determine the number of newly added queues; A front-end configuration module is used to add a corresponding number of data transmission queues according to the number of newly added queues, allocate memory space, queue numbers and interrupt numbers for the newly added data transmission queues, and bind an interrupt processing callback function to the data transmission queues; set the device state in the multi-queue general configuration register to a queue number adjusting state; wherein the queue number adjusting state is a state newly defined in advance in the VirtIO device state machine protocol; when the device state is the queue number adjusting state, the corresponding data transmission queue is prohibited from use; The address return module is used to write the memory address information allocated to the newly added data transmission queue during the front-end configuration work into the used list of the management queue, so that the back-end device can read the memory address information in the used list and complete the back-end configuration work of the queue according to the memory address information.

15. A virtual input and output device queue online management device, characterized in that: Applied to the backend device side, including: The address receiving module is used to read the memory address information from the used list of the management queue when receiving the queue adding request; wherein the memory address information is allocated when the front-end driver side receives and parses the queue adding request to determine the number of newly added queues, adds a corresponding number of data transmission queues according to the number of newly added queues, and performs the front-end configuration of the queue for the newly added data transmission queue; the management queue is a standard VirtIO queue structure, and the queue structure includes the used list and the available list that can be written by the back-end device; A memory allocation module, used for allocating corresponding queue memory for the newly added data transmission queue on the host side; An address mapping module, used to establish a mapping relationship between the queue memory and the memory address information; Whenever a queue management request is received, the queue management request is delivered to the available list of the management queue, and an interrupt containing the interrupt number bound to the management queue is injected into the virtual machine; wherein the queue management request includes the queue add request; the management queue is bound to the interrupt number, and the virtual machine interrupt containing the interrupt number triggers the queue management request processing function bound to the management queue.

16. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the virtual input / output device queue online management method as claimed in any one of claims 1 to 13 are implemented.

17. A virtual input and output device queue online management device, characterized in that: include: Memory for storing computer programs; A processor is used to implement the steps of the virtual input and output device queue online management method as described in any one of claims 1 to 13 when executing the computer program.

18. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the online management method for a virtual input / output device queue are implemented as claimed in any one of claims 1 to 13.

Images