Method and apparatus for processing virtual IO request, electronic device and storage medium

Abstract

A method and device for processing a virtual IO request, electronic equipment and storage medium are disclosed, the method comprises: receiving a first request from an upper layer by a front-end driver, and writing the first request into a first register group to trigger a first interrupt; reading the first request from the first register group according to the first interrupt by a back-end driver, and forwarding the first request to a target device for obtaining a request processing result of the first request; writing the request processing result into a second register group by the back-end driver to trigger a second interrupt; and returning the request processing result to the upper layer according to the second interrupt by the front-end driver. The application can optimize the processing process of the virtual IO request, improve the real-time performance and reliability of the virtual IO request, and realize the response of the fast IO request.

Description

Technical Field

[0001] This invention relates to the field of virtualization technology, and in particular to methods and apparatuses, electronic devices and storage media for processing virtual I / O requests. Background Technology

[0002] In the current virtualization environment, VirtIO (an abstraction layer above the devices in a paravirtualization hypervisor) is used as the virtual device interface, implemented in software. A hypervisor is a virtualization technology that allows multiple virtual machines to run on a single physical computer, isolating them in different virtualization environments. Each virtual device driver for a virtual machine is divided into a front-end driver and a back-end driver. The front-end driver runs on the guest virtual machine, receives service requests from the upper-layer standard framework, translates them into hardware logic requests, sends these requests to a virtual queue, and then the VirtIO management process schedules them for processing by the back-end driver. The back-end driver runs on the management host, receives requests from the front-end driver, forwards them to the physical device for processing, and returns the processing result to the front-end driver. When device configuration information changes, the hypervisor generates an interrupt; VirtIO uses this soft interrupt method to notify the front-end and back-end drivers to synchronize data. All virtual queues share this interrupt. This VirtIO communication method has the following disadvantages.

[0003] First, when the system is busy or multiple devices frequently send requests, the VirtIO management process may become overloaded, potentially leading to timeouts or delayed scheduling, compromising the real-time performance and reliability of I / O. Second, to ensure compatibility with all types of VirtIO requests, VirtIO has numerous context configuration options. Furthermore, the data buffer (temporarily storing input and output data) for VirtIO requests is typically a virtual address with non-contiguous physical addresses. To achieve zero-copy memory, an `sg_table` (a hash table of physical memory) data structure is needed to store information such as the start address and length of the multiple non-contiguous physical addresses corresponding to this virtual address. Each request requires passing the context configuration and the `sg_table` structure. However, in real-world scenarios, requests with small data volumes and requiring rapid transmission are common, such as fence synchronization and status queries. For these fast I / O requests and event notifications with small data volumes, the VirtIO mechanism is inefficient. Summary of the Invention

[0004] The present invention provides a method and apparatus, electronic device and storage medium for processing virtual I / O requests, which can optimize the processing of virtual I / O requests, improve the real-time performance and reliability of virtual I / O requests, and achieve fast I / O request response.

[0005] In one aspect of the present invention, a method for processing virtual I / O requests is provided. The method includes: a front-end driver receiving a first request from an upper layer and writing the first request into a first register group to trigger a first interrupt; a back-end driver reading the first request from the first register group according to the first interrupt and forwarding the first request to a target device to obtain a request processing result for the first request; the back-end driver writing the request processing result into a second register group to trigger a second interrupt; and the front-end driver returning the request processing result to the upper layer according to the second interrupt.

[0006] In another aspect of the invention, an apparatus for processing virtual I / O requests is provided. The apparatus includes: a first register group configured to trigger a first interrupt; a second register group configured to trigger a second interrupt; a front-end driver configured to receive a first request from an upper layer, write the first request into the first register group to trigger the first interrupt, and be configured to return a request processing result of the first request to the upper layer according to the second interrupt; and a back-end driver configured to read the first request from the first register group according to the first interrupt, forward the first request to a target device to obtain a request processing result of the first request, and be configured to write the request processing result into the second register group to trigger the second interrupt.

[0007] In another aspect of the invention, an electronic device is provided. The electronic device includes a memory configured to store a computer program; and a processor configured to execute the computer program to perform the aforementioned method for processing virtual I / O requests.

[0008] In another aspect of the invention, a computer-readable medium is provided. This medium stores a computer program that is executed by a processor to implement the aforementioned method for processing virtual I / O requests.

[0009] According to the technical solution of this invention, the front-end driver writes a first request from the upper layer into a first register group to trigger a first interrupt. The back-end driver then forwards the first request to the target device process for processing based on the first interrupt to obtain the request processing result. Simultaneously, the back-end driver writes the request processing result into a second register group to trigger an uplink interrupt. The front-end driver then returns the request processing result to the upper layer based on the second interrupt. The front-end driver and back-end driver generate the first and second interrupts respectively through the first and second register groups, achieving multi-channel bidirectional parallel transmission without the need for serial execution in a waiting queue, thus improving the real-time performance and reliability of virtual I / O requests. Furthermore, requests from the upper layer only require reading, writing, and storage processing in the first and second register groups, improving the response speed of virtual I / O requests. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for processing virtual I / O requests according to an embodiment of the present invention;

[0011] Figure 2 This is an architecture diagram of a method for processing virtual I / O requests according to an embodiment of the present invention;

[0012] Figure 3 This is another flowchart of a method for processing virtual I / O requests according to an embodiment of the present invention;

[0013] Figure 4 This is another flowchart of a method for processing virtual I / O requests according to an embodiment of the present invention;

[0014] Figure 5 This is a schematic diagram of the structure of an apparatus for processing virtual I / O requests according to an embodiment of the present invention;

[0015] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0016] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0017] In existing technologies, each virtual device driver in a virtual machine is divided into a front-end driver and a back-end driver. The front-end driver runs on the guest virtual machine, receives service requests from the upper-layer standard framework, converts them into hardware logic requests, sends these requests to a virtual queue, and then the VritIO management process centrally schedules and hands them over to the back-end driver for processing. The back-end driver runs on the management host, receives requests from the front-end driver, forwards them to the physical device for processing, and returns the processing result to the front-end driver. VirtIO uses a software interrupt method (when device configuration information changes, the hypervisor generates an interrupt) to notify the front-end and back-end drivers to synchronize data. All virtual queues share this interrupt. This VritIO communication method has the following disadvantages.

[0018] First, when the system is busy or multiple devices frequently send requests, the VirtIO management process may become overloaded, potentially leading to timeouts or delayed scheduling, compromising the real-time performance and reliability of I / O. Second, to ensure compatibility with all types of VirtIO requests, VirtIO has numerous context configuration options. Furthermore, the data buffer for VirtIO requests is typically a virtual address with non-contiguous physical addresses. To achieve zero-copy memory, an `sg_table` data structure is needed to store information such as the start address and length of the multiple non-contiguous physical addresses corresponding to this virtual address. Each request requires passing the context configuration and the `sg_table` structure. However, in real-world scenarios, requests with small data volumes and requiring rapid transmission are common, such as fence synchronization and status queries. For these fast I / O requests and event notifications with small data volumes, the VirtIO mechanism is inefficient.

[0019] To address at least the aforementioned technical problems, this disclosure provides a method for processing virtual I / O requests. According to this disclosure, the front-end driver writes a first request from the upper layer into a first register group to trigger a first interrupt. The back-end driver then forwards the first request to the target device process for processing based on the first interrupt to obtain the request processing result. Simultaneously, the back-end driver writes the request processing result into a second register group to trigger an uplink interrupt. The front-end driver then returns the request processing result to the upper layer based on the second interrupt. In this manner, embodiments of this disclosure can generate a first interrupt and a second interrupt between the front-end driver and the back-end driver through the first register group and the second register group respectively, achieving multi-channel bidirectional parallel transmission without the need for serial execution in a waiting queue, thus improving the real-time performance and reliability of virtual I / O requests. Furthermore, requests from the upper layer only require read, write, and storage processing in the first and second register groups, improving the response speed of virtual I / O requests.

[0020] In the following, the technical solutions according to this disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0021] Figure 1 This is a flowchart illustrating a method 100 for processing virtual I / O requests according to an embodiment of the present disclosure. (Refer to...) Figure 1 The method 100 includes the following steps 102 to 108.

[0022] In step 102, the front-end driver receives a first request from the upper layer and writes the first request into the first register group to trigger a first interrupt.

[0023] In some embodiments, writing the first request to the first register group includes: if the front-end driver determines that the size of the request data corresponding to the first request is not greater than a threshold, then the front-end driver writes the request data to the shared data register of the first register group. In this way, for upper-layer requests with small request data, an interrupt can be directly generated based on the first register group to achieve fast response processing of upper-layer requests, avoiding waiting delays and effectively improving the processing efficiency of small data requests.

[0024] In some embodiments, writing the first request to the first register group includes: if the front-end driver determines that the size of the request data corresponding to the first request is greater than a threshold, then the front-end driver writes the handle of the request data to the shared data register of the first register group. The method further includes: writing the request data to first memory in a contiguous memory pool, and sharing the first memory with the target device through the back-end driver for the target device to process the first request. In this way, for upper-layer requests with large request data, the back-end driver can share the first memory with the target device, achieving zero-copy memory between the front-end driver and the back-end driver, thereby improving the processing efficiency of large data requests and thus improving the real-time performance and reliability of virtual I / O requests.

[0025] In some embodiments, writing the first request to the first register group to trigger the first interrupt includes: the front-end driver writing the request type corresponding to the first request to the request register of the first register group; and triggering the first interrupt in response to the request type being written to the request register. In this way, after writing the request type to the first register group, an interrupt is triggered directly, and then the process waits for the completion of the upper-layer request, without adding it to the waiting queue for scheduling, thus avoiding timeouts or delayed scheduling when the management process is busy.

[0026] In some embodiments, the first request includes a request type and request data, and the first register group includes a first request register and a first shared data register. Receiving the first request from the upper layer by the front-end driver and writing the first request into the first register group to trigger a first interrupt includes: the client's front-end driver receiving the first request associated with the upper-layer framework service; the front-end driver writing the request type into the first request register to trigger the first interrupt and writing the request data into second memory; and the front-end driver writing the memory handle of the second memory into the first shared data register. In this way, writing the request type into the first request register directly triggers an interrupt, while simultaneously writing the request data into the first shared data register for temporary storage to await the completion of the upper-layer request. This achieves parallel processing of upper-layer requests, avoids timeouts or delayed scheduling when the management process is busy, and improves the real-time performance and reliability of virtual I / O requests.

[0027] In step 104, the backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device to obtain the request processing result of the first request.

[0028] In some embodiments, the backend driver reading the first request from the first register group based on the first interrupt and forwarding the first request to the target device includes: the backend driver receiving the first interrupt and invoking an interrupt callback function; reading the request type and the request data from the first register group according to the interrupt callback function; and forwarding the request type and the request data to the target device. In this manner, the backend driver directly reads the request type and request data from the first register group based on the first interrupt for forwarding, so that upper-layer requests do not need to be scheduled through the waiting queue in the management service process, but are directly responded to and processed by the first interrupt, thus improving the request response speed.

[0029] In some embodiments, the backend driver reading the first request from the first register group based on the first interrupt and forwarding the first request to the target device includes: the backend driver receiving the first interrupt and calling an interrupt callback function; reading the request type and the handle of the request data from the first register group according to the interrupt callback function; the backend driver converting the handle of the request data into a physical address; and forwarding the request type and the physical address to the target device. In this way, the backend driver directly reads the request type and request data from the first register group based on the first interrupt, without waiting for queue scheduling, thus improving request response speed. Simultaneously, the backend driver converts the handle of the request data into a physical address, allowing the target device to directly access the first memory after obtaining the physical address, achieving zero-copy memory processing, and eliminating the need to pass request-related data structures, thereby improving request processing efficiency.

[0030] In some embodiments, the backend driver reading the first request from the first register group according to the first interrupt and forwarding the first request to the target device includes: the host's backend driver calling a first interrupt callback function according to the first interrupt; the backend driver reading the request type in the first request register and the memory handle in the first shared data register according to the first interrupt callback function, and adding the request type and the memory handle to the request queue; and the backend driver forwarding the request type and the memory handle to the target device through the request queue. In this way, after the backend driver receives the first interrupt, it reads the request type and request data of the upper-layer request from the corresponding register, adds them to the request queue, and forwards them to the target device one by one for processing, avoiding the problem of excessive load on the target device.

[0031] In some embodiments, the backend driver reading the first request from the first register group according to the first interrupt and forwarding the first request to the target device includes: the backend driver reading the request type from the first request register and reading the memory handle from the first shared data register; the backend driver converting the memory handle into a physical address; and the backend driver forwarding the request type and the physical address to the target device. In this manner, reading the request type from the first request register and reading the memory handle from the first shared data register achieves request data isolation, facilitating subsequent direct reading of the corresponding data from the registers and improving data reading efficiency.

[0032] In step 106, the backend driver writes the request processing result into the second register group to trigger the second interrupt.

[0033] In some embodiments, the backend driver writing the request processing result into the second register group to trigger the second interrupt includes: the backend driver writing the completion type corresponding to the processing of the target device into the request register of the second register group to trigger the second interrupt. In this way, writing the completion type corresponding to the processing of the target device into the second register group to trigger the second interrupt enables a rapid response to upper-layer requests, eliminating the need for queue scheduling and improving request processing efficiency.

[0034] In some embodiments, the first register group includes a first interrupt status register, the second register group includes a second request register, and the request processing result includes a completion type. The backend driver writing the request processing result into the second register group to trigger a second interrupt includes: the host's backend driver writing the completion type into the second request register to trigger the second interrupt. The second interrupt is used to read and clear the interrupt status in the first interrupt status register. In this way, the interrupt status in the first interrupt status register is read and cleared by the second interrupt triggered by the backend driver to respond to the completion of the current request processing, avoiding repeated execution of the same request.

[0035] In step 108, the front-end driver returns the request processing result to the upper layer based on the second interrupt.

[0036] In some embodiments, the front-end driver returning the request processing result to the upper layer based on the second interrupt includes: the front-end driver receiving the second interrupt and calling an interrupt response function; and waking up a waiting thread according to the interrupt response function to return the request processing result to the upper layer. In this way, since the back-end driver and the target device require a certain amount of time to process the request, the front-end driver creates a waiting thread to listen for subsequent request processing results returned by the back-end driver, thereby promptly returning the request processing result to the upper layer.

[0037] In some embodiments, triggering a first interrupt includes: writing a first interrupt status to an interrupt status register of the second register group, and after triggering the first interrupt, the method further includes: reading and clearing the first interrupt status from the interrupt status register of the second register group. Triggering a second interrupt includes: writing a second interrupt status to an interrupt status register of the first register group, and after triggering the second interrupt, the method further includes: reading and clearing the second interrupt status from the interrupt status register of the first register group. In this way, by storing the first interrupt triggered by the front-end driver and the second interrupt triggered by the back-end driver in the interrupt status registers of different register groups, bidirectional transmission of request data and request results is achieved.

[0038] In some embodiments, the method may further include: after writing the first request into a first register group to trigger a first interrupt, and before the backend driver writes the request processing result into a second register group to trigger a second interrupt, the frontend driver receives a second request from the upper layer and writes the second request into the first register group to trigger a third interrupt; the backend driver reads the second request from the first register group according to the third interrupt and forwards the second request to the target device to obtain the request processing result of the second request; after the backend driver writes the request processing result into the second register group to trigger a second interrupt, the backend driver writes the request processing result of the second request into the second register group to trigger a fourth interrupt; and the frontend driver returns the request processing result of the second request to the upper layer according to the fourth interrupt. In this manner, multiple frontend drivers in the client can send requests to the backend driver in parallel. Compared to the method of sequential execution by adding a waiting queue, this invention can avoid timeouts or delayed scheduling when the management process is busy.

[0039] In some embodiments, the method may further include: after the backend driver writes the request processing result into the second register group to trigger a second interrupt, and before the frontend driver returns the request processing result to the upper layer, the frontend driver receives a third request from the upper layer and writes the third request into the first register group to trigger a fifth interrupt; the backend driver reads the third request from the first register group according to the fifth interrupt and forwards the third request to the target device to obtain the request processing result of the third request; the backend driver writes the request processing result of the third request into the second register group to trigger a sixth interrupt; and the frontend driver returns the request processing result of the third request to the upper layer according to the sixth interrupt. In this manner, multi-channel bidirectional parallel transmission of requests and request processing results can be achieved, improving request processing efficiency.

[0040] Figure 2 This is an architectural diagram illustrating a method for processing virtual I / O requests according to an embodiment of the present disclosure. (Refer to...) Figure 2 In some embodiments, the front-end driver runs on a guest virtual machine (hereinafter referred to as GUEST), and the back-end driver runs on a management host (hereinafter referred to as HOST). A first register group (hereinafter referred to as register group A) and a second register group (hereinafter referred to as register group B) are also provided. The front-end driver implements request-response mechanisms with the back-end driver based on register-based uplink and downlink interrupts and the shared memory mechanism RKVMEM.

[0041] In some embodiments, the GUEST and HOST have different read and write permissions for register group A and register group B. Specifically, the GUEST can read and write to register group A, but is read-only to register group B. The HOST is read-only to register group A, but can read and write to register group B.

[0042] In some embodiments, uplink interrupt routes and downlink interrupt routes are configured to enable bidirectional data transmission. The uplink interrupt route is set at the GUEST, allowing the GUEST's processor to receive downlink interrupts. The downlink interrupt route is set at the HOST, allowing the HOST's processor to receive uplink interrupts.

[0043] In some embodiments, relevant data in the registers are read and written via uplink and downlink interrupts. Writing a request type to the Group A request register triggers a downlink interrupt. After the downlink interrupt is triggered, the request status can be read and cleared from the Group B interrupt register. Writing a completion type to the Group B request register triggers an uplink interrupt. After the uplink interrupt is triggered, the request status can be read and cleared from the Group A interrupt register.

[0044] Figure 3 This is a flowchart illustrating a method 200 for processing virtual I / O requests according to an embodiment of the present disclosure. (Refer to...) Figure 3 This method 200 implements request processing for small data requests, including the following steps 202 to 212.

[0045] In step 202, the GUEST front-end driver receives the first request from the upper layer.

[0046] In step 204, the GUEST front-end driver writes the request type of the first request into the Group A request register, triggering the first interrupt, namely the A2B interrupt; at the same time, the GUEST front-end driver writes the memory handle of the request data of the first request into the Group A shared data register, and creates a waiting thread to wait for the first request to complete.

[0047] In step 206, the HOST backend driver receives an A2B interrupt and then calls the interrupt callback function.

[0048] In step 208, the HOST backend driver reads the GUEST's request type and memory handle from the A group request register and the A group shared data register through the interrupt callback function, adds them to the request queue, and forwards them to the target device's driver for processing through the request queue.

[0049] In step 210, the driver processing of the target device is completed, the processing result of the first request is obtained, the completion type of the first request is written into the B group request register, and the second interrupt, namely the B2A interrupt, is triggered; wherein, the completion type of the first request includes success or error.

[0050] In step 212, when the GUEST front-end driver receives a B2A interrupt, it calls the interrupt callback function and wakes up the waiting thread, returning the processing result of the first request to the upper layer through the waiting thread.

[0051] Figure 4 This is a flowchart illustrating a method 300 for processing virtual I / O requests according to an embodiment of the present disclosure. (Refer to...) Figure 4 The method 300 implements request processing for big data requests, including steps 302 to 318.

[0052] In step 302, the GUEST front-end driver receives a second request from the upper layer.

[0053] In step 304, the GUEST front-end driver writes the request type of the second request into the A group request register, triggering the third interrupt, namely the A2B interrupt; the GUEST front-end driver allocates a block of memory from the contiguous memory pool and obtains the memory handle corresponding to that memory.

[0054] In step 306, the GUEST front-end driver writes the memory handle into the shared data register.

[0055] In step 308, the HOST backend driver receives an A2B interrupt and then calls the interrupt callback function.

[0056] In step 310, the HOST backend driver reads the request type of GUEST from the Group A request register through the interrupt callback function; the HOST backend driver reads the memory handle from the Group A shared data register through the interrupt callback function and converts the memory handle into a physical address.

[0057] In step 312, the HOST backend driver sends the request type and physical address to the driver of the target device.

[0058] In step 314, the driver of the target device maps the physical address to the virtual machine address to access the memory, or sets the physical address directly into the register of the hardware processing unit for processing. For example, the physical address of the memory of the error-encoded video is handed over to the device's video codec unit (VPU) for processing.

[0059] In step 316, the driver processing of the target device is completed, the processing result of the second request is obtained, the completion type of the second request is written into the B group request register, and the fourth interrupt, namely the B2A interrupt, is triggered.

[0060] In step 318, the GUEST front-end driver receives a B2A interrupt, calls the interrupt callback function, wakes up the waiting thread, and returns the processing result of the second request to the upper layer through the waiting thread.

[0061] In existing technologies, to improve data memory access efficiency, multimedia hardware processing units on a device (such as graphics processing units (GPUs), video encoding / decoding units (VPUs), display processing and compositing units (VOPs), and 2D graphics processors (RGAs)) can directly access DDR memory without CPU intervention. However, in standard virtual machine architectures, for data security reasons, guests are generally not allowed to directly access DDR memory; memory mapping and access control are required in the hypervisor. In this architecture, the contiguous memory accessed by the guest is actually memory mapped by the hypervisor. This memory appears contiguous to the guest, but it may not actually be truly physically contiguous. Therefore, multimedia hardware processing units cannot directly access this memory; they need to convert it into multiple physically contiguous memory blocks and enable the CPU-based memory management unit (MMU) or copy the data to designated physically contiguous memory blocks before the multimedia hardware processing units can access this memory, resulting in very low access efficiency.

[0062] This invention addresses the characteristic of multimedia hardware processing units (MLUs) directly accessing physical memory, and combines this with the memory access characteristics of virtual machines (VMs) to establish a shared memory mechanism, RKMEM (method 300). RKMEM allocates a physically contiguous block of memory within Hypervisor and manages it. RKMEM controls access to this contiguous memory block and provides an interface for memory allocation and the conversion between memory handles and physical addresses. When a guest needs memory, it can call the memory allocation interface to return a memory handle and a VM address mapped to the guest and directly accessible. The guest front-end driver accesses this memory block through this VM address. The host back-end driver converts the memory handle of this block into a physical address through the RKMEM interface and writes it to the registers of the multimedia hardware processing unit, allowing the MLU to access this physical memory. Through this RKMEM shared memory mechanism, the multimedia hardware processing unit and the guest front-end driver can access the same memory block, achieving zero-copy memory access while ensuring mutual exclusion, effectively improving access efficiency.

[0063] According to another aspect of the invention, Figure 5 This is a block diagram illustrating an apparatus 400 for processing virtual I / O requests according to an embodiment of the present invention. (Refer to...) Figure 5The device 400 includes a first register set 402, a second register set 404, a front-end driver 406, and a back-end driver 408. The first register set 402 is configured to trigger a first interrupt. The second register set 404 is configured to trigger a second interrupt. The front-end driver 406 is configured to receive a first request from an upper layer, write the first request to the first register set 402 to trigger the first interrupt, and is configured to return the request processing result of the first request to the upper layer according to the second interrupt. The back-end driver 408 is configured to read the first request from the first register set 402 according to the first interrupt, forward the first request to a target device to obtain the request processing result of the first request, and is configured to write the request processing result to the second register set 404 to trigger the second interrupt.

[0064] In some embodiments, the device 400 includes multiple data transmission channels, each including a first register group 402 and a second register group 404. Each of the first register group 402 and the second register group 404 includes a request register, an interrupt register, and a 64-bit shared data register. The request register stores the request type, the interrupt register stores the interrupt status, and the shared data register stores the memory handle or physical address of the data memory. In this way, the mailbox delivery function is simulated, enabling multi-channel bidirectional data transmission and improving the real-time performance and reliability of I / O requests.

[0065] According to another aspect of the invention, Figure 6 This is a schematic diagram illustrating an electronic device 500 according to an embodiment of the present invention. (Refer to...) Figure 6 The electronic device 500 includes a memory 502, a processor 504, and a computer program stored in the memory 502 and executable on the processor 504. When the processor 504 executes the computer program, it implements the steps of the method for processing virtual I / O requests as described above.

[0066] According to another aspect of the present invention, a computer-readable medium is provided. The computer-readable medium stores a computer program that is executed by a processor to implement the method for processing virtual I / O requests as described above.

[0067] In summary, the present invention provides a method, apparatus, electronic device, and storage medium for processing virtual I / O requests. The front-end driver achieves bidirectional parallel transmission through a first register group and a second register group. Compared to the prior art method of sending upper-layer requests to a request queue and then having VritIO schedule transmission according to priority and first-in-first-out principles, the present invention allows multiple front-end drivers to send I / O requests to the back-end driver in parallel, eliminating the need for serial scheduling and execution within a request queue, effectively improving the real-time performance and reliability of virtual I / O requests. For small data requests, the front-end driver only needs to trigger an interrupt directly through registers for a fast response, ensuring that the response time is controlled within nanoseconds, effectively improving the response speed of small data requests. Simultaneously, for large data requests, the front-end driver and the target device share memory, achieving zero-copy memory between the front-end driver and the back-end driver, effectively improving data access efficiency. The present invention comprehensively improves the response efficiency of virtual I / O requests by optimizing the processing of different I / O requests.

[0068] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for processing virtual I / O requests, characterized in that, include: The front-end driver receives the first request from the upper layer and writes the first request into the first register group to trigger the first interrupt; The backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device to obtain the request processing result of the first request; The backend driver writes the request processing result into the second register group to trigger a second interrupt; as well as The front-end driver returns the request processing result to the upper layer based on the second interrupt. Writing the first request to the first register group includes: if the front-end driver determines that the size of the request data corresponding to the first request is not greater than a threshold, then the front-end driver writes the request data to the shared data register of the first register group; if the front-end driver determines that the size of the request data corresponding to the first request is greater than the threshold, then the front-end driver writes the handle of the request data to the shared data register of the first register group. The method further includes: writing the request data into a first memory in a contiguous memory pool, and sharing the first memory with the target device via the backend driver for the target device to process the first request. The first register group includes a first interrupt status register, and the second register group includes a second request register. The request processing result includes a completion type. The process of the backend driver writing the request processing result to the second register group to trigger the second interrupt includes: the host's backend driver writing the completion type to the second request register to trigger the second interrupt, wherein the second interrupt is used to read and clear the interrupt status in the first interrupt status register. Triggering the first interrupt includes writing the first interrupt status to the second interrupt status register of the second register group. After triggering the first interrupt, the method further includes reading and clearing the first interrupt status from the second interrupt status register of the second register group. Triggering the second interrupt includes writing the second interrupt status into the first interrupt status register of the first register group. After triggering the second interrupt, the method further includes reading and clearing the second interrupt status from the first interrupt status register of the first register group. The front-end driver has read and write permissions for the first register group and read-only permissions for the second register group, while the back-end driver has read-only permissions for the first register group and read and write permissions for the second register group.

2. The method according to claim 1, characterized in that, Writing the first request to the first register group to trigger the first interrupt includes: The front-end driver writes the request type corresponding to the first request into the request register of the first register group; and The first interrupt is triggered in response to the request type being written to the request register.

3. The method according to claim 2, characterized in that, The backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device, including: The backend driver receives the first interrupt and calls the interrupt callback function; The request type and request data are read from the first register group according to the interrupt callback function; and The request type and the request data are forwarded to the target device.

4. The method according to claim 2, characterized in that, The backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device, including: The backend driver receives the first interrupt and calls the interrupt callback function; The interrupt callback function reads the handle of the request type and the request data from the first register group. The backend driver converts the handle of the request data into a physical address; and The request type and the physical address are forwarded to the target device.

5. The method according to claim 1, characterized in that, The backend driver writes the request processing result to the second register group to trigger the second interrupt, including: The backend driver writes the completion type corresponding to the processing of the target device into the request register of the second register group to trigger the second interrupt.

6. The method according to claim 1, characterized in that, The front-end driver returning the request processing result to the upper layer based on the second interrupt includes: The front-end driver receives the second interrupt and calls the interrupt response function; and The interrupt response function wakes up the waiting thread to return the request processing result to the upper layer.

7. The method according to claim 1, characterized in that, The first request includes a request type and request data, and the first register group includes a first request register and a first shared data register. The process of the front-end driver receiving a first request from the upper layer and writing the first request into the first register group to trigger a first interrupt includes: The client's front-end driver receives the first request associated with the upper-layer framework service; The front-end driver writes the request type into the first request register to trigger the first interrupt, and writes the request data into the second memory; and The front-end driver writes the memory handle of the second memory into the first shared data register.

8. The method according to claim 7, characterized in that, The backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device, including: The host's backend driver calls the first interrupt callback function based on the first interrupt; The backend driver reads the request type from the first request register and the memory handle from the first shared data register according to the first interrupt callback function, and adds the request type and the memory handle to the request queue; The backend driver forwards the request type and the memory handle to the target device through the request queue.

9. The method according to claim 7, characterized in that, The backend driver reads the first request from the first register group according to the first interrupt and forwards the first request to the target device, including: The backend driver reads the request type from the first request register and the memory handle from the first shared data register; The backend driver translates the memory handle into a physical address; and The backend driver forwards the request type and the physical address to the target device.

10. The method according to claim 1, characterized in that, Also includes: After the first request is written to the first register group to trigger the first interrupt, and before the backend driver writes the request processing result to the second register group to trigger the second interrupt, the frontend driver receives the second request from the upper layer and writes the second request to the first register group to trigger the third interrupt; The backend driver reads the second request from the first register group according to the third interrupt, and forwards the second request to the target device to obtain the request processing result of the second request; After the backend driver writes the request processing result into the second register group to trigger the second interrupt, the backend driver writes the request processing result of the second request into the second register group to trigger the fourth interrupt. as well as The front-end driver returns the request processing result of the second request to the upper layer based on the fourth interrupt.

11. The method according to claim 1, characterized in that, Also includes: After the backend driver writes the request processing result into the second register group to trigger the second interrupt, and before the frontend driver returns the request processing result to the upper layer, the frontend driver receives a third request from the upper layer and writes the third request into the first register group to trigger the fifth interrupt; The backend driver reads the third request from the first register group according to the fifth interrupt, and forwards the third request to the target device to obtain the request processing result of the third request; The backend driver writes the request processing result of the third request into the second register group to trigger the sixth interrupt; as well as The front-end driver returns the request processing result of the third request to the upper layer based on the sixth interrupt.

12. An apparatus for processing virtual I / O requests, characterized in that, include: The first register group is configured to trigger the first interrupt; The second register group is configured to trigger a second interrupt; The front-end driver is configured to receive a first request from the upper layer, write the first request to the first register group to trigger the first interrupt, and is configured to return the request processing result of the first request to the upper layer according to the second interrupt; as well as The backend driver is configured to read the first request from the first register group according to the first interrupt, forward the first request to the target device to obtain the request processing result of the first request, and is configured to write the request processing result to the second register group to trigger the second interrupt. The front-end driver is configured such that if the front-end driver determines that the size of the request data corresponding to the first request is not greater than a threshold, the front-end driver writes the request data into the shared data register of the first register group. If the front-end driver determines that the size of the request data corresponding to the first request is greater than a threshold, then the front-end driver writes the handle of the request data into the shared data register of the first register group. The front-end driver is configured to write the request data into a first memory within a contiguous memory pool, and the back-end driver is configured to share the first memory with the target device for the target device to process the first request. The first register group includes a first interrupt status register, and the second register group includes a second request register. The request processing result includes a completion type. The backend driver is configured to write the completion type to the second request register to trigger the second interrupt, which is used to read and clear the interrupt status in the first interrupt status register. The first register group is configured to write a first interrupt status to a second interrupt status register of the second register group, and to read and clear the first interrupt status from the second interrupt status register of the second register group after the first interrupt is triggered. The second register group is configured to write the second interrupt status to the first interrupt status register of the first register group, and to read and clear the second interrupt status from the first interrupt status register of the first register group after the second interrupt is triggered. The front-end driver has read and write permissions for the first register group and read-only permissions for the second register group, while the back-end driver has read-only permissions for the first register group and read and write permissions for the second register group.

13. An electronic device, characterized in that, include: The memory is configured to store executable programs; as well as A processor is configured to execute the program to perform the method according to any one of claims 1 to 11.

14. A computer-readable medium having a computer program stored thereon, characterized in that, The computer program is executed to implement the method according to any one of claims 1 to 11.

Images