Task processing method and device of virtualization system, equipment, medium and product

Abstract

The invention discloses a task processing method and device of a virtualization system, equipment, a medium and a product. The method comprises the steps that a front-end driver writes instruction information corresponding to a user operation instruction into a shared memory; storing a storage address and a data length of the instruction information in the shared memory to a target descriptor; storing the target descriptor into a first queue in a shared memory; the back-end device reads the target descriptor from the first queue and obtains a storage address and a data length; the back-end device reads the instruction information from the shared memory according to the storage address and the data length; the back-end device operates the block device according to the instruction information to obtain an operation result, and updates the operation result to the shared memory according to the storage address; and storing the target descriptor into a second queue in the shared memory, so that the front-end driver obtains the operation result from the shared memory. According to the embodiment of the invention, the adaptability of the virtualization system and the utilization rate of hardware resources can be improved.

Description

Technical Field

[0001] This application belongs to the field of virtualization technology, and in particular relates to a task processing method, apparatus, device, medium and product of a virtualization system. Background Technology

[0002] Virtualization technology is a technical system that uses software or hardware means to abstract and isolate the hardware resources, operating system or application of a computer system, transforming a single physical resource into multiple logically independent virtual resource instances, in order to achieve efficient resource allocation, parallel processing of multiple tasks and secure isolation.

[0003] In related technologies, when applying virtualization technology, different IoT devices and applications may run on different operating systems, and their interfaces and protocols may vary, making the adaptation and adjustment of virtualization technology development complex. Furthermore, the storage requirements of different IoT devices vary significantly, and static allocation models lead to polarized resource utilization, resulting in resource utilization that does not meet demand.

[0004] Therefore, how to improve the adaptability of virtualization systems and the utilization rate of hardware resources is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a task processing method, apparatus, device, medium, and product for a virtualization system, which can improve the adaptability of the virtualization system and the utilization rate of hardware resources.

[0006] In a first aspect, embodiments of this application provide a task processing method for a virtualization system. The virtualization system includes a front-end driver based on a first operating system, a back-end device based on a second operating system, and shared memory. The first operating system is different from the second operating system. The method includes: upon receiving a user operation instruction, the front-end driver writes instruction information corresponding to the user operation instruction into the shared memory; the front-end driver stores the storage address and data length of the instruction information in the shared memory into a target descriptor, wherein the target descriptor is an unoccupied descriptor among multiple descriptors in the shared memory; the front-end driver stores the target descriptor into a first queue in the shared memory; the back-end device reads the target descriptor from the first queue and parses the target descriptor to obtain the storage address and data length; the back-end device reads instruction information from the shared memory according to the storage address and data length; the back-end device performs an operation on the block device according to the instruction information, obtains the operation result, and updates the operation result to the shared memory according to the storage address; the back-end device stores the target descriptor into a second queue in the shared memory, so that the front-end driver can obtain the operation result from the shared memory according to the target descriptor in the second queue.

[0007] In one implementation, when the front-end driver receives a user operation instruction, it writes the instruction information corresponding to the user operation instruction into shared memory, including: the front-end driver determining the data operation type corresponding to the user operation instruction; and writing the instruction information into shared memory according to the data storage structure corresponding to the data operation type.

[0008] In one embodiment, the data operation type includes a non-read / write operation type, wherein the first data structure corresponding to the non-read / write operation type includes at least a message header, and the message header includes at least a data operation type area, an operation address offset area, and a data length area; writing instruction information into shared memory according to the data storage structure corresponding to the data operation type includes: determining the first target sub-operation type corresponding to the user operation instruction according to multiple first sub-operation types corresponding to the non-read / write operation type, and writing the first target sub-operation type into the data operation type area; writing the block device sector address in the instruction information into the operation address offset area; determining the first structure data length of the instruction information stored in the first data structure, and writing the first structure data length into the data length area.

[0009] In one embodiment, the data operation type includes a read / write operation type, wherein the second data structure corresponding to the read / write operation type includes at least a message header and a message body. The message header includes at least a data operation type area, an operation address offset area, and a data length area, and the message body includes at least an operation data area. Writing instruction information into shared memory according to the data storage structure corresponding to the data operation type includes: dividing the operation data according to a preset data size to obtain multiple sub-operation data, and determining the sub-sector address and sub-data length corresponding to each sub-operation data; determining the second target sub-operation type corresponding to the user operation instruction based on the multiple second sub-operation types corresponding to the read / write operation type; for each sub-operation data, writing the second target sub-operation type into the data operation type area corresponding to that sub-operation data; for each sub-operation data, writing the sub-block device sector address corresponding to that sub-operation data into the operation address offset area corresponding to that sub-operation data; for each sub-operation data, determining the second structure data length of the sub-operation data stored in the second data structure, and writing the second structure data length into the data length area corresponding to that sub-operation data; and for each sub-operation data, writing the sub-operation data into the operation data area.

[0010] In one embodiment, after the front-end driver stores the target descriptor in a first queue in shared memory, the method further includes: the front-end driver sending a first interrupt request to the back-end device, so that the back-end device reads the target descriptor from the first queue in shared memory after receiving the first interrupt request; after the back-end device stores the target descriptor in a second queue in shared memory, the method further includes: the back-end device sending a second interrupt request to the front-end driver, so that the front-end driver obtains the operation result from shared memory based on the target descriptor in the second queue.

[0011] In one embodiment, the method further includes: the front-end driver releasing the target operation descriptor from the second queue in response to obtaining the operation result.

[0012] In one implementation, the front-end driver releases the target descriptor from the second queue in response to the front-end driver obtaining the operation result, including: the front-end driver releases the target descriptor from the second queue through a mutex lock.

[0013] In one embodiment, after the front-end driver stores the target descriptor into a first queue in shared memory, the method further includes: the back-end device sending a first semaphore to an asynchronous thread in the back-end device to indicate the target descriptor to be processed; after the back-end device stores the target descriptor into a second queue in shared memory, the method further includes: the front-end driver sending a second information quantity to an asynchronous thread in the front-end driver to indicate the result of a read operation; and in response to the front-end driver obtaining the operation result, releasing the target descriptor from the second queue includes: the front-end driver sending a third information quantity to an asynchronous thread in the front-end driver to release the target descriptor.

[0014] In one embodiment, the method further includes: the front-end driver writing instruction information corresponding to the user operation instruction into shared memory via a spinlock; and the back-end device updating the operation result to shared memory via a spinlock.

[0015] Secondly, embodiments of this application provide a task processing apparatus for a virtualization system. The virtualization system includes a front-end driver based on a first operating system, a back-end device based on a second operating system, and shared memory. Furthermore, the first operating system is different from the second operating system. The apparatus includes: The first operation module is used by the front-end driver to write the instruction information corresponding to the user operation instruction into the shared memory when the user operation instruction is received. The first storage module is used by the front-end driver to store the storage address and data length of the instruction information in the shared memory to the target descriptor, wherein the target descriptor is an unoccupied descriptor among multiple descriptors in the shared memory; The second storage module is used by the front-end driver to store the target descriptor into the first queue in shared memory; The parsing module is used by the backend device to read the target descriptor from the first queue and parse the target descriptor to obtain the storage address and data length. The read module is used by the backend device to read instruction information from shared memory based on the storage address and data length; The second operation module is used by the backend device to operate the block device according to the instruction information, obtain the operation result, and update the operation result to the shared memory according to the storage address; The third storage module is used by the backend device to store the target descriptor into the second queue in the shared memory, so that the frontend driver can obtain the operation result from the shared memory based on the target descriptor in the second queue.

[0016] Thirdly, embodiments of this application provide a task processing device for a virtualization system, the device including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the task processing method of the virtualization system in the first aspect or any embodiment of the first aspect.

[0017] Fourthly, a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the task processing method of the virtualization system in the first aspect or any embodiment of the first aspect.

[0018] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a task processing method of a virtualization system as described in the first aspect or any embodiment of the first aspect.

[0019] The task processing method, apparatus, device, medium, and product of the virtualization system in this application embodiment ensure that the instruction information corresponding to user operation instructions is always located in shared memory when transferred between the front-end and back-end, avoiding the overhead of copying data multiple times between operating system kernels. This achieves compatibility requirements between different systems and improves the adaptability of virtualization technology across different systems. Furthermore, in this application embodiment, the system efficiently and collaboratively solves the problems of resource idleness and resource shortage through a descriptor circular reuse mechanism and asynchronous queue communication (including a first queue and a second queue). Specifically, after the front-end driver obtains the operation result from the second queue, it immediately releases the descriptor. This step ensures that limited descriptor resources can be quickly reclaimed and reused by subsequent requests, fundamentally preventing processing stagnation due to resource exhaustion and resolving the hidden danger of resource shortage. Simultaneously, interrupt-based asynchronous notification allows the front-end and back-end to process tasks in parallel without mutual blocking or waiting, ensuring continuous and efficient utilization of system resources and avoiding resource idleness. The combination of these two aspects constructs a virtualization system with efficient resource flow, stable performance, and the ability to support high-concurrency processing. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a task processing method for a virtualization system according to an embodiment of this application is shown; Figure 2 A flowchart illustrating a task processing method for a virtualization system provided in one embodiment of this application is shown. Figure 3 A schematic diagram of the architecture of a descriptor provided in one embodiment of this application is shown; Figure 4 This application illustrates a schematic diagram of the architecture of a virtualization system provided in one embodiment. Figure 5 A flowchart illustrating a task processing method for a virtualization system provided in one embodiment of this application is shown. Figure 6 This diagram illustrates the correspondence between the split structure and descriptors provided in one embodiment of this application. Figure 7 A schematic flowchart of a read / write operation provided in one embodiment of this application is shown; Figure 8 This is a schematic diagram of the structure of a task processing device for a virtualization system provided in another embodiment of this application; Figure 9 This is a schematic diagram of the structure of a task processing device of a virtualization system provided in another embodiment of this application. Detailed Implementation

[0022] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0024] Virtualization technology is a technical system that uses software or hardware means to abstract and isolate the hardware resources (such as CPU, memory, storage, network), operating system, or applications of a computer system, transforming a single physical resource into multiple logically independent virtual resource instances, in order to achieve efficient resource allocation, parallel processing of multiple tasks, and secure isolation.

[0025] Among related technologies, virtualization can be hardware virtualization based on hypervisors, operating system virtualization utilizing Linux kernel features (such as Docker containers), application virtualization decoupling applications from the underlying environment, and virtualization integration of network and storage resources. Key technologies in virtualization involve CPU instruction emulation and hardware acceleration (such as Intel VT-x), memory address translation (EPT or NPT), and I / O device paravirtualization (VirtIO), etc. It is widely used in scenarios such as building cloud computing resource pools, integrating heterogeneous systems on edge devices, development and testing sandbox environments, and multi-tenant security isolation. Furthermore, virtualization technology continues to evolve towards hardware-assisted acceleration, AI-driven resource scheduling, and the integration of heterogeneous computing.

[0026] Furthermore, when applying virtualization technology, the diversity of the Internet of Things (IoT) leads to significant variations in the product forms and deployments involved in both hardware and software. Numerous different storage devices may have different interfaces and protocols, posing challenges to their access and management. Simultaneously, different IoT devices and applications may run on different operating systems, increasing the workload and complexity of development and compatibility, and also raising the likelihood of errors during application. Moreover, due to the significant differences in device storage needs, traditional static allocation models result in a polarization of resource utilization; some devices experience idle and wasted storage, while others suffer from performance bottlenecks or data loss risks due to insufficient resources.

[0027] Therefore, how to improve the adaptability of virtualization systems and the utilization rate of hardware resources is a technical problem that urgently needs to be solved by those skilled in the art.

[0028] To address the problems of the prior art, embodiments of this application provide a task processing method, apparatus, device, medium, and product for a virtualization system. The task processing method for the virtualization system provided in this application embodiment will be described first below.

[0029] Figure 1 A flowchart illustrating a task processing method for a virtualization system according to an embodiment of this application is shown. The virtualization system includes a front-end driver based on a first operating system, a back-end device based on a second operating system, and shared memory. The first operating system is different from the second operating system, and the first and second operating systems share the same physical storage device. Further, as... Figure 1 As shown, the task processing method of the virtualization system includes the following steps S110-S170: S110: When the front-end driver receives a user operation command, it writes the command information corresponding to the user operation command into the shared memory.

[0030] For example, the front-end driver can run on a first operating system that can receive requests from upper-layer applications. The first operating system can be a guest operating system running the corresponding application. For instance, the first operating system can be a real-time operating system.

[0031] For example, user operation instructions include corresponding instruction information. In one example, the instruction information may include read, write, write zero, synchronize, and delete, etc.

[0032] For example, shared memory can be a physical memory region that can be accessed simultaneously by a first operating system and a second operating system.

[0033] For example, when the front-end driver receives a user operation command from an upper-layer application, it writes the command information corresponding to the user operation command into shared memory. In one example, an application in a first operating system requests to read data from a file on a block device. After receiving the read request, the front-end driver writes the command information corresponding to the read request into shared memory.

[0034] S120, the front-end driver stores the instruction information in shared memory and the data length in the target descriptor.

[0035] The target descriptor is an unused descriptor among multiple descriptors in shared memory.

[0036] For example, the front-end driver can determine unoccupied target descriptors from the descriptor queue, and write the instruction information's storage address in shared memory and data length into the target descriptor.

[0037] In some optional embodiments, the front-end driver uses a spinlock to write the instruction information corresponding to the user operation command into shared memory. It is understood that using a spinlock to request the target descriptor avoids concurrent acquisition of the target descriptor, thus preventing resource corruption. The front-end driver can release the spinlock after completing the writing of the target descriptor.

[0038] For example, a descriptor can be used to identify user operation instructions. There is a one-to-one correspondence between the descriptor and the user operation instruction.

[0039] For example, each descriptor can have an index to a target descriptor, which can be used to uniquely identify the descriptor. In one example, the index corresponding to the target descriptor could be the target index.

[0040] S130, The front-end driver stores the target descriptor into the first queue in shared memory.

[0041] For example, the first queue can be used to store descriptors for requests sent by the front-end driver to the back-end device.

[0042] For example, the target index corresponding to the target descriptor can be stored in the first queue.

[0043] In some alternative embodiments, the front-end driver sends a first interrupt request to the back-end device, so that the back-end device, upon receiving the first interrupt request, reads the target descriptor from a first queue in shared memory. It is understood that the front-end driver and the back-end device can communicate via interrupts (i.e., inter-core communication), thereby enabling the back-end device to respond quickly to user operation commands and improving data processing efficiency.

[0044] For example, the front-end driver can use a spin lock to store the target descriptor into a first queue in shared memory and release the lock after storage.

[0045] In some alternative embodiments, the backend device may send a first semaphore to an asynchronous thread of the backend device to indicate the existence of a target descriptor to be processed. The first semaphore can be used to indicate to the asynchronous thread of the backend device that a target descriptor exists to be processed. It is understood that semaphores can be used to control access to shared resources by multiple threads, ensuring the order of resource access.

[0046] In this process, after receiving the first interrupt request from the front-end device, the back-end device can send a first semaphore to the asynchronous thread in the back-end device to prompt the asynchronous thread to process the target descriptor. That is, the first semaphore can be used to implement the callback processing of the back-end device's execution interrupt or polling. S140, the back-end device reads the target descriptor from the first queue and parses the target descriptor to obtain the storage address and data length.

[0047] For example, the backend device can be a driver or service process installed in a second operating system. It can receive requests from the frontend driver and operate the actual physical hardware. The second operating system can be a general-purpose operating system.

[0048] For example, the backend device can read the target descriptor from the first queue after receiving the first interrupt request. Alternatively, the backend device can also read the first queue in a polling manner to obtain the target descriptor.

[0049] For example, the backend device can read the target index corresponding to the target descriptor from the first queue and find the corresponding target descriptor from the descriptor queue in shared memory. It then parses the target descriptor to obtain the storage address and data length of the instruction information in shared memory.

[0050] S150: The backend device reads instruction information from the shared memory based on the storage address and data length.

[0051] For example, the backend device can read data of the specified length from a storage address in shared memory. It can then parse the read data to obtain the corresponding instruction information.

[0052] S160: The backend device operates on the block device according to the instruction information, obtains the operation result, and updates the operation result to the shared memory according to the storage address.

[0053] For example, a storage device can be divided into multiple block devices. The instruction information can include the target block device on which the instruction acts. Furthermore, the backend device can perform operations on the target block device according to the instruction information to obtain the operation result.

[0054] For example, the corresponding operation result can be updated to the shared memory based on the operation result corresponding to the user's operation instruction.

[0055] In one example, the update result can be copied to the shared memory region corresponding to the storage address.

[0056] In another example, for a read request, the read data can be stored in shared memory, and for a write request, the result of whether the write request was successful can be updated in shared memory.

[0057] In some optional embodiments, the backend device updates the operation result to shared memory using a spinlock. It is understood that updating the operation result using a spinlock can avoid resource corruption issues. The backend device can release the spinlock after completing the update.

[0058] S170. The backend device stores the target descriptor in the second queue in the shared memory so that the frontend driver can obtain the operation result from the shared memory based on the target descriptor in the second queue.

[0059] For example, the second queue can be used to store descriptors that have been processed and returned by the backend device to the frontend driver.

[0060] For example, the target index corresponding to the target descriptor can be stored in the second queue.

[0061] For example, the front-end driver can obtain the target descriptor from the second queue, thereby obtaining the processing result of the back-end device on the user's operation command.

[0062] In some optional embodiments, the backend device sends a second interrupt request to the frontend driver, enabling the frontend driver to retrieve the operation result from shared memory based on the target descriptor in the second queue. It is understood that message passing between the frontend driver and the backend device can be achieved through inter-core communication, thereby enabling the frontend driver to quickly respond and retrieve the operation result, improving data processing efficiency.

[0063] In some alternative embodiments, the front-end driver sends a second semaphore to its asynchronous thread to indicate the result of the read operation. This second semaphore can be used to indicate to the asynchronous thread that a processing result exists. It is understood that semaphores can be used to control multi-threaded access to shared resources, ensuring the orderliness of resource access. Furthermore, after the front-end driver obtains the operation result, it can release the target operation descriptor from the second queue. This allows the descriptors to be reused, i.e., releasing descriptors makes the descriptor pool a renewable resource. Each release creates conditions for the next new request, enabling the system to continuously process tasks, thereby ensuring long-term stability and availability.

[0064] In some alternative embodiments, the front-end driver releases the target descriptor from the second queue via a mutex lock, thereby avoiding concurrent access and ensuring the orderliness of resource access.

[0065] In one example, the front-end driver can release the instruction information of the target descriptor stored in shared memory.

[0066] In one example, the backend device can implement context switching for message processing using a work queue. When it receives an inter-core interrupt from the frontend driver, it places the actual operation part into the work queue for implementation, and the interrupt returns immediately, thus ensuring that excessively long operations are not performed during the interrupt.

[0067] In some alternative embodiments, the front-end driver sends a third semaphore to an asynchronous thread within the front-end driver to release the target descriptor. This third semaphore can be used to prompt the asynchronous thread of the front-end driver to release the target descriptor. It is understood that semaphores can be used to control multi-threaded access to shared resources, ensuring the order of resource access.

[0068] Figure 1In the illustrated embodiment, the instruction information corresponding to user operation commands resides in shared memory during transmission between the front-end and back-end, avoiding the overhead of multiple data copies between operating system kernels. This achieves compatibility requirements between different systems and improves the adaptability of virtualization technology across various systems. Furthermore, in this embodiment, the system efficiently addresses resource idleness and insufficient resources through a descriptor reuse mechanism and asynchronous queue communication (including a first queue and a second queue). Specifically, the front-end driver releases the descriptor immediately after obtaining the operation result from the second queue. This step ensures that limited descriptor resources can be quickly reclaimed for subsequent requests, fundamentally preventing processing stagnation due to resource exhaustion and resolving the potential for resource insufficiency. Simultaneously, interrupt-based asynchronous notification allows the front-end and back-end to process tasks in parallel without mutual blocking, ensuring continuous and efficient utilization of system resources and preventing resource idleness. The combination of these two aspects constructs a virtualization system with efficient resource flow, stable performance, and the ability to support high-concurrency processing.

[0069] To ensure compatibility with different systems, as another implementation of this application, this application also provides another implementation of the task processing method for a virtualization system, as detailed in the following embodiments.

[0070] Figure 2 A flowchart illustrating a task processing method for a virtualization system according to an embodiment of this application is shown. The task processing method for the virtualization system includes the following steps: S210, The front-end driver determines the data operation type corresponding to the user operation command.

[0071] For example, different data operation types can correspond to different data storage structures.

[0072] In one example, data operation types include read-write operation types and non-read-write operation types. Non-read-write operation types can include write zero, synchronization, and deletion.

[0073] S220. Write the instruction information into the shared memory according to the data storage structure corresponding to the data operation type.

[0074] For example, instruction information can be stored in shared memory according to the data storage structure corresponding to the instruction information.

[0075] In some optional embodiments, the data operation type includes a non-read / write operation type, wherein the first data structure corresponding to the non-read / write operation type includes at least a message header, and the message header includes at least a data operation type area, an operation address offset area, and a data length area. Based on multiple first sub-operation types corresponding to the non-read / write operation type, a first target sub-operation type corresponding to the user operation instruction is determined, and the first target sub-operation type is written into the data operation type area; the block device sector address in the instruction information is written into the operation address offset area; the first structure data length of the instruction information stored in the first data structure is determined, and the first structure data length is written into the data length area.

[0076] For example, the first sub-operation types corresponding to the read / write operation types include operations such as write zero, synchronization, and deletion. Furthermore, after determining the first sub-operation type, this first sub-operation type can be written into the data operation type area in the message header.

[0077] For example, the block device sector address in the instruction information can be used to identify the starting address of the operation corresponding to the user operation instruction. This starting address can be the address corresponding to the block device. Furthermore, this starting address can be written into the operation address offset area.

[0078] For example, the first structure data length can be used to characterize the length of the entire instruction information, and this length can be written into the data length area.

[0079] In one example, user operation commands that are not read / write operations can be performed in the form of command words.

[0080] It is understood that in the embodiments of this application, a simplified first data structure (i.e., only including the message header) is used for non-read / write operation data, so that the amount of data in each communication is minimized, thereby significantly reducing system overhead and memory copying times, and providing the system with the lowest latency and the highest throughput.

[0081] In some alternative embodiments, the data operation type includes a read-write operation type, wherein the second data structure corresponding to the read-write operation type includes at least a message header and a message body. The message header includes at least a data operation type area, an operation address offset area, and a data length area, and the message body includes at least an operation data area.

[0082] The operation data is divided into multiple sub-operation data according to a preset data size, and the sub-sector address and sub-data length corresponding to each sub-operation data are determined. Based on the multiple second sub-operation types corresponding to the second data operation type, the second target sub-operation type corresponding to the user operation instruction is determined. For each sub-operation data, the second target sub-operation type is written into the data operation type area corresponding to that sub-operation data. For each sub-operation data, the sub-block device sector address corresponding to that sub-operation data is written into the operation address offset area corresponding to that sub-operation data. For each sub-operation data, the second structure data length of the sub-operation data stored in the second data structure is determined, and the second structure data length is written into the data length area corresponding to that sub-operation data. For each sub-operation data, the sub-operation data is written into the operation data area.

[0083] For example, the preset data size can be pre-set by technicians according to different needs. In one example, the preset data size can be set to 4k based on the page size of the system file.

[0084] For example, after dividing the operation data into multiple sub-operation data according to a preset data size, a corresponding target descriptor can be assigned to each sub-operation data.

[0085] For example, the sub-sector address and sub-data length corresponding to each sub-operation data can be used to characterize the starting address and corresponding data length of the block device corresponding to the sub-operation data.

[0086] For example, the multiple second sub-operation types corresponding to the second data operation type include read operations and write operations. Further, after determining the second sub-operation type, it can be written into the data operation type area in the message header of the target descriptor.

[0087] For example, for each sub-operation data, the sub-sector address and sub-data length corresponding to the sub-operation data can be written into the operation address offset area and data length area corresponding to the message header, respectively. Alternatively, the sub-operation data can also be written into the operation data area.

[0088] In one example, Figure 3 This illustration shows an architectural diagram of a descriptor provided in one embodiment of the present application, such as... Figure 3 As shown, the descriptor includes a message header and a message body. The message header includes a data operation type area, an operation address offset area, and a data length area. The message body includes at least an operation data area.

[0089] It is understood that in this embodiment of the application, when the data operation type is read / write, the data can be split, thereby reducing redundant processes during data processing and remaining within the limits of shared memory size. Simultaneously, this ensures that the backend device directly fills in the data during processing, reducing the complexity of the processing flow, thereby reducing overhead during message transmission and improving the efficiency of the entire message flow.

[0090] Figure 2 In the illustrated embodiment, a differentiated processing strategy is adopted based on different data operation types, which improves data processing efficiency and effectiveness.

[0091] Below, in conjunction with Figures 4-7 The following examples illustrate the task processing methods of virtualization systems.

[0092] Figure 4 This application illustrates a schematic diagram of the architecture of a virtualization system provided in one embodiment. Figure 5 A flowchart illustrating a task processing method for a virtualization system provided in one embodiment of this application is shown. Figure 6 This diagram illustrates the correspondence between the split structure and descriptors provided in one embodiment of this application. Figure 7 A schematic flowchart of a read / write operation provided in one embodiment of this application is shown.

[0093] like Figure 4 As shown, the virtualization system includes a OneOS-based front-end driver 401, a Linux-based back-end driver 402, and shared memory 403. Furthermore, in Figure 5 In this process, the user layer 501 issues I / O commands to the front-end driver 401. These I / O commands can be stored in an I / O task list and issued to the front-end driver 401 in a polling manner. The front-end driver 401 can also be notified to process I / O commands via an interrupt.

[0094] In one example, the OneOS system includes basic virtual device structure pointers, generic pointers to driver block devices for user operations, spinlocks for synchronization control, timers for polling scenarios, and basic block device information structures. The virtual device structure includes specific shared memory mapping addresses and lengths, Vritio framework structure (VRING), and other information.

[0095] In another example, the Linux virtual block device structure is more complex, including Linux virtual device structure pointers, disk structures bound to block devices, mutexes for synchronization operations, work queue structures for handling interrupts, and the Vritio framework's block device virtqueue structure, among other members.

[0096] Furthermore, after receiving an I / O instruction, the front-end driver 401 can determine the cache region based on the I / O instruction. The cache region can represent the storage location of the I / O instruction in shared memory. Further, it stores the instruction information according to the type of instruction information corresponding to the I / O instruction and its corresponding data storage format. It also allocates a descriptor for the I / O instruction and adds the descriptor to the available queue (first queue). Finally, it notifies the back-end device to process the I / O request. In one example, the location of the instruction information in shared memory can be determined in the form of a data cache pointer.

[0097] In one example, the descriptors correspond to the I / O instructions stored in shared memory, such as... Figure 7 As shown, descriptor 0 corresponds to a set of data in shared memory, including a message header and message body; descriptor 1 also corresponds to a set of data in shared memory, including a message header and message body. During device initialization, the virtualized device, acting as an MMIO device, retrieves the name of the actual bound block device from the device tree to obtain the device structure during subsequent message processing. In one example, the corresponding block device can be represented by a device pointer.

[0098] In one example, such as Figure 6 As shown, in S601, it is determined whether the I / O instruction is for reading or writing data. If so, S602 is executed, and the instruction information corresponding to the I / O instruction is split into 4K data sizes. Further, in S603, it is determined whether the I / O instruction is for writing data. If so, S604 is executed, and the instruction information corresponding to the I / O instruction is stored in shared memory. If the I / O instruction is determined not to be for reading or writing data, S605 is executed, and the front-end driver sends an interrupt request to the back-end.

[0099] Furthermore, upon receiving an I / O request, the backend device retrieves the corresponding instruction information from shared memory and processes the data on the block device according to this instruction. After data processing is complete, it updates the shared memory and adds the descriptor to the used queue (second queue). It then sends an interrupt request to notify the frontend driver to complete the I / O instruction processing. To improve efficiency throughout the transmission process, when data is operable, the backend device directly transmits data using the generic block layer BIO structure provided by the frontend driver, utilizing its request queue mechanism to directly distribute information to specific devices for operation. The process code is controlled synchronously, ensuring that the frontend is notified via an inter-core interrupt only after all BIO requests have been processed.

[0100] In one example, such as Figure 6As shown, in S606, the backend device processes the data and notifies the frontend of the data processing result. In S607, it is determined whether the IO instruction is for reading data. If yes, S608 is executed to read the data result from the shared memory. If not, S609 is executed to determine whether all data has been processed. If yes, S610 is executed to release the descriptor and end the process; if not, S611 is executed to release the descriptor and return to S603.

[0101] To avoid excessive processing time during interrupts, the interrupt callback function does not actually process business messages. Instead, it uses semaphores or switching work queues to place the actual data processing in the corresponding asynchronous thread.

[0102] In this embodiment, a virtualized block device can virtualize multiple physical storage devices into a unified storage resource pool, dynamically allocating storage resources according to actual needs. This avoids resource idleness or insufficiency caused by static allocation, improving hardware resource utilization. Furthermore, the virtualized block device can provide an independent virtual storage environment for each application, achieving resource isolation and ensuring data security and independence between different applications. Simultaneously, storage resources can be flexibly shared according to actual usage, improving overall resource utilization efficiency. Further, by abstracting and virtualizing various hardware devices at the underlying level, the virtualized block device provides a unified virtual storage interface for upper-layer applications, shielding the differences in underlying hardware and enabling seamless integration of different types of storage devices into the IoT system, improving device compatibility and interoperability. Moreover, the virtualized block device provides a unified storage access method for various operating systems and applications. Regardless of whether the device runs on an embedded operating system or a general-purpose operating system, data read and write operations can be performed through the virtual storage interface, facilitating application development and deployment, and improving application portability and compatibility. Furthermore, in this embodiment, efficient synchronization primitives, such as spinlocks and semaphores, are designed to ensure data consistency and integrity, avoid concurrent access conflicts, and ensure low latency and high reliability. Moreover, by rationally splitting and merging messages, software-level overhead is reduced, ensuring efficient data transmission between OneOS and Linux.

[0103] Based on the task processing method for the virtualization system provided in the above embodiments, this application also provides specific implementation methods of the task processing apparatus for the virtualization system. Please refer to the following embodiments.

[0104] First see Figure 8 The task processing device 800 of the virtualization system provided in this application embodiment includes the following modules: The first operation module 801 is used to write the instruction information corresponding to the user operation instruction into the shared memory when the front-end driver receives the user operation instruction. The first storage module 802 is used by the front-end driver to store the storage address and data length of instruction information in shared memory to the target descriptor, wherein the target descriptor is an unoccupied descriptor among multiple descriptors in shared memory; The second storage module 803 is used for the front-end driver to store the target descriptor into the first queue in shared memory; The parsing module 804 is used by the backend device to read the target descriptor from the first queue and parse the target descriptor to obtain the storage address and data length. The read module 805 is used by the backend device to read instruction information from the shared memory according to the storage address and data length; The second operation module 806 is used by the backend device to operate the block device according to the instruction information, obtain the operation result, and update the operation result to the shared memory according to the storage address. The third storage module 807 is used by the backend device to store the target descriptor into the second queue in the shared memory, so that the frontend driver can obtain the operation result from the shared memory based on the target descriptor in the second queue.

[0105] In one embodiment, the first operation module 801 writes the instruction information corresponding to the user operation instruction into the shared memory when the front-end driver receives the user operation instruction in the following manner: the front-end driver determines the data operation type corresponding to the user operation instruction; and writes the instruction information into the shared memory according to the data storage structure corresponding to the data operation type.

[0106] In one embodiment, the data operation type includes a non-read / write operation type, wherein the first data structure corresponding to the non-read / write operation type includes at least a message header, and the message header includes at least a data operation type area, an operation address offset area, and a data length area; the first operation module 801 writes instruction information into shared memory according to the data storage structure corresponding to the data operation type in the following manner: determining the first target sub-operation type corresponding to the user operation instruction based on multiple first sub-operation types corresponding to the non-read / write operation type, and writing the first target sub-operation type into the data operation type area; writing the block device sector address in the instruction information into the operation address offset area; determining the first structure data length of the instruction information stored in the first data structure, and writing the first structure data length into the data length area.

[0107] In one embodiment, the data operation type includes a read / write operation type, wherein the second data structure corresponding to the read / write operation type includes at least a message header and a message body. The message header includes at least a data operation type area, an operation address offset area, and a data length area, and the message body includes at least an operation data area. The first operation module 801 writes instruction information into shared memory according to the data storage structure corresponding to the data operation type in the following manner: dividing the operation data according to a preset data size to obtain multiple sub-operation data, and determining the sub-sector address and sub-data length corresponding to each sub-operation data; determining the second target sub-operation type corresponding to the user operation instruction according to the multiple second sub-operation types corresponding to the read / write operation type; writing the second target sub-operation type into the data operation type area corresponding to each sub-operation data for each sub-operation data; writing the sub-block device sector address corresponding to each sub-operation data into the operation address offset area corresponding to each sub-operation data for each sub-operation data; determining the second structure data length of the sub-operation data stored in the second data structure for each sub-operation data, and writing the second structure data length into the data length area corresponding to the sub-operation data for each sub-operation data; and writing the sub-operation data into the operation data area for each sub-operation data.

[0108] In one embodiment, after the front-end driver stores the target descriptor in a first queue in shared memory, the apparatus further includes: a first sending module, configured to send a first interrupt request to a back-end device, so that the back-end device reads the target descriptor from the first queue in shared memory after receiving the first interrupt request; and after the back-end device stores the target descriptor in a second queue in shared memory, the apparatus further includes: a second sending module, configured to send a second interrupt request to the front-end device, so that the front-end driver obtains the operation result from shared memory based on the target descriptor in the second queue.

[0109] In one embodiment, the apparatus further includes a release module for the front-end driver to release the target operation descriptor from the second queue in response to obtaining the operation result.

[0110] In one implementation, the release module releases the target descriptor from the second queue in response to the front-end driver obtaining the operation result: the front-end driver releases the target descriptor from the second queue through a mutex lock.

[0111] In one embodiment, after the front-end driver stores the target descriptor in a first queue in shared memory, the first sending module is further configured to send a first semaphore to the asynchronous thread of the back-end device to indicate the target descriptor to be processed; after the back-end device stores the target descriptor in a second queue in shared memory, the second sending module is further configured to send a second information quantity to the asynchronous thread of the front-end driver to indicate the result of the read operation; in response to the front-end driver obtaining the operation result, the device for releasing the target descriptor from the second queue further includes: a third sending module, configured to send a third information quantity to the asynchronous thread of the front-end driver to release the target descriptor.

[0112] In one embodiment, the first storage module 802 uses a spinlock pair to write the instruction information corresponding to the user operation instruction into the shared memory; the third storage module 807 uses a spinlock pair to update the operation result to the shared memory.

[0113] Figure 9 A schematic diagram of the hardware structure of the task processing device of the virtualization system provided in this application embodiment is shown.

[0114] The task processing device in a virtualization system may include a processor 901 and a memory 902 storing computer program instructions.

[0115] Specifically, the processor 901 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0116] Memory 902 may include mass storage for data or instructions. For example, and not limitingly, memory 902 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 902 may include removable or non-removable (or fixed) media. Where appropriate, memory 902 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 902 is non-volatile solid-state memory.

[0117] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0118] The processor 901 reads and executes computer program instructions stored in the memory 902 to implement any of the task processing methods of the virtualization system in the above embodiments.

[0119] In one example, the task processing device of the virtualization system may further include a communication interface 903 and a bus 910. For example, Figure 9 As shown, the processor 901, memory 902, and communication interface 903 are connected through bus 910 and complete communication with each other.

[0120] The communication interface 903 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0121] Bus 910 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 910 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0122] The task processing device of this virtualization system can execute the task processing method of the virtualization system in this embodiment based on user operation commands, thereby achieving a combination of Figure 1 and Figure 2 The method for task processing in the virtualization system is described.

[0123] Furthermore, in conjunction with the task processing methods in the virtualization system described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the task processing methods in the virtualization system described in the above embodiments.

[0124] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements a task processing method for any of the virtualization systems described in the above embodiments.

[0125] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0126] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0127] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0128] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0129] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A task processing method of a virtualization system, characterized by, The virtualization system comprises a front-end driver based on a first operating system, a back-end device based on a second operating system, and shared memory, and the first operating system is different from the second operating system, and the method comprises: The front-end driver writes instruction information corresponding to the user operation instruction into the shared memory when receiving the user operation instruction; The front-end driver stores a storage address of the instruction information in the shared memory and a data length to a target descriptor, wherein the target descriptor is an unused descriptor in a plurality of descriptors of the shared memory; The front-end driver stores the target descriptor to a first queue in the shared memory; The back-end device reads the target descriptor from the first queue and parses the target descriptor to obtain the storage address and the data length; The back-end device reads the instruction information from the shared memory according to the storage address and the data length; The back-end device operates a block device according to the instruction information, obtains an operation result, and updates the operation result to the shared memory according to the storage address; The back-end device stores the target descriptor to a second queue in the shared memory, so that the front-end driver obtains the operation result from the shared memory according to the target descriptor in the second queue.

2. The task processing method of a virtualization system according to claim 1, wherein, The front-end driver writes instruction information corresponding to the user operation instruction into the shared memory when receiving the user operation instruction, comprising: The front-end driver determines a data operation type corresponding to the user operation instruction; According to a data storage structure corresponding to the data operation type, the instruction information is written into the shared memory.

3. The task processing method of a virtualization system according to claim 2, wherein, The data operation type comprises a non-read-write operation type, wherein a first data structure corresponding to the non-read-write operation type at least comprises a message header, and the message header at least comprises a data operation type area, an operation address offset area, and a data length area; According to a data storage structure corresponding to the data operation type, the instruction information is written into the shared memory, comprising: According to a plurality of first sub-operation types corresponding to the non-read-write operation type, a first target sub-operation type corresponding to the user operation instruction is determined, and the first target sub-operation type is written into the data operation type area; A block device sector address in the instruction information is written into the operation address offset area; A first structure data length of the instruction information stored in the first data structure is determined, and the first structure data length is written into the data length area.

4. The task processing method of a virtualization system according to claim 2, wherein, The data operation type comprises a read-write operation type, wherein a second data structure corresponding to the read-write operation type at least comprises a message header and a message body, the message header at least comprises a data operation type area, an operation address offset area, and a data length area, and the message body at least comprises an operation data area; According to a data storage structure corresponding to the data operation type, the instruction information is written into the shared memory, comprising: The operation data is divided according to the preset data size, and a plurality of sub-operation data is obtained, and a sub-sector address corresponding to each of the sub-operation data and a sub-data length are determined; According to a plurality of second sub-operation types corresponding to the read-write operation type, a second target sub-operation type corresponding to the user operation instruction is determined; For each of the sub-operation data, the second target sub-operation type is written into the data operation type area corresponding to the sub-operation data; For each of the sub-operation data, a sub-block device sector address corresponding to the sub-operation data is written into the operation address offset area corresponding to the sub-operation data; For each of the sub-operation data, a second structure data length of the sub-operation data stored in the second data structure is determined, and the second structure data length is written into the data length area corresponding to the sub-operation data; For each of the sub-operation data, the sub-operation data is written into the operation data area.

5. The task processing method of a virtualization system according to claim 1, wherein, After the front-end driver stores the target descriptor into the first queue in the shared memory, the method further comprises: The front-end driver sends a first interrupt request to the back-end device, so that the back-end device reads the target descriptor from the first queue in the shared memory after receiving the first interrupt request; After the back-end device stores the target descriptor into the second queue in the shared memory, the method further comprises: The back-end device sends a second interrupt request to the front-end driver, so that the front-end driver acquires the operation result from the shared memory according to the target descriptor in the second queue.

6. The task processing method of a virtualization system according to claim 1 or 5, characterized by, The method further comprises: The front-end driver releases the target descriptor from the second queue in response to acquiring the operation result.

7. The task processing method of a virtualization system according to claim 6, wherein, The front-end driver releases the target descriptor from the second queue in response to the front-end driver acquiring the operation result, comprising: The front-end driver releases the target descriptor from the second queue through a mutex.

8. The task processing method of a virtualization system according to claim 6, wherein, After the front-end driver stores the target descriptor into the first queue in the shared memory, the method further comprises: The back-end device sends a first semaphore for prompting a to-be-processed target descriptor to an asynchronous thread in the back-end device; After the back-end device stores the target descriptor into the second queue in the shared memory, the method further comprises: The front-end driver sends a second semaphore for prompting reading the operation result to an asynchronous thread in the front-end driver; The front-end driver releases the target descriptor from the second queue in response to the front-end driver acquiring the operation result, comprising: The front-end driver sends a third semaphore for releasing the target descriptor to an asynchronous thread in the front-end driver.

9. The task processing method of a virtualization system according to claim 1, wherein, The method further comprises: The front-end driver writes the instruction information corresponding to the user operation instruction into the shared memory through a spin lock; The back-end device updates the operation result to the shared memory through the spin lock.

10. A task processing apparatus of a virtualization system, characterized by comprising: The virtualization system comprises a front-end driver based on a first operating system, a back-end device based on a second operating system, and shared memory, and the first operating system is different from the second operating system, and the device comprises: A first operation module, configured to write, by the front-end driver, instruction information corresponding to a user operation instruction into the shared memory when the user operation instruction is received; A first storage module, configured to store, by the front-end driver, a storage address of the instruction information in the shared memory and a data length to a target descriptor, wherein the target descriptor is an unused descriptor in a plurality of descriptors of the shared memory; A second storage module, configured to store, by the front-end driver, the target descriptor to a first queue in the shared memory; An analysis module, configured to read, by the back-end device, the target descriptor from the first queue, and analyze the target descriptor to obtain the storage address and the data length; A reading module, configured to read, by the back-end device, the instruction information from the shared memory according to the storage address and the data length; A second operation module, configured to operate, by the back-end device, a block device according to the instruction information, obtain an operation result, and update the operation result to the shared memory according to the storage address; A third storage module, configured to store, by the back-end device, the target descriptor to a second queue in the shared memory, so that the front-end driver acquires the operation result from the shared memory according to the target descriptor in the second queue.

11. A task processing device of a virtualization system, characterized by, The device comprises a processor and a memory storing computer program instructions; The processor executes the computer program instructions to implement the task processing method of the virtualization system as claimed in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by a processor to implement the task processing method of the virtualization system as claimed in any one of claims 1-9.

13. A computer program product, characterised in that, The instructions in the computer program product are executed by a processor of an electronic device, so that the electronic device performs the task processing method of the virtualization system as claimed in any one of claims 1-9.

Images