IO processing methods and devices

Abstract

This invention discloses a VirtIO device driver architecture and IO processing method and device, relating to the field of virtual machine technology. The device driver architecture includes a VirtIO transparent proxy module, a VirtIO protocol bridging and conversion module, and a VirtIO backend processing module. The VirtIO transparent proxy module runs on the Hypervisor and is used to implement all access from the Guest VM VirtIO frontend to the VirtIO backend. The VirtIO protocol bridging and conversion module runs on DDE and is used to convert VirtIO frontend requests through shared memory and send the converted VirtIO frontend requests to the VirtIO backend processing module according to the VirtIO device mapping table. This application has strong versatility and is more lightweight.

Description

Technical Field

[0001] This application relates to the field of virtual machine technology, specifically to a VirtIO device driver architecture and IO processing method and device. Background Technology

[0002] Traditional Hypervisor (virtual machine monitor) and VirtIO (virtualization input / output device standard) virtualization require extensive custom development of both the front-end and back-end. Typically, a VirtIO front-end and back-end interface is defined based on the Hypervisor layer for customized development. For example, L4RE (a virtualization / microkernel system based on the Fiasco kernel) customized the L4VirtIO (a VirtIO front-end and back-end interface developed based on L4RE) interaction interface for VirtIO development based on L4RE. Currently, the L4RE VirtIO architecture is shown below. Figure 1 As shown. Figure 1 In this context, Guest VM represents the guest virtual machine, Frontend represents the front end, Guest Applications represents the guest applications, Guest OS represents the virtual system, VirtIO Frontend Driver represents the driver in the virtual machine (Guest OS) used to communicate with VirtIO backend devices, VirtIO Ring represents the core transmission mechanism of the VirtIO protocol, Host represents the host, Backend represents the backend, Device Emulation Layer represents the device emulation layer, Network Backend represents the backend components, Storage Backend represents the storage backend, Host OSServices represents the host operating system services, Memory Mgmt represents memory management, IPC represents inter-process communication, Scheduling represents scheduling, Capability Mgmt represents management capabilities, Device Access represents the device access permission management mechanism, and L4RE Runtime Environment is a lightweight operating system runtime environment based on the L4 microkernel, where L4 Microkernel represents the microkernel and Hardware represents the hardware.

[0003] However, the existing VirtIO architecture has the following drawbacks: (1) It is not a general architecture. If a Hypervisor is replaced, the front-end and back-end interaction interface based on the Hypervisor needs to be redefined; (2) A large number of mature VirtIO back-ends in the open source community cannot be reused. The stability and efficiency of the newly customized VirtIO back-end need to be verified; (3) Custom Hypervisor VirtIO front-end and back-end interaction implementations are generally updated slowly. Custom maintenance and development are required. Moreover, with the development and updates of the VirtIO standard, custom Hypervisor VirtIO interfaces often cannot support the latest defined VirtIO back-end devices; (4) Usually, the implementation of Hypervisor VirtIO back-end does not support hot-plugging mechanism, that is, VirtIO back-end does not support separate startup and update mechanism. Summary of the Invention

[0004] This application provides a VirtIO device driver architecture, IO processing method, and device, which has strong versatility and is implemented in a more lightweight manner.

[0005] In a first aspect, embodiments of this application provide a VirtIO device driver architecture, the VirtIO device driver architecture comprising:

[0006] The VirtIO transparent proxy module runs on the Hypervisor and is used to enable all access from the Guest VM VirtIO frontend to the VirtIO backend.

[0007] The VirtIO protocol bridging and conversion module runs on DDE. The VirtIO protocol bridging and conversion module is used to convert VirtIO front-end requests through shared memory and send the converted VirtIO front-end requests to the VirtIO back-end processing module according to the VirtIO device mapping table.

[0008] The VirtIO backend processing module runs on DDE and supports hot-swapping. The VirtIO backend processing module is used to create and manage VirtIO backend devices.

[0009] In conjunction with the first aspect, in one implementation method,

[0010] The device driver architecture supports the simultaneous operation of multiple Guest VMs and multiple DDEs;

[0011] VirtIO frontend requests from multiple Guest VMs are forwarded to the corresponding DDE VirtIO backend processing modules for processing through the VirtIO transparent proxy module.

[0012] In conjunction with the first aspect, in one implementation, the shared memory is shared memory between Hypervisor Native and DDE, and the shared memory is implemented by Hypervisor Native.

[0013] Secondly, embodiments of this application provide an I / O processing method, implemented based on the VirtIO device driver architecture described above, the I / O processing method comprising:

[0014] The VirtIO front-end driver receives I / O requests sent by the Guest VM application and notifies the VirtIO transparent proxy module via MMIO write operations.

[0015] The VirtIO transparent proxy module intercepts and parses I / O requests, encapsulates the I / O requests into RPC messages, and the VirtIO protocol bridging and conversion module receives the RPC messages and sends them to the VirtIO backend processing module.

[0016] The VirtIO backend processing module receives VirtIO-related requests corresponding to RPC messages and calls the VirtIO protocol bridging and conversion module to convert the vring indirect desc related addresses stored in the VirtIO data queue so that DDE can be accessed.

[0017] In conjunction with the second aspect, in one implementation, the VirtIO front-end driver receives I / O requests sent by the Guest VM application and notifies the VirtIO transparent proxy module via MMIO write operations, specifically including:

[0018] The application in the Guest VM initiates an I / O request;

[0019] The VirtIO front-end driver in the Guest OS receives I / O requests, constructs VirtIO descriptors and fills queues, and notifies the VirtIO transparent proxy module through MMIO write operations.

[0020] In conjunction with the second aspect, in one implementation, the VirtIO transparent proxy module intercepts and parses I / O requests, encapsulates the I / O requests into RPC messages, and the VirtIO protocol bridging and conversion module receives the RPC messages and sends them to the VirtIO backend processing module, specifically including:

[0021] The VirtIO transparent proxy module intercepts the Guest VM's MMIO access operations, parses I / O requests in VirtIO protocol format, and encapsulates the I / O requests into RPC messages;

[0022] The DDE's VirtIO protocol bridging and conversion module receives RPC messages;

[0023] The VirtIO protocol bridging and conversion module's Memory MAP module handles memory mapping and permission checks, and converts the memory address of vring within the Guest VM into a DDE-accessible DDE GPA address.

[0024] The VirtIO protocol bridging and conversion module sends RPC messages to the VirtIO backend processing module through the Router module;

[0025] The VirtIO protocol bridging and conversion module also includes an Ioeventfd / IRQFD module, which is used for interrupt handling of data transmission and reception in the Kernel Space of the VirtIO backend.

[0026] In conjunction with the second aspect, in one implementation method,

[0027] The VirtIO backend processing module includes a VirtIO BUS module, an Event Loop module, and a Memory Region module;

[0028] The VirtIO BUS module is used to create user-mode or kernel-mode VirtIO devices, and to control the VirtIO backend to perform specific device operations and data processing. The VirtIO backend then calls the Linux Native Driver to access the hardware.

[0029] The Event Loop module is used to receive VirtIO-related requests corresponding to RPC messages sent by the VirtIO protocol bridging and conversion module;

[0030] The Memory Region module is used to call the VirtIO protocol bridging and conversion module to convert the vring indirect desc related addresses stored in the VirtIO data queue so that DDE can be accessed.

[0031] In conjunction with the second aspect, in one implementation method,

[0032] Before the VirtIO front-end driver receives I / O requests sent by the Guest VM application, it also includes starting the VirtIO device driver architecture;

[0033] The device driver architecture for launching VirtIO specifically includes:

[0034] Start the Boot Loader and Hypervisor, and initialize the components;

[0035] Start the Linux Native driver container as a DDE and load the VirtIO protocol bridging and conversion module;

[0036] The VirtIO backend processing module of the DDE kernel layer starts to start the VirtIO backend service to provide services to the Guest VM;

[0037] Start one or more Guest VMs based on requirements.

[0038] In conjunction with the second aspect, in one implementation method,

[0039] The VirtIO backend includes two types: one type runs only in User Space, where VirtIO's Ctrl Plane and Data Plane are mixed together; the other type runs in both User Space and Kernel Space, where the implementation in Kernel Space reuses the Linux Vhost driver framework to handle the front-end and back-end interaction of VirtIO Data Plane.

[0040] Thirdly, embodiments of this application provide an I / O processing device, the I / O processing device including a processor, a memory, and an I / O processing program stored in the memory and executable by the processor, wherein when the I / O processing program is executed by the processor, it implements the steps of the I / O processing method described above.

[0041] The beneficial effects of the technical solutions provided in this application include:

[0042] Using the general VirtIO virtualization architecture, it can be flexibly modified to be applicable to multiple types of hypervisors. The Guest VM VirtIO front-end requires no modification and is fully compatible with the standard VirtIO. At the same time, it adopts multi-layer security isolation, supports multiple back-end instances running simultaneously, and supports dynamic back-end switching, hot-swapping, OTA upgrades, etc. From an architectural design perspective, the VirtIO back-end framework is only responsible for the creation and management of back-end devices, not the creation and management of virtual machines, making its implementation more lightweight. Attached Figure Description

[0043] Figure 1 A schematic diagram of the VirtIO architecture for L4RE;

[0044] Figure 2 This is a schematic diagram of the device driver architecture of VirtIO in this application;

[0045] Figure 3 This is a flowchart illustrating the IO processing method of this application;

[0046] Figure 4 This is a complete flowchart of the IO processing method in this application;

[0047] Figure 5 This is a schematic diagram of the hardware structure of the IO processing device of this application. Detailed Implementation

[0048] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0050] Firstly, embodiments of this application provide a VirtIO device driver architecture, namely, a virtualization architecture based on VirtIO.

[0051] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the device driver architecture for VirtIO in this application. Figure 2 As shown, the VirtIO device driver architecture includes: VirtIO transparent proxy module, VirtIO protocol bridging and conversion module, and VirtIO backend processing module.

[0052] Figure 2 In this paper, the DDE (Device Driver Engine) provides VirtIO backend services for the Guest VM. The VirtIO device driver architecture of this application is not limited to multiple Hypervisor systems such as L4re, QNX, SEL4, and XEN. By using the device driver architecture of this application, the VirtIO frontend on the Guest VM side uses the Linux (an operating system) VirtIO standard frontend. The device driver architecture of this application mainly involves three key modules on the Hypervisor side: the VirtIO transparent proxy module, the VirtIO protocol bridging and conversion module, and the VirtIO backend processing module.

[0053] In this application, the VirtIO transparent proxy module runs on the hypervisor and is used to enable all access from the Guest VM VirtIO frontend to the VirtIO backend. Specifically, the Hypervisor implements the VirtIO transparent proxy module, the Guest VM VirtIO frontend sees the standard VirtIO device, and all access from the Guest VM VirtIO frontend to the VirtIO backend is implemented based on the VirtIO transparent proxy module.

[0054] In this application, the VirtIO protocol bridging and conversion module runs on DDE. This module is used to convert VirtIO front-end requests via shared memory and send the converted requests to the VirtIO back-end processing module according to the VirtIO device mapping table. The shared memory is between Hypervisor Native and DDE, and is implemented by Hypervisor Native (a virtualization technology that runs directly on physical hardware).

[0055] Specifically, the Hypervisor Native implementation shares memory with the DDE implementation, efficiently converting multiple VirtIO frontend requests through shared memory. Based on the VirtIO device mapping table, the converted VirtIO frontend requests are sent to the VirtIO backend processing module. In addition, the VirtIO protocol bridging and conversion module also implements failover and reconnection mechanisms to cooperate with the backend hot-plug mechanism.

[0056] In this application, the VirtIO backend processing module runs on DDE and supports hot-swapping. This module is used to create and manage VirtIO backend devices. Specifically, unlike traditional Qemu / Crosvm / Acrn Device VMs, the VirtIO backend processing module does not create or manage virtual machines; its functionality is limited to the creation and management of VirtIO backend devices, making its implementation more lightweight. The VirtIO backend processing module is hot-swappable and supports OTA upgrades and fault restart mechanisms.

[0057] It should be noted that the device driver architecture of this application supports the simultaneous operation of multiple Guest VMs and multiple DDEs; the VirtIO front-end requests of multiple Guest VMs are forwarded to the VirtIO back-end processing module of the corresponding DDE for processing through the VirtIO transparent proxy module.

[0058] for Figure 2APP represents an application program; VirtIO Driver represents the driver interface designed for VirtIO devices in the Linux kernel; vIRQ represents a virtual interrupt request; Trap represents a mechanism in virtualization; Device Proxy represents an intermediate component in the VirtIO architecture used to coordinate communication between the front-end driver and the back-end device; RPC represents Remote Procedure Call; Linux Native driver container represents a technology that encapsulates Linux kernel drivers in a container; VirtIO Device represents a paravirtualized device; VirtIO BUS is a virtual bus in the Linux kernel used to manage VirtIO devices; Device Mgr represents the device manager; Event Loop represents the event loop; Memory Region represents a specific area in memory planned by the software layer in RDMA communication, used to store data transmission and reception; Linux Native Drv represents a driver natively supported by the Linux kernel; Vhost Drv is the core component of vhost technology, mainly used to improve the performance of VirtIO devices in a virtualized environment; Data Plane represents the data plane; Memory... MAP stands for memory mapping. Ioeventfd / IRQFD are two mechanisms in KVM-QEMU virtualization used for efficient communication between the Guest and the host, respectively for receiving Guest notifications and injecting interrupts into the Guest. Router stands for routing. Physical Device stands for physical device. HW stands for backend hardware.

[0059] Secondly, this application also provides an IO processing method based on the device driver architecture of VirtIO described above.

[0060] In one embodiment, reference is made to Figure 3 , Figure 3 This is a flowchart illustrating the IO processing method of this application. Figure 3 As shown, the IO processing methods include:

[0061] S1: The VirtIO front-end driver receives I / O (input / output) requests sent by the Guest VM application and notifies the VirtIO transparent proxy module through MMIO (memory-mapped input / output) write operations;

[0062] S2: The VirtIO transparent proxy module intercepts and parses I / O requests, encapsulates the I / O requests into RPC messages, and the VirtIO protocol bridging and conversion module receives the RPC messages and sends them to the VirtIO backend processing module;

[0063] S3: The VirtIO backend processing module receives the VirtIO-related requests corresponding to the RPC message and calls the VirtIO protocol bridging and conversion module to convert the vring indirect desc (indirect descriptor) related addresses stored in the VirtIO data queue so that the DDE can be accessed.

[0064] Furthermore, in one embodiment, the VirtIO front-end driver receives I / O requests sent by the Guest VM application and notifies the VirtIO transparent proxy module via MMIO write operations, specifically including:

[0065] S101: An application in the Guest VM initiates an I / O request;

[0066] S102: The VirtIO front-end driver in the Guest OS (virtual system) receives I / O requests, constructs VirtIO descriptors and fills queues, and notifies the VirtIO transparent proxy module through MMIO write operations.

[0067] Specifically, applications in the Guest VM initiate I / O operations (requests) such as network transmissions and disk read / write operations. The VirtIO front-end driver within the Guest OS receives the I / O requests, constructs VirtIO descriptors and fills the queue, and then notifies the VirtIO transparent proxy module via MMIO write operations. The queue refers to the virtqueue queue defined in the VirtIO protocol.

[0068] Furthermore, in one embodiment, the VirtIO transparent proxy module intercepts and parses I / O requests, encapsulates the I / O requests into RPC messages, and the VirtIO protocol bridging and conversion module receives the RPC messages and sends them to the VirtIO backend processing module, specifically including:

[0069] S201: The VirtIO transparent proxy module intercepts the Guest VM's MMIO access operations, parses the I / O requests in the VirtIO protocol format, and encapsulates the I / O requests into RPC messages;

[0070] S202: The DDE's VirtIO protocol bridging and conversion module receives RPC messages;

[0071] S203: The VirtIO protocol bridging conversion module's Memory MAP module handles memory mapping and permission checks, and converts the memory address of the vring (a data structure) within the Guest VM into a DDE-accessible DDE GPA address (the guest's physical address).

[0072] S204: The VirtIO protocol bridging and conversion module sends RPC messages to the VirtIO backend processing module through the Router module;

[0073] The VirtIO protocol bridging and conversion module also includes the Ioeventfd / IRQFD module, which is the part of the VirtIO backend in the Kernel Space (the running space of the Linux kernel) for interrupt handling of data transmission and reception.

[0074] Furthermore, the VirtIO backend processing modules include the VirtIO BUS module, the Event Loop module, and the MemoryRegion module.

[0075] The VirtIO BUS module is used to create user-space or kernel-space VirtIO devices and control the VirtIO backend to perform specific device operations and data processing. The VirtIO backend then calls the Linux Native Driver (a device driver developed directly based on the Linux kernel) to access the hardware. Specifically, the VirtIO BUS module creates user-space or kernel-space VirtIO devices and controls the actual VirtIO backend to perform specific device operations and data processing. The actual VirtIO backend can be implemented using open-source methods, such as the VirtIO-net backend or the VirtIO-blk backend.

[0076] The Event Loop module is used to receive VirtIO-related requests corresponding to RPC messages sent by the VirtIO protocol bridging and conversion module; VirtIO-related requests include configuration requests, data transmission requests, etc.

[0077] The Memory Region module is used to call the VirtIO protocol bridging and translation module to translate the vring indirect desc related addresses stored in the VirtIO data queue, making them accessible to DDE. This translation is an address translation because the addresses seen in DDE and the addresses seen in the Guest virtual machine are different; there is an offset between them. For example, if the address seen by the VirtIO backend processing module in DDE is A, and the address seen by the Guest virtual machine is B, then A = B + offset.

[0078] The IO processing method of this application also includes response return. After the hardware operation is completed, a response is returned in reverse. The VirtIO transparent proxy module injects a virtual interrupt into the Guest and notifies the Guest front-end driver that the processing is complete.

[0079] Furthermore, in one embodiment, before the VirtIO front-end driver receives the I / O request sent by the Guest VM application, the device driver architecture of VirtIO is also started.

[0080] The VirtIO device driver architecture is initiated, specifically including:

[0081] S11: Start the Boot Loader and Hypervisor, and initialize the components;

[0082] Specifically, the Boot Loader starts, performs hardware initialization and security world settings, the Hypervisor starts, the Hypervisor loads and initializes basic system services, and the Hypervisor starts components such as memory management, I / O services, and logging services;

[0083] S12: Start the Linux Native driver container as a DDE and load the VirtIO protocol bridging and conversion module;

[0084] S13: The VirtIO backend processing module of the DDE kernel layer starts to start the VirtIO backend service to provide services to the Guest VM;

[0085] VirtIO backends include two types: one type runs only in User Space, where VirtIO's CtrlPlane (control plane) and Data Plane are mixed together; the other type runs in both User Space and Kernel Space, where the implementation in Kernel Space reuses the Linux Vhost driver framework to handle the front-end and back-end interaction of VirtIO Data Plane.

[0086] S14: Start one or more Guest VMs based on demand. That is, start multiple or one Guest VMs as needed. The applications in the Guest VMs start, and the system enters normal operation.

[0087] The complete process of the IO processing method in this application is shown in [link to application]. Figure 4 As shown. Figure 4 In Linux virtualization, Ioevnetfd is the IO event notification mechanism used for KVM / QEMU.

[0088] The IO processing method in this application uses a general VirtIO virtualization architecture, which can be flexibly modified to be applicable to multiple types of hypervisors, such as l4re, xen, and sel4. The Guest VM VirtIO front-end requires no modification and is fully compatible with standard VirtIO. At the same time, it adopts multi-layer security isolation, supports multiple back-end instances running simultaneously, and supports dynamic back-end switching, hot-swapping, and OTA upgrades. Furthermore, from an architectural design perspective, the VirtIO back-end framework is only responsible for the creation and management of back-end devices, not the creation and management of virtual machines, making its implementation more lightweight. In addition, a large number of existing VirtIO back-ends in the open-source community, such as Qemu, Crosvm, Rust-vmm, etc., have implemented VirtIO-net, VirtIO-blk, VirtIO-input back-end devices, which can be compatible and reused.

[0089] Thirdly, embodiments of this application provide an IO processing device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0090] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the I / O processing device involved in the embodiments of this application. In the embodiments of this application, the I / O processing device may include a processor, a memory, a communication interface, and a communication bus.

[0091] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0092] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the I / O processing device, as well as interfaces used for interconnecting the I / O processing device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0093] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0094] The processor can be a general-purpose processor, which can call an I / O processing program stored in memory and execute the I / O processing method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the I / O processing program is called can be referred to in the various embodiments of the I / O processing method of this application, and will not be repeated here.

[0095] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0096] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0097] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0098] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0099] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0101] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An IO processing method based on VirtIO device driver architecture implementation, characterized in that, The IO processing method comprises: The VirtIO front-end driver receives an I / O request sent by a Guest VM application, and notifies a VirtIO transparent proxy module through an MMIO write operation; The VirtIO transparent proxy module intercepts and analyzes the I / O request, encapsulates the I / O request into an RPC message, and the VirtIO protocol bridge conversion module receives the RPC message and sends it to a VirtIO back-end processing module; The VirtIO back-end processing module receives a VirtIO-related request corresponding to the RPC message, and calls the VirtIO protocol bridge conversion module to convert a vring indirect desc related address stored in a VirtIO data queue, so that the DDE can access; The device driver architecture of the VirtIO comprises: The VirtIO transparent proxy module runs in a Hypervisor, and is used to realize all accesses of a Guest VM VirtIO front-end to a VirtIO back-end; The VirtIO protocol bridge conversion module runs in a DDE, and is used to convert a VirtIO front-end request through shared memory, and send the converted VirtIO front-end request to the VirtIO back-end processing module according to a VirtIO device mapping table; The VirtIO back-end processing module runs in the DDE and supports hot plug, and is used to realize creation and management of a VirtIO back-end device; The device driver architecture supports simultaneous running of multiple Guest VMs and multiple DDEs; VirtIO front-end requests of the multiple Guest VMs are forwarded to VirtIO back-end processing modules of corresponding DDEs through the VirtIO transparent proxy module for processing; The shared memory is a shared memory between the Hypervisor Native and the DDE, and is implemented by the Hypervisor Native.

2. The IO processing method of claim 1, wherein, The VirtIO front-end driver receives an I / O request sent by a Guest VM application, and notifies a VirtIO transparent proxy module through an MMIO write operation, and specifically comprises: An application program in the Guest VM initiates an I / O request; A VirtIO front-end driver in the Guest OS receives the I / O request, constructs a VirtIO descriptor and fills a queue, and notifies the VirtIO transparent proxy module through an MMIO write operation.

3. The IO processing method of claim 2, wherein, The VirtIO transparent proxy module intercepts and analyzes the I / O request, encapsulates the I / O request into an RPC message, and the VirtIO protocol bridge conversion module receives the RPC message and sends it to a VirtIO back-end processing module, and specifically comprises: The VirtIO transparent proxy module intercepts an MMIO access operation of the Guest VM, analyzes an I / O request in a VirtIO protocol format, and encapsulates the I / O request into an RPC message; The VirtIO protocol bridging conversion module of the DDE receives the RPC message; The Memory MAP module of the VirtIO protocol bridging conversion module processes memory mapping and permission checking, and converts the memory address of the vring in the Guest VM into a DDE GPA address accessible by the DDE; The VirtIO protocol bridging conversion module sends the RPC message to the VirtIO backend processing module through the Router module; The Ioeventfd / IRQFD module in the VirtIO protocol bridging conversion module is used for the part of the VirtIO backend in the Kernel Space, and is used for interrupt processing for data sending and receiving.

4. The IO processing method of claim 2, wherein: The VirtIO backend processing module includes a VirtIO BUS module, an Event Loop module, and a Memory Region module; The VirtIO BUS module is used for creating a user state or kernel state VirtIO device, and controlling the VirtIO backend to perform specific device operations and data processing, and then calling the Linux Native Driver by the VirtIO backend to access hardware; The Event Loop module is used for receiving a VirtIO-related request corresponding to the RPC message sent by the VirtIO protocol bridging conversion module; The Memory Region module is used for calling the VirtIO protocol bridging conversion module to convert the vring indirect desc-related address stored in the VirtIO data queue, so as to be accessible by the DDE.

5. The IO processing method of claim 2, wherein: Before the VirtIO frontend driver receives the I / O request sent by the Guest VM application, the method further includes starting a device driver architecture of the VirtIO; The starting of the device driver architecture of the VirtIO specifically includes: Starting a Boot Loader and a Hypervisor, and performing component initialization; Starting a Linux Native driver container as a DDE, and loading the VirtIO protocol bridging conversion module; Starting the VirtIO backend processing module in the DDE kernel layer to start the VirtIO backend service to provide services for the Guest VM; Starting one or more Guest VMs based on requirements.

6. The IO processing method of claim 5, wherein: The VirtIO backend includes two types, one of which only runs in the User Space, and the Ctrl Plane and Data Plane of VirtIO are mixed together, and the other of which runs in the User Space and the Kernel Space at the same time, and the implementation part in the Kernel Space reuses the Linux Vhost driver framework to process the front-end and back-end interaction part of the VirtIO Data Plane.

7. An IO processing device, characterized by, The IO processing device includes a processor, a memory, and an IO processing program stored in the memory and executable by the processor, wherein the IO processing program, when executed by the processor, implements the steps of an IO processing method according to any one of claims 1 to 6.

Images