Virtual machine cross-operating system communication method based on microkernel Hypervisor

Abstract

The invention discloses a micro-kernel Hypervisor-based virtual machine cross-operating system communication method, which comprises the following steps of: creating virtual machines which independently run in respective operating system environments by a micro-kernel Hypervisor, then constructing a shared memory between two virtual machines with communication requirements, respectively initializing virtual machine shared equipment by the two virtual machines, and storing the virtual machine shared equipment in the shared memory; according to the cross-operating-system communication method, the shared memory is mapped to a virtual address of the shared memory, when one virtual machine needs to transmit data to the opposite side, communication is initiated to write the data into the shared memory, and the virtual machine receiving the data reads the data from the shared memory, so that cross-operating-system communication of the virtual machines is realized. Based on the shared memory technology, the communication process of the shared memory and the virtual machines is managed by using the microkernel Hypervisor, and cross-operating system communication between the virtual machines is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of virtual machines, and more specifically, relates to a virtual machine cross-operating system communication method based on a microkernel Hypervisor. Background Art

[0002] Virtual machine technology has been developed in server and desktop environments for decades, and has also played a role in promoting the rapid development of cloud computing. Virtualization technology abstracts physical hardware resources (such as servers, storage, networks, and memory) into virtual resources, and divides a single physical resource into multiple virtual resources. Each virtual resource can be independently allocated to different operating systems to achieve effective resource isolation. In the field of embedded systems, such as vehicle-mounted platforms, with the rapid development of intelligence, virtualization technology can make full use of limited resources and support multiple operating systems running on the same hardware platform, each playing a different role.

[0003] The hypervisor implements the isolation and sharing of processor resources, memory resources, and peripheral resources between different partitions, so the upper-level virtual machines cannot communicate directly. However, a key function of virtualization is the sharing of data and memory between virtual machines and between the host system and virtual machines. To achieve this goal, there are currently several main methods for inter-virtual machine communication:

[0004] Communication between virtual machines is achieved through network sockets, and virtual network interface cards (vNICs) and virtual switches (vSwitches) are used to simulate physical network environments. Each virtual machine is equipped with a vNIC, which is connected through a vSwitch to achieve standard network communication. Socket programming based on TCP or UDP protocols enables virtual machines to exchange data within the same physical host or across hosts. This method has a wide range of uses and is not limited by scenarios, but the Socket interface data transmission using the TCP / IP protocol needs to go through the protocol stack and requires multiple data copies, and will inevitably be affected by network delays, so there is a certain performance overhead.

[0005] Shared memory technology has become a key means to achieve efficient communication between virtual machines. Compared with traditional network communication, this method not only provides higher communication efficiency, but is also particularly suitable for symbiotic virtual machines running on the same physical hardware platform. Using shared memory, these virtual machines can directly open up shared areas in physical memory, thereby realizing data sharing operations between clients. This method not only avoids the delay problem that may occur in network communication, but also greatly reduces the number of copies of data during transmission, thereby improving the speed of data transmission and the overall performance of the system.

[0006] XenSocket is a high-throughput unidirectional inter-VM communication mechanism that uses a shared memory buffer between communicating VMs to completely bypass the network protocol stack. The receiving VM allocates a pool of 128KB pages and asks the Xen hypervisor to share these pages with the sending VM, which are reused in a circular buffer. XenSocket is a unidirectional communication pipe, and the upper layer interface still relies on a network socket-like method for data exchange.

[0007] XenLoop uses shared memory to create a ring buffer to support inter-VM network communication on the same hardware platform. No changes are required to existing applications, libraries, or front-end network devices to use XenLoop. A potential disadvantage of the XenLoop design is that the virtual machine operating system or application cannot use shared memory directly, and data is still copied through the network stack.

[0008] XenLoop and XenSocket are both ways of communicating between virtual machines on the Xen virtual machine manager. Although they both rely on shared memory at the bottom layer, virtual machines still need to establish upper-layer communication through network sockets. In addition, virtual machines cannot directly use shared memory, and data is still copied through the network stack. During the communication process, it will be affected by network communication and there will be performance loss problems.

[0009] IVSHMEM (Inter-VM Shared Memory) is a shared memory protocol between virtual machines implemented in QEMU, and is used as the underlying implementation mechanism for virtual machine communication in virtual machine managers such as Jailhouse and Acrn. IVSHMEM allocates a shared memory area between hosts and maps it to the virtual machine address space. Each virtual machine accesses data through a virtual PCI device, and implements message notifications between virtual machines through an interrupt mechanism. IVSHMEM relies on the Linux operating system, and virtual machines access shared memory areas through virtual PCI devices. IVSHMEM does not require network communication between virtual machines. Two virtual machines rely on virtual PCI devices to exchange data, and when multiple virtual machines access the same memory area, data synchronization cannot be guaranteed. If the virtual machine itself does not support PCI devices, the two cannot directly establish a point-to-point connection for data transmission. For virtualized communication, when multiple virtual machines communicate simultaneously, real-time performance is a requirement. IVSHMEM does not support a notification mechanism based on priority between virtual machines, and only supports a first-come, first-served event notification mechanism between virtual machines. Summary of the invention

[0010] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a virtual machine cross-operating system communication method based on a microkernel Hypervisor. Based on shared memory technology, the microkernel Hypervisor is used to manage the communication process between shared memory and virtual machines, thereby realizing cross-operating system communication between virtual machines.

[0011] In order to achieve the above-mentioned object of the invention, the virtual machine cross-operating system communication method based on the microkernel Hypervisor of the present invention comprises the following steps:

[0012] S1: The microkernel Hypervisor creates a virtual machine and configures shared memory. The specific steps are as follows:

[0013] S1.1: The microkernel Hypervisor creates virtual machines VM_A and VM_B according to the configuration file set by the user. VM_A and VM_B run independently in their respective operating system environments without interfering with each other. The configuration file contains the configuration parameters required for each virtual machine to communicate, mainly including the virtual machine communication channel identifier shmid, the shared memory address shm_addr, the shared memory size shm_size and the interrupt number irq_num;

[0014] S1.2: The Hypervisor uses the malloc function to allocate a block of memory for the shared memory of virtual machines VM_A and VM_B according to the shared memory size shm_size, and sets its identifier to shmid; then the Hypervisor maps this shared memory to virtual machines VM_A and VM_B through the secondary page table;

[0015] S1.3: Hypervisor initializes the event channel notification mechanism. The specific method is as follows: Hypervisor initializes the notification object through the notification_init function to manage the communication between virtual machines. Then the root service rootserver initiates the system call syscall, finds the processing function associated with the notification object according to the capability pointer cptr, and calls the notification_wait function to block the service thread used for virtual machine communication data management in the root service rootserver, waiting for the arrival of the hypercall;

[0016] S1.4: Initialize a priority communication queue priority_queue_t in the root service rootserver for managing the communication between all virtual machines. The priority communication queue priority_queue_t is implemented based on a bidirectional linked list, including a bidirectional linked list node structure list_head_t and a queue element structure queue_node_t, where:

[0017] The doubly linked list node structure list_head_t contains pointers to the previous node and the next node;

[0018] The queue element structure queue_node_t contains the priority prio, the shared memory identifier shmid, the data buffer pointer buf and a doubly linked list node node;

[0019] S2: VM_A and VM_B create and initialize the VMshm shared device respectively. The specific method is as follows:

[0020] The virtual machine divides two memory areas for the virtual machine shared device VMshm, one for the write buffer writebuffer and the other for the read buffer read buffer;

[0021] Then define the VM_shmem structure for managing the read and write buffer of shared memory, which includes the device ID, the base address and size of the read and write buffer, and the physical base address; the virtual machine uses the VM_shmem_read_fops function and the VM_shmem_write_fops function to process the read and write operations of the shared memory respectively, wherein: the read operation copies the data in the shared memory to the read buffer, and the read operation is implemented through the interrupt mechanism. Each virtual machine shared device VMshm has a corresponding interrupt number irq_num and registers the corresponding interrupt processing function. When the virtual interrupt is injected into the virtual machine, the virtual machine finds the corresponding interrupt handler and then calls VM_shmem_read_fops to read data from the read buffer; the write operation copies the data from the write buffer to the shared memory, and initiates a hypercall through the VM_shmem_hvc function to notify the corresponding virtual machine to read the data;

[0022] The virtual machine registers and initializes the virtual machine shared device VMshm in the Linux platform device, including reading the device tree attributes, mapping the shared memory, creating the character device and generating the device node;

[0023] S3: When one of VM_A and VM_B needs to initiate communication with the other, the VM writes data to the writer buffer of the bound VMshm shared device, initiates a hypercall, writes the identifier shmid to register x1, and writes the priority prio to register x2. Register x0 is used to receive the result returned by the Hypervisor after processing the hypercall.

[0024] S4: After receiving the hypercall from the initiating virtual machine, the Hypervisor jumps to the kernel's aborts_sync_handler function to handle the synchronous exception, finds the corresponding processing function according to the exception type, and then finds the notification pointer object at the time of initialization, calls the notification_signal function to unblock the service thread used for virtual machine communication data management, and transfers the processing to the root service rootserver;

[0025] S5: After the service thread for virtual machine communication data management in the root service rootserver is unblocked, the identifier shmid, priority prio and communication data transmitted by the hypercall are extracted, and a new queue node is created to store this information. The specific method is as follows: first, the address of the write buffer writerbuffer associated with the shared memory is found according to the identifier shmid, and the memory copy function is used to directly copy the data from the write buffer writer buffer to the corresponding field of the newly created queue node; then, according to the priority prio, the node is inserted into the corresponding position of the priority communication queue priority_queue_t;

[0026] S6: The unblocked service thread in the root service rootserver of the Hypervisor takes out the first node of the queue from the priority communication queue priority_queue_t in turn; when the identifiers shmid of the two nodes are the same, it indicates that the two virtual machines are establishing communication, and then copies the communication data saved by the node to the read buffer readbuffer of the receiving virtual machine, finds the physical core information of the receiving virtual machine, initiates inter-core communication, and notifies the interrupt controller to inject the corresponding virtual interrupt;

[0027] After receiving the virtual interrupt, the virtual machine receiving the communication determines that this is the device used for virtual machine communication based on the interrupt number irq_num, and then calls the interrupt handler corresponding to the interrupt to read data from the read buffer to complete a communication.

[0028] The present invention is based on a virtual machine cross-operating system communication method of a microkernel Hypervisor. The microkernel Hypervisor creates virtual machines that run independently in their respective operating system environments, and then builds a shared memory between two virtual machines with communication requirements. The two virtual machines respectively initialize virtual machine shared devices and map the shared memory to their own virtual addresses. When one virtual machine needs to transmit data to the other, communication is initiated to write the data into the shared memory, and the virtual machine receiving the data reads the data from the shared memory, thereby realizing cross-operating system communication of the virtual machines.

[0029] The present invention has the following beneficial effects:

[0030] 1) The present invention is based on shared memory technology and uses a microkernel Hypervisor as a host operating system to efficiently manage and allocate virtual machine resources. The shared memory areas between virtual machines are precisely controlled by capabilities, effectively ensuring that only the two virtual machines that have established a communication connection can access these memory areas, while other virtual machines cannot access them, thereby greatly improving data security;

[0031] 2) The present invention establishes a priority-driven message notification mechanism by configuring event priorities according to the priorities of virtual machines on the microkernel Hypervisor, which ensures that in the case of urgent communication events, virtual machines with high priorities can share data first, optimize resource allocation and communication efficiency, ensure efficient resource utilization in a multi-task concurrent execution environment, and enable each virtual machine to run and communicate independently under the premise of ensuring performance;

[0032] 3) The present invention adopts a more universal virtual device configuration mode inside the virtual machine. Compared with the traditional PCI device, this virtual device configuration has higher compatibility and applicability in different operating systems. Through this virtual device, efficient data exchange can be achieved between virtual machines, overcoming some limitations of traditional PCI devices in virtualized environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a flow chart of a specific implementation of the cross-operating system communication method based on the microkernel Hypervisor of the present invention;

[0034] Figure 2 It is a flow chart of the microkernel Hypervisor in the present invention creating a virtual machine and configuring shared memory;

[0035] Figure 3 is a structural diagram of a priority communication queue in the present invention;

[0036] Figure 4 It is a memory sharing architecture diagram between virtual machines in the present invention;

[0037] Figure 5 4 is a system architecture diagram of virtual machine communication in this embodiment. DETAILED DESCRIPTION

[0038] The specific implementation of the present invention is described below in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0039] Example

[0040] Figure 1 FIG. 1 is a flow chart of a specific implementation of the cross-operating system communication method based on the microkernel Hypervisor of the present invention. Figure 1 As shown, the specific steps of the cross-operating system communication method based on the microkernel Hypervisor of the present invention include:

[0041] S101: Microkernel Hypervisor creates virtual machines and configures shared memory:

[0042] The focus of the microkernel Hypervisor in the present invention is to ensure the reasonable allocation, accurate mapping and comprehensive protection of shared memory. The Hypervisor not only needs to ensure the efficiency of shared memory allocation, but also needs to ensure that only the associated virtual machine can access the specific shared memory to prevent unauthorized access. In addition, the Hypervisor also needs to effectively manage the data transmission between virtual machines and establish an efficient event notification mechanism to ensure that the information transmission in the communication process can be timely and reliable. Based on the above analysis, the present invention proposes a specific method for the microkernel Hypervisor to create a virtual machine and configure shared memory. Figure 2 FIG. 1 is a flowchart of the microkernel Hypervisor in the present invention creating a virtual machine and configuring shared memory. Figure 2 As shown, the specific steps of the microkernel Hypervisor in the present invention to create a virtual machine and configure shared memory include:

[0043] S201: Create a virtual machine:

[0044] The microkernel Hypervisor creates virtual machines VM_A and VM_B according to the configuration file set by the user. VM_A and VM_B run independently in their respective operating system environments without interfering with each other. The configuration file contains the configuration parameters required for each virtual machine to communicate, including the virtual machine communication channel identifier shmid, the shared memory address shm_addr, the shared memory size shm_size and the interrupt number irq_num. In this embodiment, when creating a virtual machine, the Hypervisor adopts a static physical resource allocation strategy, that is, when the virtual machine is started, the required physical resources (such as CPU, memory, peripherals, etc.) are directly allocated to the virtual machine, and no dynamic allocation is performed after the virtual machine is running.

[0045] S202: Allocate shared memory and map it to the virtual machine:

[0046] Since all resources of the microkernel Hypervisor are protected based on capabilities, each virtual machine corresponds to a kernel object CAP_VM. Therefore, in the present invention, the Hypervisor uses the malloc function to allocate a piece of memory for the shared memory of virtual machines VM_A and VM_B according to the shared memory size shm_size, and its identifier is set to shmid. This shared memory is used for data transmission between virtual machines and is protected by capabilities. Only virtual machines VM_A and VM_B can have access rights. Therefore, the Hypervisor maps this shared memory to virtual machines VM_A and VM_B through a stage-2 page table to enable access. It should be noted that although the shared memory accessed between the two virtual machines is the same piece of memory, the physical address of the shared memory seen by each virtual machine may be different. This is because the Hypervisor maps the shared memory address seen by each virtual machine separately, thereby ensuring that the virtual machine can access the correct address.

[0047] S203: Initialize event channel notification mechanism:

[0048] The notification object is a resource type that is managed and referenced through capabilities. The inter-process communication of the microkernel Hypervisor relies on the notification mechanism. Because the synchronous exception handling of the hypercall will be trapped in the kernel, but the actual handler is in the root service rootserver. When a hypercall arrives, the service thread in the root service is notified through the notification mechanism for specific processing. Therefore, the Hypervisor needs to initialize the event channel notification mechanism. The specific method is:

[0049] The hypervisor initializes the notification object through the notification_init function to manage the communication between virtual machines. Then the root service Rootserver initiates the system call syscall, finds the processing function associated with the notification object according to the capability pointer cptr (capability pointer), and calls the notification_wait function to block the service thread used for virtual machine communication data management in the root service rootserver, waiting for the arrival of the hypercall.

[0050] S204: Initialize the priority communication queue:

[0051] Initialize a priority communication queue priority_queue_t in the root service rootserver to manage communication between all virtual machines. Figure 3 : is a structural diagram of the priority communication queue in the present invention. Figure 3 As shown, the priority communication queue priority_queue_t in the present invention is implemented based on a bidirectional linked list, including a bidirectional linked list node structure list_head_t and a queue element structure queue_node_t, wherein:

[0052] The doubly linked list node structure list_head_t contains pointers to the previous node and the next node.

[0053] The queue element structure queue_node_t contains the priority prio, the shared memory identifier shmid, the data buffer pointer buf, and a doubly linked list node node.

[0054] Depend on Figure 3 It can be seen that each node in the queue is sorted in order according to the size of the priority prio, and subsequent searches and insertions are also based on the priority prio.

[0055] S102: The virtual machine initializes shared memory:

[0056] In order to realize virtual machine communication, virtual machines VM_A and VM_B also need to initialize shared memory. From the perspective of the virtual machine, shared memory is designed as a common external device and non-PCI device. In order to support this structure, it is necessary to modify the source code in the Linux kernel and add a virtual machine shared device VMshm to each virtual machine. The base address of this device corresponds to the base address of the shared memory area, and its driver is responsible for implementing the specific read and write operations when communicating between virtual machines. Virtual machines VM_A and VM_B respectively create virtual machine shared devices VMshm and initialize them. The specific methods are as follows:

[0057] The virtual machine divides two memory areas for the virtual machine shared device VMshm, one for the write buffer writebuffer and the other for the read buffer read buffer. The core advantage of this design is that it implements asynchronous full-duplex communication, that is, the virtual machine can perform read and write operations at the same time without waiting for the other party to complete the operation, which improves the efficiency of data transmission between virtual machines.

[0058] Then define the VM_shmem structure for managing the read and write buffer of shared memory, which includes the device ID, the base address and size of the read and write buffer, and the physical base address. The virtual machine uses the VM_shmem_read_fops function and the VM_shmem_write_fops function to process the read and write operations of the shared memory respectively, where: the read operation copies the data in the shared memory to the read buffer, and the read operation is implemented through the interrupt mechanism. Each virtual machine shared device VMshm has a corresponding interrupt number irq_num and registers the corresponding interrupt processing function. When the virtual interrupt is injected into the virtual machine, the virtual machine finds the corresponding interrupt handler and then calls VM_shmem_read_fops to read data from the read buffer; the write operation copies the data from the write buffer to the shared memory, and initiates a hypercall through the VM_shmem_hvc function to notify the corresponding virtual machine to read the data.

[0059] The driver management of the virtual machine shared device VMshm is implemented through the Linux platform device. Therefore, the virtual machine registers and initializes the virtual machine shared device VMshm in the Linux platform device, including reading the device tree attributes, mapping the shared memory, creating the character device and generating the device node.

[0060] Based on the above process, a complete memory sharing architecture between virtual machines is established. Figure 4 : is a memory sharing architecture diagram between virtual machines in the present invention. Figure 4 As shown, in the present invention, two virtual machines read and write data to the writer buffer and read buffer of the shared memory through their respective virtual machine shared devices VMshm, thereby completing the communication between the virtual machines. Compared with traditional PCI devices, this communication mechanism based on shared memory has several advantages. First, PCI devices usually rely on the hardware bus for communication, which is complex to configure and operate and has a large overhead. The virtual machine shared device VMshm directly transmits data between virtual machines through shared memory, reducing the dependence on hardware resources and communication overhead. Secondly, the communication mode of PCI devices is usually asynchronous and interrupt-driven, while the virtual machine shared device VMshm implements synchronous processing through kernel management and hypercall notification, and has a faster response speed. In addition, the design of the virtual machine shared device VMshm simplifies the communication model between virtual machines, which is easy to expand and maintain.

[0061] S103: The virtual machine initiates communication:

[0062] When one of the virtual machines VM_A and VM_B needs to initiate communication with the other, the virtual machine writes data to the writer buffer of the bound virtual machine shared device VMshm, writes the identifier shmid to register x1 after initiating a hypercall, and writes the priority prio to register x2. Register x0 is used to receive the result returned by the Hypervisor after processing the hypercall.

[0063] S104: Hypervisor processes hypercall:

[0064] After the Hypervisor receives the hypercall from the initiating virtual machine, it jumps to the kernel's aborts_sync_handler function to handle the synchronous exception, finds the corresponding processing function according to the exception type, and then finds the notification pointer object at the time of initialization, calls the notification_signal function to unblock the service thread used for virtual machine communication data management, and transfers the processing to the root service rootserver.

[0065] S105: Root service replication data:

[0066] After the service thread for virtual machine communication data management in the root server is unblocked, the identifier shmid, priority prio and communication data sent by the hypercall are extracted, and a new queue node is created to save this information. The specific method is as follows: first, the address of the writer buffer associated with the shared memory is found according to the identifier shmid. Since the Hypervisor has full access to the shared memory area, the memory copy function can be used directly to copy the data from the writer buffer to the corresponding field of the newly created queue node. Then, according to the priority prio, the node is inserted into the corresponding position of the priority communication queue priority_queue_t.

[0067] S106: Communication completed:

[0068] The service thread that has been unblocked in the root service rootserver of the Hypervisor takes out the first node of the queue from the priority communication queue priority_queue_t in turn. The advantage of this is that it can meet the real-time requirements and give priority to notifying the virtual machines that are in urgent need of communication. When the identifiers shmid of two nodes are the same, it means that the two virtual machines are establishing communication, and then copy the communication data saved by the node to the read buffer of the receiving virtual machine, find the physical core information of the receiving virtual machine, initiate inter-core communication, and notify the interrupt controller to inject the corresponding virtual interrupt.

[0069] After receiving the virtual interrupt, the virtual machine receiving the communication determines that this is the device used for virtual machine communication based on the interrupt number irq_num, and then calls the interrupt handler corresponding to the interrupt to read data from the read buffer to complete a communication.

[0070] Figure 5 : is a system architecture diagram of virtual machine communication in this embodiment. Figure 5 As shown, this embodiment includes three virtual machine pairs, namely virtual machines VM0 and VM1, virtual machines VM2 and VM3, virtual machines VM4 and VM5, wherein the virtual machine communication channel identifier shmid=0 and priority prio=0 of virtual machines VM0 and VM1; the virtual machine communication channel identifier shmid=1 and priority prio=1 of virtual machines VM2 and VM3; the virtual machine communication channel identifier shmid=2 and priority prio=3 of virtual machines VM4 and VM5. Each node in the priority communication queue priority_queue_t in the root service of the Hypervisor corresponds to one virtual machine communication, and the Hypervisor takes out each node in turn to complete the communication.

[0071] Although the above describes the illustrative specific embodiments of the present invention to facilitate those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations using the concept of the present invention are protected.

Claims

1. A virtual machine cross-operating system communication method based on a microkernel hypervisor, characterized in that: The following steps are involved: S1: The microkernel Hypervisor creates a virtual machine and configures shared memory. The specific steps are as follows: S1.1: The microkernel Hypervisor creates virtual machines VM_A and VM_B according to the configuration file set by the user. VM_A and VM_B run independently in their respective operating system environments without interfering with each other. The configuration file contains the configuration parameters required for each virtual machine to communicate, mainly including the virtual machine communication channel identifier shmid, the shared memory address shm_addr, the shared memory size shm_size and the interrupt number irq_num; S1.2: The Hypervisor uses the malloc function to allocate a block of memory for the shared memory of virtual machines VM_A and VM_B according to the shared memory size shm_size, and sets its identifier to shmid; then the Hypervisor maps this shared memory to virtual machines VM_A and VM_B through the secondary page table; S1.3: Hypervisor initializes the event channel notification mechanism. The specific method is as follows: Hypervisor initializes the notification object through the notification_init function to manage the communication between virtual machines. Then the root service rootserver initiates the system call syscall, finds the processing function associated with the notification object according to the capability pointer cptr, and calls the notification_wait function to block the service thread used for virtual machine communication data management in the root service rootserver, waiting for the arrival of the hypercall; S1.4: Initialize a priority communication queue priority_queue_t in the root service rootserver for managing the communication between all virtual machines. The priority communication queue priority_queue_t is implemented based on a bidirectional linked list, including a bidirectional linked list node structure list_head_t and a queue element structure queue_node_t, where: The doubly linked list node structure list_head_t contains pointers to the previous node and the next node; The queue element structure queue_node_t contains the priority prio, the shared memory identifier shmid, the data buffer pointer buf and a doubly linked list node node; S2: VM_A and VM_B create and initialize the VMshm shared device respectively. The specific method is as follows: The virtual machine divides two memory areas for the virtual machine shared device VMshm, one for the write buffer and the other for the read buffer; Then define the VM_shmem structure for managing the read and write buffer of shared memory, which includes the device ID, the base address and size of the read and write buffer, and the physical base address; the virtual machine uses the VM_shmem_read_fops function and the VM_shmem_write_fops function to process the read and write operations of the shared memory respectively, wherein: the read operation copies the data in the shared memory to the read buffer, and the read operation is implemented through the interrupt mechanism. Each virtual machine shared device VMshm has a corresponding interrupt number irq_num and registers the corresponding interrupt processing function. When the virtual interrupt is injected into the virtual machine, the virtual machine finds the corresponding interrupt handler and then calls VM_shmem_read_fops to read data from the read buffer; the write operation copies the data from the write buffer to the shared memory, and initiates a hypercall through the VM_shmem_hvc function to notify the corresponding virtual machine to read the data; The virtual machine registers and initializes the virtual machine shared device VMshm in the Linux platform device, including reading the device tree attributes, mapping the shared memory, creating the character device and generating the device node; S3: When one of VM_A and VM_B needs to initiate communication with the other, the VM writes data to the writer buffer of the bound VMshm shared device, initiates a hypercall, writes the identifier shmid to register x1, and writes the priority prio to register x2. Register x0 is used to receive the result returned by the Hypervisor after processing the hypercall. S4: After receiving the hypercall from the initiating virtual machine, the Hypervisor jumps to the kernel's aborts_sync_handler function to handle the synchronous exception, finds the corresponding processing function according to the exception type, and then finds the notification pointer object at the time of initialization, calls the notification_signal function to unblock the service thread used for virtual machine communication data management, and transfers the processing to the root service rootserver; S5: After the service thread for virtual machine communication data management in the root service rootserver is unblocked, the identifier shmid, priority prio and communication data transmitted by the hypercall are extracted, and a new queue node is created to store this information. The specific method is as follows: first, the address of the write buffer writer buffer associated with the shared memory is found according to the identifier shmid, and the memory copy function is directly used to copy the data from the write buffer writer buffer to the corresponding field of the newly created queue node; then, according to the priority prio, the node is inserted into the corresponding position of the priority communication queue priority_queue_t; S6: The unblocked service thread in the root service rootserver of the Hypervisor takes out the first node of the queue from the priority communication queue priority_queue_t in turn; when the identifiers shmid of the two nodes are the same, it indicates that the two virtual machines are establishing communication, and then copies the communication data saved by the node to the read buffer readbuffer of the receiving virtual machine, finds the physical core information of the receiving virtual machine, initiates inter-core communication, and notifies the interrupt controller to inject the corresponding virtual interrupt; After receiving the virtual interrupt, the virtual machine receiving the communication determines that this is the device used for virtual machine communication based on the interrupt number irq_num, and then calls the interrupt handler corresponding to the interrupt to read data from the read buffer to complete a communication.

2. The virtual machine cross-operating system communication method according to claim 1, characterized in that: In step S1, when creating a virtual machine, the Hypervisor adopts a static physical resource allocation strategy.

Images