Virtual machine simulation event handling methods, apparatus, devices and media
By using a polling thread pool and an IO event read/write thread pool to handle IO events in the virtual machine simulation system, the problem of high system call overhead on solid-state drives in QEMU-Virtio type virtual machines is solved, and the adaptation difficulty of the Vhost-User method is reduced, achieving efficient IO processing and functional completeness.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JINAN INSPUR DATA TECH CO LTD
- Filing Date
- 2026-01-26
- Publication Date
- 2026-05-26
Smart Images
Figure CN122086522A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of virtual device simulation technology, and in particular to virtual machine simulation event processing methods, apparatus and devices. Background Technology
[0002] A virtual machine (VM) is a virtual data processing system, exclusively used by a specific user, but its functionality is achieved by sharing various resources of a real data processing system. The semi-virtualization interface specification Virtio is a semi-virtualization device abstraction interface. Currently, only Quick Emulator (QEMU) and Vhost-User implement virtual machine devices.
[0003] QEMU-Virtio type virtual machines suffer from significant overhead during I / O processing via system calls, especially when used with high-speed solid-state drives (SSDs). While the Vhost-User approach, exemplified by the Storage Performance Development Kit (SPDK), avoids this overhead, it sacrifices some performance gains. Furthermore, this approach is complex and difficult to adapt to new hardware and safety data sheets (SDS). Summary of the Invention
[0004] This application provides a virtual machine simulation event processing method, apparatus, device, and medium to at least solve the problem of high system call overhead during IO processing when QEMU-Virtio type virtual machines run on SSD solid-state drives, as well as the technical problems of complex process and high adaptation difficulty of Vhost-User method represented by SPDK when connecting to new hardware.
[0005] This application provides a virtual machine simulation event handling method. This method is applied to a virtual machine simulation system that establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. The method includes: When the first polling thread in the polling thread pool receives an event sent by KVM, it analyzes the event to determine the target virtual machine that initiated the event and the event type. The first polling thread can be any polling thread in the polling thread pool. When the event type is determined to be an IO event, the first read / write thread in the IO event read / write thread pool is used to obtain the data operation instructions corresponding to the IO event. The first read / write thread can be any read / write thread in the read / write thread pool. The virtual hard disk to be operated on is determined based on the data operation instructions; Execute simulated operations corresponding to data operation instructions in the virtual hard disk and generate simulated operation results; The simulation results are forwarded to the target virtual machine via KVM.
[0006] This application also provides a virtual machine simulation event processing apparatus, which is applied to a virtual machine simulation system. The virtual machine simulation system establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. The apparatus includes: The receiving module is used to receive events sent by the KVM using a first polling thread in the polling thread pool, wherein the first polling thread is any polling thread in the polling thread pool; The processing module is used to analyze the event and determine the target virtual machine that initiated the event and the event type; The acquisition module is used to acquire the data operation instructions corresponding to the IO event by using the first read / write thread in the IO event read / write thread pool when the processing module determines that the event type is an IO event. The first read / write thread is any read / write thread in the read / write thread pool. The processing module is further configured to determine the virtual hard disk to be operated on according to the data operation instruction; execute the simulation operation corresponding to the data operation instruction in the virtual hard disk and generate the simulation operation result; The forwarding module is used to forward the operation result to the target virtual machine through the KVM.
[0007] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described virtual machine simulation event handling methods.
[0008] This application describes a process where, upon receiving an event from KVM via the first polling thread in the polling thread pool, the event is analyzed to determine the target virtual machine initiating the event and the event type. The target virtual machine is identified for retrieving data operation instructions corresponding to the IO event, and the event type is determined for specific read or write operations. After confirming the event type as an IO event, the first read / write thread in the IO event read / write thread pool retrieves the corresponding data operation instructions. The system is able to retrieve these instructions because the target virtual machine initiating the IO event has already been identified, and the system can directly retrieve the data operation instructions by accessing the target virtual machine's memory. Following this, based on the retrieved data operation instructions, a simulated operation corresponding to the instructions is executed from the virtual hard disk where the operation is to be performed, generating a simulated operation result. This simulated operation result is then forwarded to the target virtual machine via KVM, thus completing the processing of a virtual machine simulated event.
[0009] As described above, the system obtains IO events through KVM, acquires data operation instructions using the IO read / write thread pool, executes specific operations based on these instructions, and returns simulated operation results. Since this process runs in kernel mode, it avoids the context switching present in related technologies where data transmission instructions first pass through user mode and then to kernel mode. This reduces the overhead of system calls in handling IO events, thus solving the problem of significant system call overhead in QEMU-Virtio type virtual machines used in high-speed SSD storage applications. Since this method does not bypass kernel-mode block devices, such as solid-state drives (SSDs), to user space like the Vhost-User approach represented by SPDK, it maintains the same level of functional completeness as QEMU-Virtio. Vhost-User, by bypassing kernel-mode block devices, cannot implement some functions, such as snapshots. To use these functions on top of Vhost-User, new interfaces, drivers, and protocols need to be adapted separately. Therefore, when interfacing with new hardware or new SDS (Single Depth Semiconductor Devices) and other kernel-mode block devices, this method, using the QEMU-Virtio interface, driver, and protocol, achieves performance comparable to Vhost-User. Furthermore, by using the more general-purpose QEMU-Virtio interface, driver, and protocol, it reduces the complexity of interfacing with new kernel-mode block devices and lowers the adaptation difficulty. Attached Figure Description
[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0011] Figure 1 A simplified schematic diagram illustrating the principle of the QEMU-Virtio type virtual machine I / O processing procedure provided in this application embodiment; Figure 2 A simplified schematic diagram illustrating the principle of the virtual hard disk I / O processing process for the Vhost-User type provided in this application embodiment; Figure 3 A schematic diagram illustrating a virtual machine-simulated event handling method flow provided in an embodiment of this application; Figure 4 A schematic diagram illustrating another virtual machine simulation event handling method provided in this application embodiment; Figure 5 A schematic diagram illustrating the principle of a virtual machine simulating an event processing procedure, provided in an embodiment of this application; Figure 6 This application provides a schematic diagram of the structure of a virtual machine simulation event processing device. Figure 7 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation
[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0015] In related technologies, VM (Virtual Machine) is a virtual data processing system used to implement various functions using the resources of a real data processing system. The semi-virtualization interface specification Virtio is a semi-virtualization device abstraction interface widely used in QEMU and kernel-based Virtual Machines (KVM), and supports mainstream operating systems such as Windows and Linux. Front-end drivers implemented in the virtual machine operating system are generally called Virtio. Back-end drivers implemented on the host machine mainly take three forms: the back-end implementation in QEMU is called QEMU-Virtio; the implementation in other independent user-space processes, such as SPDK, is called Vhost-User; and the back-end implementation in kernel space is called Vhost-kernel. For virtual machine devices, currently only QEMU-Virtio and Vhost-User are implemented.
[0016] System virtualization technology is a key technology enabling cloud computing. Virtual machines, with their hardware compatibility, security, reliability, and high performance, support the vast majority of cloud services. Disks and network interface cards (NICs) are the two main peripherals configured in a virtual machine, and their performance directly affects the overall performance of the virtual machine. Virtio is currently the most important virtual peripheral specification and interface. There are two main implementations of Virtio devices, that is, the implementations of I / O processing and other emulation processes in virtual machine devices: QEMU-Virtio and Vhost-User.
[0017] See details Figure 1 As shown, Figure 1 The following is a simplified schematic diagram illustrating the principle of I / O processing in a QEMU-Virtio type virtual machine. Figure 1 A simplified workflow for virtual hard disk I / O processing of the QEMU-Virtio type.
[0018] In user space, including the VM Virtio frontend, an event is emitted. When the event is an IO event, it will be intercepted by KVM and transmitted to the QEMU Virtio backend, i.e., step (1) is executed to notify the IO to initiate the event. Then, the QEMU Virtio backend will obtain the operation instructions from the VM Virtio frontend, i.e., step (2) is executed to obtain the IO operation data. In fact, the operation data refers to the data included in the operation instructions, such as the operation type, operation address, and the data length of the operation to be executed. After parsing the operation data, the QEMU Virtio backend can execute the operation corresponding to the operation data, such as executing the corresponding operation by calling the system to read and write the block device, or executing the corresponding operation by calling the system to read and write the file. These operations will all be applied to the kernel-mode block device, which can also be understood as the backend of the virtual machine. That is, the corresponding simulated operation is executed in the virtual machine. That is, step 3(a) or 3(b) is executed. The specific execution of 3(a) or 3(b) is determined according to the actual operation data, and there is no restriction here. After the operation is completed, the operation result needs to be fed back to the VM Virtio frontend, that is, step (4) is executed, and the IO operation result is written back, including the operation status (success / failure, etc.) and the data read, etc. The specific operation result also corresponds to the operation data in the aforementioned step (2), and there are no further restrictions here. After the operation is completed, it may also include an IO completion event notification to inform the VM Virtio frontend that the above operation has been completed, that is, step (5) is executed.
[0019] The above is the appendix. Figure 1 A simplified workflow for virtual machine I / O processing of the QEMU-Virtio type.
[0020] Because during the above operations, when executing the operation data corresponding to step (2), it is necessary to perform operations such as step (3a) or step (3b). When dealing with mechanical hard drives, even though these two steps take a long time, the defect is not obvious due to the inherently low efficiency of mechanical hard drives. In the past, when using mechanical hard drives, their operating speed was relatively slow. Even if there was a certain IO delay, the delay accounted for a small percentage of the overall runtime and had little impact on the user experience. However, due to the widespread adoption of solid-state drives (SSDs), their transmission speed and operating efficiency have greatly improved. If the delay value generated by the same IO operation is the same as that of a mechanical hard drive, then under the faster overall operating rhythm of SSDs, the proportion of this fixed delay will increase significantly, and the impact on the overall performance and user experience of SSDs will become more obvious.
[0021] Therefore, since the hard drives used in work and life are mostly high-speed SSDs, the overhead of system calls, such as the time loss during context switching for executing I / O events, becomes the main factor hindering the improvement of virtual machine performance. The main reason is that high-speed SSDs significantly improve the speed of performing corresponding operations, while the latency of executing system calls is particularly noticeable in comparison.
[0022] The specific reason is that when performing this operation, it is necessary to go through the following steps: Figure 1 The kernel-mode block device shown is the I / O software stack. Because the stability of the I / O software stack is considered during I / O operations, it notifies the CPU via interrupts to ensure compatibility with various devices. However, there is a certain time delay between sending the interrupt to the CPU and the actual start of I / O processing. In the past, when mechanical hard drives were used, this delay was relatively small. However, current solid-state drives (SSDs), especially those supporting the Non-Volatile Memory Express (NVMe) protocol, have faster transfer speeds. While the latency of the I / O operation is the same on both mechanical and SSDs, the proportion of this delay in the overall latency on the SSD is larger. Therefore, bypassing the I / O software stack reduces the latency caused by it.
[0023] Based on the above issues, Vhost-User methods, represented by SPDK, have emerged in related technologies. These methods allow the kernel to directly access hardware or third-party SDS in user space, and combine technologies such as polling, large page memory, zero-copy data, and multi-core parallel programming to support high-performance storage devices.
[0024] like Figure 2 As shown, Figure 2 This is a simplified schematic diagram illustrating the I / O process for a virtual hard disk of type Vhost-User. Steps (1), (2), (4), and (5) are similar to those in the previous example and will not be repeated here. It is important to note that in this example, steps (3a) and (3b) will not require further processing. Figure 1 The diagram illustrates that the QEMU-Virtio type virtual hard disk I / O processing does not require the kernel-mode I / O software stack steps, but instead connects directly to devices such as NVMe and SDS in user mode. Therefore, this method can avoid system overhead caused by system calls.
[0025] However, this method also has obvious drawbacks, as the performance improvement comes at the expense of other performance benefits. For example, it cannot directly utilize advanced features already implemented in traditional files, such as snapshots and backups, and it requires redeveloping drivers on the SPDK side to adapt to high-speed hard drives such as SSDs. This means it needs to interface with new hardware and new SDS, which is highly complex and difficult to adapt.
[0026] To address the aforementioned problems, embodiments of this application provide a virtual machine simulation event handling method. This method is applied to a virtual machine simulation system, which establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. See details... Figure 3 As shown, the method includes the following steps: Step S301: After the first polling thread in the polling thread pool receives an event sent by KVM, the event is analyzed to determine the target virtual machine that initiated the event and the event type.
[0027] The first polling thread is any polling thread in the polling thread pool.
[0028] Step S302: When the event type is determined to be an IO event, the first read / write thread in the IO event read / write thread pool is used to obtain the data operation instructions corresponding to the IO event.
[0029] The first read / write thread is any read / write thread in the read / write thread pool; Specifically, the system polls any polling thread in the thread pool and uses the event notification interface (EventPoll, or epoll) to poll all read / write event descriptors (IOevent FileDescriptors, or ioeventfds) of events sent by KVM. When the event sent by KVM is an IO event, the system obtains the readable event epollin identifier for that IO event. Therefore, when the system receives the epollin identifier, it uses any read / write thread in the IO event read / write thread pool to obtain the owner identifier of that IO event. The owner identifier indicates the specific location of the data operation instructions corresponding to the current IO event in the virtual memory of the target virtual machine. Thus, the system can switch to the memory context of the target virtual machine corresponding to the owner identifier to obtain the data operation instructions corresponding to the IO event.
[0030] Step S303: Determine the virtual hard disk to be operated on according to the data operation instructions.
[0031] Step S304: Execute the simulation operation corresponding to the data operation instruction in the virtual hard disk and generate the simulation operation result.
[0032] Step S305: Forward the simulation operation results to the target virtual machine via KVM.
[0033] Specifically, the system uses data operation instructions to carry the specific operation content to be executed, such as the storage address corresponding to the data to be read. After that, the system uses io_uring to perform the simulated operation corresponding to the data operation instruction to the execution object of the data operation instruction, i.e., the hard disk.
[0034] After the simulation operation is completed, a simulation operation result will be generated. This result includes, but is not limited to, IO operation status identifiers, data transmission information, and device-request matching identifiers. The IO operation status identifier informs the target virtual machine whether the IO request was executed successfully. Data transmission information includes the actual data read from the virtual hard disk for a read operation and the data write verification result (e.g., checksum) for a write operation, ensuring the data is completely written to the virtual hard disk. The device-request matching identifier associates the result with the corresponding IO operation; for example, it may include the virtual block device identifier to identify which device performed the IO operation. Other information may also be included, depending on the specific circumstances, and will not be elaborated further here.
[0035] After generating the simulation operation result, the system will use KVM to forward the simulation operation result to the specific location of the virtual memory of the target virtual machine corresponding to the owner identifier of the IO event corresponding to the data operation instruction, thereby completing the execution process of the IO event.
[0036] In a specific example, when the system receives an event sent by KVM using the first polling thread in the polling thread pool, it analyzes the event and can determine the target virtual machine based on the owner identifier. When the read / write operation type of the event is a read operation, the first thread in the IO event read / write thread pool retrieves the corresponding data operation instruction. From the retrieved data operation instruction, the read / write operation address and length can be determined. For example, when the read / write operation address is L and the read / write operation length is 512 bytes, the system will read 512 bytes of data at address L of the virtual hard disk. That is, it will perform the corresponding read operation at address L of the virtual hard disk and forward the read data (i.e., the simulated operation result) to the memory of the corresponding virtual machine via KVM according to the owner identifier, thus completing the forwarding of the simulated operation result to the target virtual machine via KVM.
[0037] This application provides a virtual machine simulation event handling method. When the first polling thread in the polling thread pool receives an event sent by KVM, the event is analyzed to determine the target virtual machine initiating the event and the event type. The target virtual machine is used to subsequently retrieve data operation instructions corresponding to the IO event, and the event type is used for specific read or write operations. The system polls the ioeventfd using epoll. When a readable event `epollin` is detected, after determining the event type to be an IO event, the first read / write thread in the IO event read / write thread pool retrieves the data operation instructions corresponding to the IO event. The system is able to retrieve the data operation instructions corresponding to the IO event because the target virtual machine initiating the IO event has been identified beforehand. The system accesses the target virtual machine's memory and retrieves its owner identifier. The owner identifier identifies the specific location of the data operation instructions corresponding to the current IO event in the virtual machine's virtual memory, thus allowing direct retrieval of the data operation instructions. Following this, based on the specific data operation instructions obtained, the simulation operation corresponding to the data operation instructions is executed from the virtual hard disk where the corresponding operation is to be performed, the simulation operation result is generated, and the simulation operation result is forwarded to the target virtual machine through KVM, thus completing the processing of a virtual machine simulation event.
[0038] As described above, the system acquires IO events through KVM, obtains data operation instructions using the IO read / write thread pool, executes specific operations based on these instructions, and returns simulated operation results—all within kernel mode. Because this process runs entirely in kernel mode, it avoids the context switching present in related technologies where data transmission instructions first pass through user mode and then to kernel mode. This reduces the overhead of system calls in handling IO events, thus resolving the issue of significant system call overhead in QEMU-Virtio type virtual machines used in high-speed SSD storage applications. Since this method does not bypass kernel-mode block devices, such as solid-state drives (SSDs), to user space like the Vhost-User approach represented by SPDK, it maintains the same level of functional completeness as QEMU-Virtio. Vhost-User, by bypassing kernel-mode block devices, cannot implement some functions, such as snapshots. To use these functions on top of Vhost-User, new interfaces, drivers, and protocols need to be adapted separately. Therefore, when interfacing with new hardware or new SDS (Single Depth Semiconductor Devices) and other kernel-mode block devices, this method, using the QEMU-Virtio interface, driver, and protocol, achieves performance comparable to Vhost-User. Furthermore, by using the more general-purpose QEMU-Virtio interface, driver, and protocol, it reduces the complexity of interfacing with new kernel-mode block devices and lowers the adaptation difficulty.
[0039] In an optional example, if the system obtains the operation instructions corresponding to the IO event through the IO event read / write thread pool, and this is done through the kernel-level virtual machine KVM, then the security and reliability of the thread pool's acquisition of virtual machine data can be ensured, avoiding unauthorized access. This guarantees the accuracy and data consistency of the IO event read / write thread pool when obtaining the operation instructions corresponding to the IO event. Therefore, based on the aforementioned embodiments, the method may further include the following method steps, see details below. Figure 4 As shown, when the event type is determined to be an IO event, the first read / write thread in the IO event read / write thread pool obtains the data operation instructions corresponding to the IO event, including: Step S401: Use the first read / write thread to send an operation command request to the target virtual machine via KVM.
[0040] Step S402: Receive the data operation command corresponding to the operation command acquisition request from the target virtual machine forwarded by KVM.
[0041] Specifically, the system uses the first read / write thread to send an operation instruction retrieval request to the target virtual machine via KVM. Since the system has previously obtained the owner identifier of the IO event using any read / write thread in the IO event read / write thread pool, it can switch to the memory context of the target virtual machine corresponding to that owner identifier to retrieve the data operation instructions corresponding to the IO event. Subsequently, because the data operation instructions need to pass through KVM to be transmitted from the target virtual machine to the system's IO event read / write thread pool, the system receives the data operation instructions forwarded by KVM.
[0042] In the above approach, when the system obtains the operation instructions corresponding to the IO event through the IO event read / write thread pool, it goes through the kernel-mode virtual machine KVM, which can ensure the security and reliability of the thread pool in obtaining virtual machine data, avoid unauthorized access, and achieve accuracy and data consistency when the IO event read / write thread pool obtains the operation instructions corresponding to the IO event.
[0043] In an alternative example, based on the above embodiments, i performs a simulated operation corresponding to the data operation instructions in the virtual hard disk to generate the simulated operation result, specifically including: Step a: Release the first read / write thread, call io_uring to execute the simulation operation corresponding to the data operation instruction, and generate the simulation operation result.
[0044] Specifically, the first read / write thread releases itself after acquiring the data operation instructions corresponding to the I / O event. This can be achieved through methods such as natural termination or automatic reclamation of its stack memory, handles, and other resources by the system. Afterward, the system uses the io_uring interface to convert the data operation instructions handled by the first read / write thread into asynchronous tasks. The kernel then performs simulated operations corresponding to the data operation instructions in the background and generates the simulated operation results.
[0045] In one alternative example, after generating the simulation results, the simulation results need to be sent to the target virtual machine.
[0046] In a specific example, when the read / write operation type is read, the system reads data at the read / write operation address of the virtual hard disk and forwards the read data (i.e. the simulated operation result) to the memory of the corresponding target virtual machine through KVM according to the owner identifier, thus completing the simulation operation result forwarding to the target virtual machine through KVM.
[0047] Since the first read / write thread has completed its task after obtaining the data operation instructions corresponding to the IO event, releasing the first read / write thread in a timely manner after use can avoid the thread blocking and resource waste caused by the first read / write thread needing to perform operations on the virtual hard disk synchronously, and can also reduce the system's operating burden.
[0048] As a system call interface, io_uring allows the system to submit an IO request through a thread, enabling the first read / write thread to return to handle other request tasks, thereby improving the efficiency of IO read / write and reducing resource overhead.
[0049] In an alternative example, based on the foregoing embodiments, before calling io_uring to execute the simulation operation corresponding to the data operation instruction and generating the simulation operation result, this method further includes the following steps: Step b1: Identify the data type of the data to be operated on, corresponding to the data operation instruction.
[0050] In one specific embodiment, the data type is determined based on a combination of data function and data feature fingerprint.
[0051] The data functions include one or more of the following: file metadata, database redo logs, dirty data pages of the database, application code, and video stream data; the data feature fingerprint includes one or more of the following: data access patterns, data block size, and data sources.
[0052] For example, the data function of the first data type is file metadata, and the data feature fingerprint is the data access pattern; the data function of the second data type is database redo log, and the data feature fingerprint is the data block size.
[0053] Step b2: Determine the execution priority of the data to be operated on based on the data type.
[0054] Specifically, the execution priority of the data to be operated on is determined according to the preset priority strategy.
[0055] The specific preset priority strategies are as follows: When the data function of the data to be operated on is the database redo log, in order to ensure low latency and high reliability, the data to be operated on is determined to be high priority data. Alternatively, when the data function of the data to be operated on is a dirty data page in the database, in order to balance persistence efficiency and resource consumption, the data to be operated on is determined to be medium priority data. Alternatively, when the data function of the data to be operated is video stream data, since a certain delay can be allowed but continuous transmission is required, the data to be operated is determined to be low-priority data. Alternatively, when the data function of the data to be operated on is file metadata or application code snippets, since the I / O operations are frequent but the data volume is small, the data to be operated on is determined to be lightweight data.
[0056] Step b3: Based on the execution priority, determine the target io_uring that matches the execution priority, so that the first read / write thread can be released and the target io_uring can be called to perform the simulated operation corresponding to the data operation instruction.
[0057] Specifically, for high-priority data, a priority target io_uring is matched. Since the priority target io_uring uses a larger circular queue capacity and is bound to a CPU core, it can prioritize the processing of its submitted IO requests during kernel scheduling, thus avoiding blocking.
[0058] Alternatively, for medium-priority data, match the general target io_uring, which employs a balanced queue size and scheduling strategy; Alternatively, for low-priority data, match low-priority target io_uring. Since the resource usage of low-priority target io_uring is limited by the system to avoid affecting core business, or use batch submission mode to optimize throughput. Alternatively, for lightweight data, a shared target io_uring can be reused, which is any io_uring that is the last remaining io_uring among all io_uring.
[0059] In the above approach, the execution priority of the data to be operated on is determined based on the data type. Different priority io_uring values are assigned to different priority data. This reduces resource contention and improves the orderliness of the simulated operations. Furthermore, the priority of releasing the first read / write thread varies depending on the execution priority. Threads executing high-priority data need to be released immediately, allowing the thread pool to quickly reclaim resources and promptly process the next high-priority task. Threads executing low-priority data, however, are allowed a certain delay and can be released after completing the corresponding data operation instructions. This avoids limiting the long-term occupation of threads without affecting core operations. Based on this, by identifying data types and clarifying the adaptation rules for data operations, the problem of simulation operation failure or inefficiency caused by type mismatch is solved, improving the success rate and efficiency of simulation operations. Moreover, by matching the target io_uring value to the data to be operated on, thread resources can be prioritized for high-value tasks, reducing thread pool resource waste and improving system efficiency.
[0060] In an optional example, although when calling io_uring to execute the simulation operation corresponding to the data operation instruction, and writing the simulation operation result to the virtual machine after generating the simulation operation result, if the virtual machine does not receive the completion information sent to the virtual machine by the system through KVM, the virtual machine will idle, resulting in wasted resources.
[0061] Therefore, in related technologies, after the simulated operation corresponding to the data manipulation instruction is executed through io_uring, the completion information is fed back using an interrupt notification. However, interrupt handling triggers a context switch between user mode and kernel mode, and may also cause delays due to interrupt queue queuing and CPU scheduling conflicts, resulting in low overall notification efficiency. Therefore, to avoid the problem of low notification efficiency caused by interrupt handling, the virtual machine simulation system includes a response feedback thread pool. This method also includes the following steps: Step c1 involves periodically reading the operation status in the target io_uring using the response feedback thread in the response feedback thread pool.
[0062] The operation status is used to indicate whether the simulation operation corresponding to the data operation instruction has been completed.
[0063] Specifically, the response feedback thread in the response feedback thread pool polls the simulation operation results. Once the system receives the simulation operation result through the response feedback thread, it determines that the current target io_uring operation status is completed.
[0064] Step c2: When it is determined from the operation status that the simulated operation corresponding to the data operation instruction has been completed, the operation status indicating that the simulated operation corresponding to the data operation instruction has been completed is fed back to the target virtual machine through KVM via the response feedback thread.
[0065] Specifically, when the system polls the target io_uring through the response feedback thread in the response feedback thread pool and learns that the operation status of the target io_uring is completed, it will use the response feedback thread to write the information of the completed data operation instruction of the target io_uring into the specific location of the target virtual machine memory in the form of interrupt injection based on the owner identifier.
[0066] In the above approach, the system uses a response feedback thread pool to specifically poll the operation status of the target io_uring. Once the operation status of the target io_uring is polled to be completed, the system uses KVM to write the information that the data operation instruction has been completed to the specific location of the target virtual machine memory. This avoids the problems of context switching and low notification efficiency in interrupt notifications in related technologies, and improves the efficiency of interaction between the system and the virtual machine.
[0067] In an optional example, since this method uses multiple independent thread pools, if the number of threads is set to ensure that each thread pool can handle the maximum I / O read / write pressure, then when the I / O read / write pressure is low, some threads in the thread pool may be idle, excessively consuming system resources. Therefore, this method further includes the following steps: Step d1: Periodically calculate the average load of each thread pool in the virtual machine simulation system.
[0068] Step d2: When it is determined that the average load of the target thread pool is greater than the first preset threshold, increase the number of threads in the target thread pool.
[0069] The target thread pool is any thread pool included in the virtual machine simulation system.
[0070] Alternatively, in step d3, when it is determined that the average load in the target thread pool is less than the second preset threshold, the number of threads in the target thread pool is reduced.
[0071] The second preset threshold is less than the first preset threshold.
[0072] Specifically, when the average load in any thread pool exceeds a first preset threshold, a new thread is created and added to the thread pool to share the workload. Alternatively, when the average load in any thread pool is less than a second preset threshold, the idle threads in the thread pool are destroyed.
[0073] In a specific example, the first preset threshold is 70%, and the second preset threshold is 40%. When the average load in any thread pool is greater than 70%, a new thread is created and added to the thread pool to share tasks. When the average load in any thread pool is less than 40%, idle threads in the thread pool are destroyed. This ensures that the thread pool load is not too high, which may lead to task queuing, response delay, or even timeout, as well as system lag caused by resource exhaustion. It also avoids the problem of wasted thread resources due to a large number of threads and a low average load in the thread pool.
[0074] In an optional example, a differentiated threshold strategy can be formulated based on the system call frequency differences of each thread pool. For example, for the polling thread pool with a high system call frequency, a lower second preset threshold can be configured to strengthen the thread destruction conditions, i.e., raise the thread retention threshold and reduce the overhead of frequent destruction and reconstruction. At the same time, a lower first preset threshold can be configured to relax the thread creation conditions, i.e., speed up thread expansion and adapt to high call volume requirements, so as to achieve dynamic matching between thread resources and call load. For example, based on the above embodiment, the first preset threshold for the polling thread pool can be set to 60%, and the second preset threshold can be set to 25%. Based on this, the setting of the first or second preset threshold for other thread pools is free and independent, and specific values can be set according to the specific application scenario to adapt to the current application scenario, without too many restrictions.
[0075] In the above method, in order to further save resources, the number of threads in the thread pool is dynamically scaled up or down as needed. By applying a first preset threshold and a second preset threshold, the number of threads in the thread pool is judged according to whether the average load of the thread pool is greater than the first preset threshold or less than the second preset threshold. Threads in the thread pool are dynamically created or destroyed to solve the problem of excessive system resource consumption caused by the inability to dynamically change the number of threads in related technologies, thereby saving system resource consumption.
[0076] In an optional example, in the above embodiments, the number of threads in any thread pool is greater than or equal to 1 and less than or equal to 4, so as to ensure that at least one thread can handle the task corresponding to the thread pool at any time, and there will not be too many threads, so as to ensure a certain task processing capacity while reducing the occupation of system resources.
[0077] In a specific example, such as Figure 5 As shown, Figure 5 A schematic diagram illustrating the principle of a virtual machine-simulated event handling process provided for the method of this application is shown below: In user space, there are n virtual machines. The system uses a polling thread pool to initiate (1) polling IO events for multiple virtual machines through KVM. Then, if the target virtual machine has an IO event, the system first uses the threads in the polling thread pool to send a notification to the IO event read / write thread pool through the data stream, which is to execute step (2) to notify the IO event. After that, the system uses KVM to obtain IO operation data from the virtual machine with the IO event, which is to execute step (3) to obtain IO operation data. When a specific data operation instruction is obtained, the system uses io_uring to execute the simulation operation corresponding to the data operation instruction in the kernel block device (i.e., virtual hard disk), which is to execute (4a) read / write block device and / or execute (4b) read / write file. Then, the result of the simulation operation is forwarded to the target virtual machine through KVM, which is to execute step (5) to write back the IO operation result. When (4a) reading and writing to a block device and / or (4b) reading and writing to a file is completed, the system uses the response feedback thread in the response thread pool to periodically read (e.g., by polling) the operation status of the io_uring that processes the data operation instruction. If the operation status determines that the simulated operation corresponding to the data operation instruction has been completed, the operation status used to indicate that the simulated operation corresponding to the data operation instruction has been completed is fed back to the target virtual machine through KVM via the response feedback thread, thereby completing an IO read and write event.
[0078] This allows for a comparison of the three different types of virtual hard disk implementations, and the comparison results are shown in Table 1: Table 1 Comparison of different types of virtual hard disk implementations
[0079] As shown in Table 1, QEMU-Virtio's performance is relatively low due to the overhead of system calls, which is a major factor hindering the improvement of virtual machine performance. However, because the kernel-mode block devices are well preserved and have relatively complete functions, and QEMU-Virtio only needs to provide the corresponding device model in accordance with the Virtio specification without modifying the QEMU core logic, the system interacts with Virtio devices through standard system calls, thereby shielding the underlying hardware differences and implementation complexity and enabling rapid integration.
[0080] Vhost-User improves performance by bypassing the kernel-mode block device in user space and directly accessing hardware or third-party SDS. It combines technologies such as polling, large page memory, zero-copy data, and multi-core parallel programming to support high-performance storage devices. However, because it bypasses the kernel-mode block device in user space, it cannot perform the functions that were originally in the kernel-mode block device, such as snapshots and backups. Furthermore, when interfacing with new distributed file systems and distributed storage, the file interface is more compatible with QEMU, so the driver must be re-adapted, which makes the adaptation difficult.
[0081] The method provided in this application ensures complete functionality without requiring frequent context switching because it does not bypass kernel-mode block devices. Furthermore, when interfacing with new hardware or new SDS, no modification to the kernel core code is required. Adaptation development is only needed based on the existing stable infrastructure of the kernel, such as interfaces, driver frameworks, and protocol stacks. The kernel uses these mature components to shield the differences in underlying hardware, the complexity of protocols, and interaction details, thereby simplifying the interfacing process.
[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0083] Embodiments of this application also provide a virtual machine simulation event processing apparatus. The apparatus is applied to a virtual machine simulation system, which establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. See details... Figure 6 As shown, the device includes: The receiving module 601 is used to receive events sent by KVM using the first polling thread in the polling thread pool. The first polling thread is any polling thread in the polling thread pool. The processing module 602 is used to analyze the event and determine the target virtual machine that initiated the event and the event type; The acquisition module 603 is used to acquire the data operation instructions corresponding to the IO event by using the first read / write thread in the IO event read / write thread pool when the processing module determines that the event type is an IO event. The first read / write thread is any read / write thread in the read / write thread pool. The processing module 602 is also used to determine the virtual hard disk to be operated on according to the data operation instruction; to perform the simulation operation corresponding to the data operation instruction in the virtual hard disk and generate the simulation operation result; Forwarding module 604 is used to forward the operation results to the target virtual machine via KVM.
[0084] In an optional example, obtaining module 603 specifically includes: The sending submodule is used to send operation instructions and request acquisition to the target virtual machine via KVM using the first read / write thread; The receiving submodule is used to receive data operation instructions corresponding to the operation instruction acquisition request from the target virtual machine forwarded by KVM.
[0085] In an optional example, the processing module 602 is specifically used to release the first read / write thread, call io_uring to execute the simulation operation corresponding to the data operation instruction, and generate the simulation operation result.
[0086] In an optional example, the device further includes: an identification module 605 and a determination module 606; The identification module 605 is used to identify the data type of the data to be operated corresponding to the data operation instruction; The determination module 606 is used to determine the execution priority of the data to be operated on based on the data type; and to determine the target io_uring that matches the execution priority based on the execution priority, so as to release the first read / write thread later. The processing module 602 is also used to call the target io_uring to perform the simulation operation corresponding to the data operation instruction.
[0087] In an optional example, the data type identified by the identification module 605 is determined based on data function or data feature fingerprint, wherein the data feature fingerprint includes one or more of data access mode, data block size, and data source.
[0088] In an optional example, the device further includes: a reading module 607 and a feedback module 608; The reading module 607 is used to periodically read the operation status in the target io_uring using the response feedback thread in the response feedback thread pool. The operation status is used to indicate whether the simulated operation corresponding to the data operation instruction has been completed. The feedback module 608 is used to send the operation status indicating that the simulation operation corresponding to the data operation instruction has been completed to the target virtual machine through the response feedback thread when it is determined from the operation status that the simulation operation corresponding to the data operation instruction has been completed.
[0089] In an optional example, the device also includes: a statistics module 609; Statistics module 609 is used to periodically calculate the average load of each thread pool in the virtual machine simulation system. The processing module 602 is further configured to, when it is determined that the average load of the target thread pool is greater than a first preset threshold, increase the number of threads in the target thread pool, wherein the target thread pool is any thread pool included in the virtual machine simulation system; or, when it is determined that the average load in the target thread pool is less than a second preset threshold, decrease the number of threads in the target thread pool, wherein the second preset threshold is less than the first preset threshold.
[0090] The description of the features of the virtual machine simulation event processing device provided in this application can be found in the relevant description of the virtual machine simulation event processing method, which will not be repeated here.
[0091] This application provides a virtual machine simulation event processing device. When the first polling thread in the polling thread pool receives an event sent by KVM, the event is analyzed to determine the target virtual machine initiating the event and the event type. The target virtual machine is used to subsequently obtain data operation instructions corresponding to the IO event, and the event type is determined for specific read or write operations. After determining the event type to be an IO event, the first read / write thread in the IO event read / write thread pool obtains the data operation instructions corresponding to the IO event. The system is able to obtain the data operation instructions corresponding to the IO event because the target virtual machine initiating the IO event has been identified beforehand. The system can directly obtain the data operation instructions by accessing the memory of the target virtual machine. Afterwards, based on the obtained specific data operation instructions, the simulated operation corresponding to the data operation instructions is executed from the virtual hard disk where the corresponding operation is to be performed, generating a simulated operation result. The simulated operation result is forwarded to the target virtual machine via KVM, thus completing the processing of one virtual machine simulation event.
[0092] As can be seen from the above method, the process of the system obtaining IO events through KVM, acquiring data operation instructions using the IO read / write thread pool, executing specific operations based on the data operation instructions, and returning simulated operation results all run in kernel mode. Since the above process all runs in kernel mode, it avoids the context switching that exists in related technologies where data transmission instructions first pass through user mode and then to kernel mode to transmit data operation instructions. This reduces the overhead of system call processing IO events, thus solving the problem of large system call overhead in the IO processing of QEMU-Virtio type virtual machines when applied to high-speed SSD hard disks in related technologies. Since this method does not bypass kernel-mode block devices, such as solid-state drives (SSDs), to user space like the Vhost-User approach represented by SPDK, this device is functionally complete, just like QEMU-Virtio. Vhost-User, due to bypassing kernel-mode block devices, cannot implement some functions, such as snapshots. To use these functions on top of Vhost-User, new interfaces, drivers, and protocols need to be adapted separately. Therefore, when interfacing with new hardware or new SDS (Single Demand System) kernel-mode block devices, this device, using QEMU-Virtio's interface, drivers, and protocols, achieves performance comparable to Vhost-User. Furthermore, by using the more general-purpose QEMU-Virtio interface, drivers, and protocols, it reduces the complexity of interfacing with new kernel-mode block devices and lowers the adaptation difficulty.
[0093] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described embodiments of the virtual machine simulation event handling method.
[0094] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the virtual machine simulation event handling method when it runs.
[0095] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0096] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the virtual machine simulation event handling method.
[0097] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0098] The foregoing has provided a detailed description of a virtual machine simulation event processing method, apparatus, device, and medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A virtual machine-simulated event handling method, characterized in that, The method is applied to a virtual machine simulation system, which establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. The method includes: When the first polling thread in the polling thread pool receives an event sent by the KVM, it analyzes the event to determine the target virtual machine that initiated the event and the event type. The first polling thread can be any polling thread in the polling thread pool. When the event type is determined to be an IO event, the first read / write thread in the IO event read / write thread pool is used to obtain the data operation instruction corresponding to the IO event, wherein the first read / write thread is any read / write thread in the read / write thread pool; The virtual hard disk to be operated on is determined according to the data operation instructions; Execute the simulation operation corresponding to the data operation instruction in the virtual hard disk, and generate the simulation operation result; The simulation results are forwarded to the target virtual machine via the KVM.
2. The method according to claim 1, characterized in that, When the event type is determined to be an IO event, the first read / write thread in the IO event read / write thread pool obtains the data operation instructions corresponding to the IO event, specifically including: The first read / write thread sends an operation instruction request to the target virtual machine through the KVM. Receive the data operation instruction corresponding to the operation instruction acquisition request, which is forwarded by the KVM from the target virtual machine.
3. The method according to claim 1, characterized in that, The step of performing a simulated operation corresponding to the data operation instruction in the virtual hard disk and generating a simulated operation result specifically includes: Release the first read / write thread, call io_uring to execute the simulation operation corresponding to the data operation instruction, and generate the simulation operation result.
4. The method according to claim 3, characterized in that, Before releasing the first read / write thread, calling io_uring to execute the simulated operation corresponding to the data operation instruction, and generating the simulated operation result, the method further includes: Identify the data type of the data to be operated corresponding to the data operation instruction; Based on the data type, determine the execution priority of the data to be operated on; Based on the execution priority, a target io_uring that matches the execution priority is determined, which is then used to release the first read / write thread and call the target io_uring to execute the simulated operation corresponding to the data operation instruction.
5. The method according to claim 4, characterized in that, The data type is determined based on data function or data feature fingerprint, wherein the data feature fingerprint includes one or more of the following: data access mode, data block size, and data source.
6. The method according to claim 5, characterized in that, The virtual machine simulation system includes a response feedback thread pool, and the method further includes: The response feedback thread in the response feedback thread pool periodically reads the operation status in the target io_uring, and the operation status is used to indicate whether the simulation operation corresponding to the data operation instruction has been completed; When it is determined from the operation status that the simulated operation corresponding to the data operation instruction has been completed, the operation status indicating that the simulated operation corresponding to the data operation instruction has been completed is fed back to the target virtual machine through the KVM via the response feedback thread.
7. The method according to any one of claims 1-4, characterized in that, The method further includes: The average load of each thread pool in the virtual machine simulation system is periodically calculated. When it is determined that the average load of the target thread pool is greater than a first preset threshold, the number of threads in the target thread pool is increased, wherein the target thread pool is any thread pool included in the virtual machine simulation system; or, When it is determined that the average load in the target thread pool is less than a second preset threshold, the number of threads in the target thread pool is reduced, wherein the second preset threshold is less than the first preset threshold.
8. A virtual machine-simulated event processing device, characterized in that, The device is applied to a virtual machine simulation system, which establishes communication connections with multiple virtual machines through a kernel-based virtual machine (KVM). The virtual machine simulation system includes a polling thread pool and an I / O event read / write thread pool. The device includes: The receiving module is used to receive events sent by the KVM using a first polling thread in the polling thread pool, wherein the first polling thread is any polling thread in the polling thread pool; The processing module is used to analyze the event and determine the target virtual machine that initiated the event and the event type; The acquisition module is used to acquire the data operation instructions corresponding to the IO event by using the first read / write thread in the IO event read / write thread pool when the processing module determines that the event type is an IO event. The first read / write thread is any read / write thread in the read / write thread pool. The processing module is further configured to determine the virtual hard disk to be operated on according to the data operation instruction; execute the simulation operation corresponding to the data operation instruction in the virtual hard disk and generate the simulation operation result; The forwarding module is used to forward the operation result to the target virtual machine through the KVM.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the virtual machine simulation event handling method as described in any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the virtual machine simulation event handling method as described in any one of claims 1 to 7.