Method, device and equipment for implementing virtio model of lightweight virtualization

Abstract

The application discloses a kind of lightweight virtualization VirtIO model implementation method, device and equipment, is related to virtualization technical field, which method includes replacing VirtIO's Notify mechanism as Directly Deliver interrupt mechanism, and VirtIO register and register value are transferred using interrupt parameter shared memory;Reuse original Vring shared memory mechanism, and the VCPU model of Hypervisor is replaced using the thread of VM and Host;The synchronization mechanism of Hypervisor's VM exit / enter is replaced using the wait / wakeup of VM and Host.This application can improve the performance of VirtIO device on existing virtualization system.

Description

Technical Field

[0001] This application relates to the field of virtualization technology, specifically to a lightweight virtualization VirtIO model implementation method, apparatus, and device. Background Technology

[0002] The existing VirtIO (a semi-virtualization technology) model mainly relies on the Hypervisor to forward VirtIO events and perform memory mapping of the Vring (Virtual Ring, virtual ring buffer or shared memory), and the VCPU (virtual CPU) model, which relies on the Hypervisor, provides synchronization between the VirtIO front-end and back-end.

[0003] The existing VirtIO model suffers from significant performance degradation during frequent front-end and back-end interactions, and its use cases are limited. A hypervisor is a prerequisite for its use. Specifically, in the existing VirtIO model, communication between the Guest (the front-end driver running in the operating system inside the virtual machine) and the Host (the back-end processor running on the host machine) relies on register read / write operations. This causes the virtual machine to exit, and the Host can only become aware of the Guest's requests after taking over the virtual machine. Furthermore, this model has performance limitations, and repeated VM (Virtual Machine) exits negatively impact performance. Summary of the Invention

[0004] This application provides a lightweight virtualization VirtIO model implementation method, apparatus, and device, which can improve the performance of VirtIO devices on existing virtualization systems.

[0005] In a first aspect, embodiments of this application provide a lightweight virtualization VirtIO model implementation method, the lightweight virtualization VirtIO model implementation method comprising: Replace VirtIO's Notify mechanism with the Directly Deliver interrupt mechanism, and pass VirtIO registers and register values ​​via interrupt parameters shared memory; The existing Vring shared memory mechanism is reused, and the Hypervisor's VCPU model is replaced with threads for the VM and Host. Replace the Hypervisor's VM exit / enter synchronization mechanism with the VM and Host's wait / wakeup mechanism.

[0006] In conjunction with the first aspect, in one implementation, the reuse of the original Vring shared memory mechanism specifically includes: The Vring between the VM and the Host is kept as shared memory. The VM accesses the Vring through Stage2 mapping, while the Host accesses the Vring through the regular memory system.

[0007] In conjunction with the first aspect, in one implementation, for the lightweight virtualization VirtIO model, the VirtIO frontend requests backend services, specifically including: The VirtIO frontend thread stores the request memory in Vring and the request parameters in the interrupt parameter shared memory. The VirtIO frontend thread sends an interrupt to the host through the interrupt direct transmission mechanism, and then the VirtIO frontend thread is suspended, waiting to be woken up by the VirtIO-int interrupt; When the backend VirtIO-int handler is triggered, it wakes up the waiting VirtIO backend thread. The VirtIO backend thread obtains the requested memory from the Vring and the requested parameters from the interrupt parameter shared memory.

[0008] In conjunction with the first aspect, in one implementation, the request parameters include the VirtIO register address and the read / write content.

[0009] In conjunction with the first aspect, in one implementation, for the lightweight virtualization VirtIO model, the VirtIO backend completes the service notification to the frontend, specifically including: The backend VirtIO thread completes the service, updates the Vring, and writes the interrupt parameters corresponding to the request parameters to the Vring; The backend VirtIO thread sends an interrupt to the frontend VM through the interrupt direct transmission mechanism, which triggers the frontend VirtIO-int handler and wakes up the waiting frontend VirtIO thread. The VirtIO frontend thread obtains interrupt parameters and the updated Vring memory.

[0010] In conjunction with the first aspect, in one implementation, in the lightweight virtualization VirtIO model, all domains share the same UFS.

[0011] In conjunction with the first aspect, in one implementation method, The domains in the lightweight virtualization VirtIO model include a first AP domain, a second AP domain, and a third AP domain; The first AP domain is used to run the UFS driver and the UFS driver backend; The second AP domain is the Android domain, which is used to map its own System, Data, and Vendor partitions to the backend; The third AP domain is an Ubuntu domain, used to map its own root partition and data partition to the backend.

[0012] Secondly, embodiments of this application provide a lightweight virtualized VirtIO model implementation apparatus, the lightweight virtualized VirtIO model implementation apparatus comprising: The replacement module replaces VirtIO's Notify mechanism with a Directly Deliver interrupt mechanism and uses interrupt parameters to share memory to transfer VirtIO registers and register values. The reuse module is used to reuse the original Vring shared memory mechanism and replace the Hypervisor's VCPU model with VM and Host threads. The processing module replaces the Hypervisor's VM exit / enter synchronization mechanism with the VM and Host's wait / wakeup mechanism.

[0013] In conjunction with the second aspect, in one implementation, the reuse of the original Vring shared memory mechanism specifically includes: The Vring between the VM and the Host is kept as shared memory. The VM accesses the Vring through Stage2 mapping, while the Host accesses the Vring through the regular memory system.

[0014] Thirdly, embodiments of this application provide a lightweight virtualized VirtIO model implementation device, the lightweight virtualized VirtIO model implementation device including a processor, a memory, and a lightweight virtualized VirtIO model implementation program stored in the memory and executable by the processor, wherein when the lightweight virtualized VirtIO model implementation program is executed by the processor, it implements the steps of the lightweight virtualized VirtIO model implementation method described above.

[0015] The beneficial effects of the technical solutions provided in this application include: Building upon the direct delivery interruption mechanism, this application replaces the previous notification mechanism based on virtualization exit by enabling direct interruption communication between the Guest and Host sides. Based on the Stage2 shared memory mechanism of lightweight virtualization, it reuses the Host-VM's Vring memory model and the Hypervisor-independent VirtIO device model. This allows not only VSW systems to use the lightweight virtualization VirtIO model of this application, but also AMP systems that combine shared memory and interoperable interruption to use the lightweight virtualization VirtIO model of this application. Furthermore, it can improve the performance of VirtIO devices on existing virtualization systems. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the lightweight virtualization VirtIO model implementation method of this application; Figure 2 This is a schematic diagram illustrating the communication between the lightweight virtualization VirtIO model and the host in this application; Figure 3 A flowchart illustrating the process of a VirtIO frontend requesting backend services; Figure 4 A flowchart illustrating the process of the VirtIO backend completing service notifications to the frontend; Figure 5 This is a schematic diagram of the multi-domain interaction of the lightweight virtualization VirtIO model in this application; Figure 6 This is a schematic diagram of the functional modules of the lightweight virtualized VirtIO model implementation device of this application; Figure 7 This is a schematic diagram of the hardware structure of the device implementing the lightweight virtualized VirtIO model in this application. Detailed Implementation

[0017] 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.

[0018] 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.

[0019] In the first aspect, embodiments of this application provide a lightweight virtualization VirtIO model implementation method. Based on direct interrupt delivery, it replaces the previous notification mechanism based on virtualization exit by directly interrupting communication between the Guest and Host sides. It also reuses the Host-VM's Vring memory model based on the Stage2 (the second-level address translation mechanism in the Hypervisor used to control the virtual machine's memory view) shared memory mechanism of lightweight virtualization.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the lightweight virtualization VirtIO model implementation method of this application. Figure 1 As shown, the lightweight virtualization VirtIO model implementation methods include: S1: Replace VirtIO's Notify mechanism with the Directly Deliver interrupt mechanism, and pass VirtIO registers and register values ​​via interrupt parameters shared memory; S2: Reuse the original Vring shared memory mechanism and replace the Hypervisor's VCPU model with VM and Host threads; S3: Replace the Hypervisor's VM exit / enter synchronization mechanism with the VM and Host's wait / wakeup mechanism.

[0021] For details, see Figure 2The diagram shown illustrates the communication between the lightweight virtualization VirtIO model and the host in this application. For the lightweight virtualization VirtIO model of this application, in terms of overall architecture, the original virtualization VirtIO Notify mechanism is replaced with a Directly Deliver interrupt based on lightweight virtualization between VMs and hosts, where the VM does not exit. That is, the Directly Deliver interrupt mechanism is used to achieve mutual Notify. VirtIO registers and register values ​​are passed using interrupt parameters shared memory. The original Vring shared memory mechanism is reused, that is, the Vring between VM and host is kept as shared memory. VM accesses Vring through Stage2 mapping, and host accesses Vring through the regular memory system (that is, host accesses Vring through its own regular memory system). The Hypervisor's VCPU model is directly replaced by VM and host threads. The Hypervisor's VM exit / enter synchronization mechanism (VM exit means virtual machine exit, VMenter means virtual machine entry, VM exit and VM enter are mechanisms in hardware-assisted virtualization) is replaced with VM and host wait / wakeup. Figure 2 In this context, DDE stands for Dynamic Device Emulation, Driver represents the driver, and MMU represents the Memory Management Unit.

[0022] Furthermore, in one embodiment, see [reference needed]. Figure 3 As shown, in the lightweight virtualization VirtIO model, the VirtIO frontend requests backend services, specifically including: S11: The VirtIO frontend thread stores the requested memory in Vring and the requested parameters in the interrupt parameter shared memory; where frontend means frontend and thread means thread, VirtIO frontend thread means frontend VirtIO driver thread, which generally refers to the kernel thread running the VirtIO driver; the requested parameters include the VirtIO register address and read / write content. S12: The frontend thread of VirtIO sends an interrupt to the host through the interrupt direct transmission mechanism. Then the frontend thread of VirtIO is suspended and waits for the VirtIO-int interrupt (usually referred to as VirtIO interrupt, which is a mechanism for virtual devices to notify the client of events) to wake it up. In other words, the VirtIO frontend thread is suspended and waits for the VirtIO-int interrupt to wake it up. S13: The backend VirtIO-int handler (VirtIO interrupt handler) is triggered, waking up the waiting VirtIO backend thread (a backend processing thread or process running on the host side, responsible for handling VirtIO frontend I / O requests). The VirtIO backend thread obtains the requested memory from the Vring and the requested parameters from the interrupt parameter shared memory. Specifically, after an interrupt reaches the backend, the backend VirtIO-int handler is triggered to wake up the VirtIO backend thread, allowing the backend to obtain the requested memory and requested parameters from the frontend through the Vring.

[0023] Furthermore, in one embodiment, see [reference needed]. Figure 4 As shown, in the lightweight virtualization VirtIO model, the VirtIO backend completes the service notification to the frontend, specifically including: S21: The backend VirtIO thread completes the service, updates the Vring, and writes the interrupt parameters (i.e., the return value of the corresponding request parameters) to the Vring; where, service refers to device-related functional services; updating the Vring refers to writing the acquired data and content to the Vring; S22: The backend VirtIO thread sends an interrupt to the frontend VM through the interrupt direct transmission mechanism, which triggers the frontend VirtIO-int handler and wakes up the waiting frontend VirtIO thread; S23: The VirtIO frontend thread obtains interrupt parameters and the updated Vring memory. Specifically, the VirtIO frontend thread obtains interrupt parameters and the updated Vring memory through the Vring.

[0024] Further, see Figure 5The diagram shown illustrates the inter-domain interaction of the lightweight virtualization VirtIO model of this application. In the lightweight virtualization VirtIO model, all domains share the same UFS (Universal Flash Storage); the domains in the lightweight virtualization VirtIO model include the first AP domain (corresponding to...). Figure 5 AP0 in the middle), the second AP domain (corresponding to) Figure 5 AP1 in the middle), the third AP domain (corresponding to Figure 5 The three AP domains are: AP2, Ubuntu, and AP3. The first AP domain runs the UFS driver and its backend. The second AP domain is the Android domain, used to map its System, Data, and Vendor partitions to the backend. The Vendor partition stores device manufacturer-specific drivers, applications, and custom system files. The third AP domain is the Ubuntu domain, used to map its root partition and data partition to the backend. Ubuntu is an operating system. AP stands for Application Processor, which is the virtual machine running the guest operating system. Figure 5 In this context, "backend" refers to the backend, "Block VirtIO Driver" is the core driver component in the Linux kernel used to implement semi-virtualized block device I / O, and "mailbox" represents inter-kernel communication.

[0025] The lightweight virtualization VirtIO model implementation method of this application, based on direct interrupt delivery, replaces the previous notification mechanism based on virtualization exit by directly interrupting communication between the Guest and Host sides. It reuses the Host-VM's Vring memory model based on the Stage2 shared memory mechanism of lightweight virtualization and does not depend on the Hypervisor's VirtIO device model. Not only can the VSW system use the lightweight virtualization VirtIO model of this application, but it can also be used on the AMP system that combines shared memory and interoperable interrupts. Furthermore, it can improve the performance of VirtIO devices on existing virtualization systems.

[0026] Secondly, embodiments of this application also provide a lightweight virtualized VirtIO model implementation device.

[0027] In one embodiment, reference is made to Figure 6 , Figure 6 This is a schematic diagram of the functional modules of the lightweight virtualized VirtIO model implementation device of this application. Figure 6 As shown, the lightweight virtualized VirtIO model implementation device includes: a replacement module, a reuse module, and a processing module.

[0028] The replacement module replaces VirtIO's Notify mechanism with a Directly Deliver interrupt mechanism and uses interrupt parameters to pass VirtIO registers and register values ​​via shared memory. The reuse module reuses the original Vring shared memory mechanism and replaces the Hypervisor's VCPU model with VM and Host threads. The processing module replaces the Hypervisor's VM exit / enter synchronization mechanism with VM and Host wait / wakeup.

[0029] For the lightweight virtualization VirtIO model of this application, in terms of overall architecture, the original virtualization VirtIO Notify mechanism is replaced with a DirectlyDeliver interrupt based on lightweight virtualization between VMs and hosts, where the VM does not exit. That is, the DirectlyDeliver interrupt mechanism is used to achieve mutual Notify. VirtIO registers and register values ​​are passed using interrupt parameters shared memory. The original Vring shared memory mechanism is reused, that is, the Vring between the VM and the host is kept as shared memory. The VM accesses the Vring through Stage2 mapping, and the host accesses the Vring through the regular memory system (that is, the host accesses the Vring through its own regular memory system). The Hypervisor's VCPU model is directly replaced by VM and host threads. The Hypervisor's VM exit / enter synchronization mechanism (the process of the virtual machine switching from non-root mode to root mode due to a specific event during operation, i.e., VM exit, or returning from root mode to non-root mode, i.e., VMentry) is replaced by VM and host wait / wakeup.

[0030] In this application, the original Vring shared memory mechanism is reused, specifically including: maintaining the Vring between the VM and the Host as shared memory, the VM accessing the Vring through Stage2 mapping, and the Host accessing the Vring through the conventional memory system.

[0031] In this application, for the lightweight virtualization VirtIO model, the VirtIO frontend requesting the backend service specifically includes: The VirtIO frontend thread stores the request memory in Vring and the request parameters in the interrupt parameter shared memory. The VirtIO frontend thread sends an interrupt to the host through the interrupt direct transmission mechanism, and then the VirtIO frontend thread is suspended, waiting to be woken up by the VirtIO-int interrupt; When the backend VirtIO-int handler is triggered, it wakes up the waiting VirtIO backend thread. The VirtIO backend thread obtains the requested memory from the Vring and the requested parameters from the interrupt parameter shared memory.

[0032] In this application, the request parameters include the VirtIO register address and the read / write content.

[0033] In this application, for the lightweight virtualization VirtIO model, the VirtIO backend completes the service notification to the frontend, specifically including: The backend VirtIO thread completes the service, updates the Vring, and writes the interrupt parameters corresponding to the request parameters to the Vring; The backend VirtIO thread sends an interrupt to the frontend VM through the interrupt direct transmission mechanism, which triggers the frontend VirtIO-int handler and wakes up the waiting frontend VirtIO thread. The VirtIO frontend thread obtains interrupt parameters and the updated Vring memory.

[0034] In this application, in the lightweight virtualization VirtIO model, all domains share the same UFS.

[0035] The domains in the lightweight virtualization VirtIO model include a first AP domain, a second AP domain, and a third AP domain; The first AP domain is used to run the UFS driver and the UFS driver backend; The second AP domain is the Android domain, which is used to map its own System, Data, and Vendor partitions to the backend; The third AP domain is an Ubuntu domain, used to map its own root partition and data partition to the backend.

[0036] This application, based on direct interrupt delivery, replaces the previous notification mechanism based on virtualization exit by enabling direct interrupt communication between the Guest and Host sides. It also reuses the Host-VM's Vring memory model based on the Stage2 shared memory mechanism of lightweight virtualization, and does not rely on the Hypervisor's VirtIO device model. Not only can the VSW system use the lightweight virtualization VirtIO model of this application, but it can also be used on AMP systems that combine shared memory and interoperable interrupts. Furthermore, it can improve the performance of VirtIO devices on existing virtualization systems.

[0037] Thirdly, embodiments of this application provide a lightweight virtualized VirtIO model implementation device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0038] Reference Figure 7 , Figure 7 This is a schematic diagram of the hardware structure of the lightweight virtualized VirtIO model implementation device involved in the embodiments of this application. In the embodiments of this application, the lightweight virtualized VirtIO model implementation device may include a processor, memory, communication interface, and communication bus.

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

[0040] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within a lightweight virtualized VirtIO model, as well as interfaces used for interconnecting devices 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.

[0041] 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.

[0042] The processor can be a general-purpose processor, which can call the lightweight virtualization VirtIO model implementation program stored in memory and execute the lightweight virtualization VirtIO model implementation 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 lightweight virtualization VirtIO model implementation program is called can be referred to in the various embodiments of the lightweight virtualization VirtIO model implementation method of this application, and will not be repeated here.

[0043] Those skilled in the art will understand that Figure 7 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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. A lightweight virtualization VirtIO model implementation method, characterized in that, The lightweight virtualization VirtIO model implementation method includes: Replace VirtIO's Notify mechanism with the Directly Deliver interrupt mechanism, and pass VirtIO registers and register values ​​via interrupt parameters shared memory; The original Vring shared memory mechanism is reused, and the Hypervisor's VCPU model is replaced with threads for the VM and Host. Replace the Hypervisor's VM exit / enter synchronization mechanism with the VM and Host's wait / wakeup mechanism.

2. The lightweight virtualization VirtIO model implementation method as described in claim 1, characterized in that, The reuse of the original Vring shared memory mechanism specifically includes: The Vring between the VM and the Host is kept as shared memory. The VM accesses the Vring through Stage2 mapping, while the Host accesses the Vring through the regular memory system.

3. The lightweight virtualization VirtIO model implementation method as described in claim 1, characterized in that, In the lightweight virtualization VirtIO model, the VirtIO frontend requests backend services, specifically including: The VirtIO frontend thread stores the request memory in Vring and the request parameters in the interrupt parameter shared memory. The VirtIO frontend thread sends an interrupt to the host through the interrupt direct transmission mechanism, and then the VirtIO frontend thread is suspended, waiting to be woken up by the VirtIO-int interrupt; When the backend VirtIO-int handler is triggered, it wakes up the waiting VirtIO backend thread. The VirtIO backend thread obtains the requested memory from the Vring and the requested parameters from the interrupt parameter shared memory.

4. The lightweight virtualization VirtIO model implementation method as described in claim 3, characterized in that: The request parameters include the VirtIO register address and the read / write content.

5. The lightweight virtualization VirtIO model implementation method as described in claim 3, characterized in that, In the aforementioned lightweight virtualization VirtIO model, the VirtIO backend completes the service notification to the frontend, specifically including: The backend VirtIO thread completes the service, updates the Vring, and writes the interrupt parameters corresponding to the request parameters to the Vring; The backend VirtIO thread sends an interrupt to the frontend VM through the interrupt direct transmission mechanism, which triggers the frontend VirtIO-int handler and wakes up the waiting frontend VirtIO thread. The VirtIO frontend thread obtains interrupt parameters and the updated Vring memory.

6. The lightweight virtualization VirtIO model implementation method as described in claim 1, characterized in that: In the lightweight virtualization VirtIO model, all domains share the same UFS.

7. The lightweight virtualization VirtIO model implementation method as described in claim 1, characterized in that: The domains in the lightweight virtualization VirtIO model include a first AP domain, a second AP domain, and a third AP domain; The first AP domain is used to run the UFS driver and the UFS driver backend; The second AP domain is the Android domain, which is used to map its own System, Data, and Vendor partitions to the backend; The third AP domain is an Ubuntu domain, used to map its own root partition and data partition to the backend.

8. A lightweight virtualized VirtIO model implementation device, characterized in that, The lightweight virtualized VirtIO model implementation device includes: The replacement module replaces VirtIO's Notify mechanism with a Directly Deliver interrupt mechanism and uses interrupt parameters to share memory to transfer VirtIO registers and register values. The reuse module is used to reuse the original Vring shared memory mechanism and replace the Hypervisor's VCPU model with VM and Host threads. The processing module replaces the Hypervisor's VM exit / enter synchronization mechanism with the VM and Host's wait / wakeup mechanism.

9. A lightweight virtualized VirtIO model implementation device as described in claim 8, characterized in that, The reuse of the original Vring shared memory mechanism specifically includes: The Vring between the VM and the Host is kept as shared memory. The VM accesses the Vring through Stage2 mapping, while the Host accesses the Vring through the regular memory system.

10. A lightweight virtualized VirtIO model implementation device, characterized in that, The lightweight virtualized VirtIO model implementation device includes a processor, a memory, and a lightweight virtualized VirtIO model implementation program stored in the memory and executable by the processor, wherein when the lightweight virtualized VirtIO model implementation program is executed by the processor, it implements the steps of the lightweight virtualized VirtIO model implementation method as described in any one of claims 1 to 7.

Images