Virtual Machine Cross-Operating System Communication Method Based on Microkernel Hypervisor

Abstract

The present invention discloses a virtual machine cross-operating system communication method based on a microkernel Hypervisor. The microkernel Hypervisor creates virtual machines that independently run in their respective operating system environments, and then constructs a shared memory between two virtual machines with communication requirements. The two virtual machines respectively initialize the virtual machine shared device, map the shared memory to their own virtual addresses. When a virtual machine needs to transmit data to the other party, it initiates communication and writes 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 virtual machines. The present invention is based on shared memory technology, and uses the microkernel Hypervisor to manage the shared memory and the communication process of virtual machines, realizing cross-operating system communication between virtual machines.

Description

Technical Field

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

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

[0003] The virtual machine manager (Hypervisor) realizes the isolation and sharing of processor resources, memory resources, and peripheral resources between different partitions. Therefore, virtual machines at the upper layer cannot directly communicate with each other. However, a key function of virtualization is data and memory sharing between virtual machines and between the host system and virtual machines. To achieve this goal, there are currently the following main methods for inter-virtual machine communication:

[0004] Realize communication between virtual machines through network sockets, and use virtual network interface cards (vNICs) and virtual switches (vSwitches) to simulate the physical network environment. Each virtual machine is equipped with a vNIC and is connected through a vSwitch to achieve standard network communication. Socket programming based on the TCP or UDP protocol enables virtual machines to exchange data within the same physical host or across hosts. This method has a wide range of applications and no scene limitations. However, data transmission through the Socket interface of the TCP / IP protocol needs to pass through the protocol stack, requires multiple data copies, and is inevitably affected by network latency. Therefore, 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 can not only provide higher communication efficiency but is also particularly suitable for co-existing virtual machines running on the same physical hardware platform. Using shared memory, these virtual machines can directly create a shared area in physical memory to achieve data sharing operations between guest machines. This method not only avoids possible latency problems in network communication but also greatly reduces the number of data copies during data transmission, thereby improving the data transmission speed and the overall performance of the system.

[0006] XenSocket is a high-throughput one-way 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 128KB page pool and asks the Xen hypervisor to share these pages with the sending VM, and these pages are reused in a circular buffer. XenSocket is a one-way communication pipeline, and the upper-layer interface still relies on a network socket-like way to exchange data.

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

[0008] Both XenLoop and XenSocket are inter-VM communication methods on the Xen hypervisor. Although they both rely on shared memory at the bottom layer, the VMs still need to establish upper-layer communication through network sockets. Moreover, the VMs cannot directly use the shared memory, and the data will still be copied through the network stack, which will be affected by network communication during the communication process and there will be performance loss problems.

[0009] IVSHMEM (Inter-VM Shared Memory) is an inter-VM shared memory protocol implemented in QEMU and serves as the underlying implementation mechanism for VM 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 the data through a virtual PCI device and realizes message notification between virtual machines through the interrupt mechanism. IVSHMEM depends on the Linux operating system, and the virtual machine accesses the shared memory area through a virtual PCI device. IVSHMEM does not require the establishment of network communication between virtual machines. The 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, a direct point-to-point connection cannot be established between them 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 priorities between virtual machines and only supports a first-come, first-served method for event notification between virtual machines. Summary of the Invention

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

[0011] To achieve the above object of the invention, the method for cross-operating system communication of virtual machines based on a microkernel Hypervisor of the present invention comprises the following steps:

[0012] S1: The microkernel Hypervisor creates virtual machines and configures shared memory. The specific method is 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 the communication of each virtual machine, 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 allocates a block of memory for the shared memory of virtual machines VM_A and VM_B using the malloc function according to the shared memory size shm_size, and sets its identifier as shmid; then maps this block of shared memory to virtual machines VM_A and VM_B through a two-level page table;

[0015] S1.3: The Hypervisor initializes the event channel notification mechanism. The specific method is as follows: The Hypervisor initializes a notification object through the notification_init function to manage the communication between virtual machines. Then the root service rootserver initiates a 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 in the root service rootserver for managing the communication data of virtual machines, waiting for the arrival of the hypercall;

[0016] S1.4: Initialize a priority communication queue priority_queue_t for managing the communication between all virtual machines in the root service rootserver. The priority communication queue priority_queue_t is implemented based on a doubly linked list and includes a doubly 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 each create a shared VM device, VMshm, and initialize it. The specific steps are as follows:

[0020] The virtual machine divides two memory areas for the virtual machine shared device VMshm, one as the write buffer writebuffer and the other as 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 handle the read and write operations on 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;

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

[0023] S3: When one of VM_A and VM_B needs to initiate communication with the other, it writes data to the write buffer of the bound shared device VMshm, 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 the Hypervisor receives the hypercall from the initiating virtual machine, it jumps to the aborts_sync_handler function in the kernel for synchronous exception handling. It finds the corresponding handler according to the exception type, then locates the notification pointer object during initialization, and calls the notification_signal function to unblock the service thread 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, it extracts the identifier shmid, priority prio, and communication data passed by the hypercall, and creates a new queue node to save this information. The specific method is as follows: First, find the address of the write buffer writebuffer associated with the shared memory according to the identifier shmid, and directly use the memory copy function to copy the data from the write buffer write buffer to the corresponding fields of the newly created queue node; then insert the node into the corresponding position of the priority communication queue priority_queue_t according to the priority prio;

[0026] S6: The unblocked service threads in the root service rootserver of the Hypervisor sequentially take out the head nodes of the queue from the priority communication queue priority_queue_t; when the identifiers shmid of two nodes are the same, it indicates that these two virtual machines are establishing communication, and then copy the communication data saved in the node to the read buffer readbuffer of the receiving virtual machine, find the physical core information where the receiving virtual machine is located, initiate inter-core communication, and notify the interrupt controller to inject the corresponding virtual interrupt;

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

[0028] The virtual machine cross-operating system communication method based on the microkernel Hypervisor of the present invention creates virtual machines that independently run in their respective operating system environments by the microkernel Hypervisor, then constructs a shared memory between two virtual machines with communication requirements, the two virtual machines respectively initialize the virtual machine shared device, map the shared memory to their own virtual addresses, when a virtual machine needs to transfer data to the other party, it initiates communication and writes the data into the shared memory, and the receiving virtual machine reads the data from the shared memory, thereby realizing the cross-operating system communication of virtual machines.

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

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

[0031] 2) By configuring event priorities according to the priorities of virtual machines on the microkernel Hypervisor, the present invention establishes a priority-driven message notification mechanism. This ensures that in the case of urgent communication events, virtual machines with higher priorities can share data first, optimizing resource allocation and communication efficiency, ensuring efficient resource utilization in a multi-task concurrent execution environment, and enabling each virtual machine to operate and communicate independently while ensuring performance;

[0032] 3) The present invention adopts a more general virtual device configuration method inside the virtual machine. Compared with traditional PCI devices, 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 the virtualization environment. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] Figure 2 is a flowchart of creating virtual machines and configuring shared memory by the microkernel Hypervisor in the present invention;

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

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

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

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

[0039] Embodiment

[0040] Figure 1 is the flowchart of the specific implementation manner of the cross - operating - system communication method based on the micro - kernel Hypervisor of the present invention. As Figure 1 shown, the specific steps of the cross - operating - system communication method based on the micro - kernel Hypervisor of the present invention include:

[0041] S101: The micro - kernel Hypervisor creates virtual machines and configures shared memory:

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

[0043] S201: Create virtual machines:

[0044] The micro - kernel 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 communication, including the virtual - machine communication - channel identifier shmid, shared - memory address shm_addr, shared - memory size shm_size, and interrupt number irq_num. In this embodiment, when creating virtual machines, the Hypervisor adopts a static physical - resource allocation strategy, that is, directly allocates the required physical resources (such as CPU, memory, peripherals, etc.) to the virtual machines when the virtual machines are started, and no dynamic allocation is performed after the virtual machines run.

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

[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, Hypervisor allocates a block of memory for the shared memory of virtual machines VM_A and VM_B using the malloc function according to the shared memory size shm_size, and sets its identifier 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 have access rights. Therefore, Hypervisor maps this shared memory to virtual machines VM_A and VM_B through a stage-2 page table so that they can access it. It should be noted that although the shared memory accessed between the two virtual machines is the same block of memory, the physical addresses of the shared memory seen by each virtual machine may be different because Hypervisor maps the shared memory addresses seen by each virtual machine itself, thus ensuring that the virtual machine can access the correct address.

[0047] S203: Initialize the event channel notification mechanism:

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

[0049] Hypervisor initializes the notification object through the notification_init function to manage the communication between virtual machines. Then, the root service Rootserver initiates a system call syscall, finds the handler 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 for managing virtual machine communication data in the root service rootserver and wait for the arrival of the hypercall.

[0050] S204: Initialize the priority communication queue:

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

[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 a priority prio, a shared memory identifier shmid, a pointer buf to the data buffer, and a doubly linked list node node.

[0054] It can be seen from Figure 3 that each node of the queue is sorted in an orderly manner 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 the shared memory:

[0056] To implement virtual machine communication, the virtual machines VM_A and VM_B also need to initialize the shared memory. From the perspective of the virtual machine, the shared memory is designed as an ordinary external device and a non-PCI device. To support this structure, it is necessary to modify the source code in the Linux kernel to add a virtual machine shared device VMshm for 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 during virtual machine communication. The virtual machines VM_A and VM_B respectively create and initialize the virtual machine shared device VMshm. The specific method is as follows:

[0057] The virtual machine divides two memory areas for the virtual machine shared device VMshm, one is used as a write buffer writebuffer, and the other is used as a read buffer read buffer. The core advantage of this design is to achieve asynchronous full-duplex communication, that is, the virtual machine can perform read and write operations simultaneously without having to wait for the other party to complete the operation, improving the data transmission efficiency between virtual machines.

[0058] Then, the VM_shmem structure is defined for managing the shared memory's read and write buffers, containing the device ID, the base address and size of the read and write buffers, and the physical base address. The virtual machine uses the VM_shmem_read_fops and VM_shmem_write_fops functions to handle read and write operations on shared memory, respectively. Read operations copy data from shared memory to the read buffer. Read operations are implemented through the interrupt mechanism. Each virtual machine's shared device, VMshm, has a corresponding interrupt number, irq_num, and registers a corresponding interrupt handler. When a virtual interrupt is injected into a virtual machine, the virtual machine finds the corresponding interrupt handler and calls VM_shmem_read_fops to read data from the read buffer. Write operations copy data from the write buffer to shared memory and initiate 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 device tree properties, mapping shared memory, creating character devices, and generating device nodes.

[0060] According to the above process, a complete memory sharing architecture between virtual machines is established. Figure 4 This is a diagram of the memory sharing architecture between virtual machines in the present invention. Figure 4 As shown, in the present invention, two virtual machines read and write data to the write 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 shared memory-based communication mechanism has several major advantages. First, PCI devices usually rely on the hardware bus for communication, which is complex to configure and operate and has high overhead. The virtual machine shared device VMshm directly transmits data between virtual machines through shared memory, reducing dependence on hardware resources and communication overhead. Second, the communication mode of PCI devices is usually asynchronous and interrupt-driven, while the virtual machine shared device VMshm achieves synchronous processing through kernel management and hypercall notification, which has a faster response speed. In addition, the design of the virtual machine shared device VMshm simplifies the communication model between virtual machines and 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 write buffer of the virtual machine shared device VMshm it is bound to. After initiating a hypercall, it writes the identifier shmid to register x1 and 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 the hypercall:

[0064] After receiving the hypercall from the initiating virtual machine, the Hypervisor jumps to the aborts_sync_handler function in the kernel for synchronous exception handling. It finds the corresponding handler function according to the exception type, then finds the notification pointer object during initialization, and calls the notification_signal function to unblock the service thread for virtual machine communication data management, and transfers the processing to the root service rootserver.

[0065] S105: Root service copies data:

[0066] After the service thread for virtual machine communication data management in the root service rootserver is unblocked, it extracts the identifier shmid, priority prio, and communication data passed by the hypercall, and creates a new queue node to save this information. The specific method is as follows: First, find the address of the write buffer write buffer associated with the shared memory according to the identifier shmid. Since the Hypervisor has full access rights to the shared memory area, the memory copy function can be directly used to copy the data from the write buffer write buffer to the corresponding fields of the newly created queue node. Then, insert the node into the corresponding position of the priority communication queue priority_queue_t according to the priority prio.

[0067] S106: Complete communication:

[0068] The service threads unblocked in the root server of the hypervisor sequentially take out the head node of the queue from the priority communication queue priority_queue_t. The advantage of this is that it can meet the need for real-time performance and give priority to notifying the virtual machines that are urgent for communication. When the identifiers shmid of two nodes are the same, it indicates that these two virtual machines are establishing communication. Then, the communication data saved in the node is copied to the read buffer of the receiving virtual machine, the physical core information where the receiving virtual machine is located is found, and inter-core communication is initiated to notify the interrupt controller to inject the corresponding virtual interrupt.

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

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

[0071] Although the above describes the illustrative specific embodiments of the present invention for the convenience of 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 defined and determined by the appended claims, these changes are obvious, and all inventions and creations using the concept of the present invention are within the scope of protection.

Claims

1. A virtual machine cross-operating system communication method based on a microkernel hypervisor, characterized in that The steps include the following: S1: The microkernel Hypervisor creates virtual machines and configures shared memory. The specific method is 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 the communication of each virtual machine, 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 allocates a block of memory for the shared memory of virtual machines VM_A and VM_B using the malloc function according to the shared memory size shm_size, and sets its identifier as the virtual machine communication channel identifier shmid; then maps this block of shared memory to virtual machines VM_A and VM_B through the secondary page table; S1.3: The Hypervisor initializes the event channel notification mechanism. The specific method is: The Hypervisor initializes the notification object through the notification_init function to manage the communication between virtual machines. Then the root service rootserver initiates a 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 for managing the communication data of virtual machines in the root service rootserver and wait for the arrival of the hypercall; S1.4: Initialize a priority communication queue priority_queue_t for managing the communication between all virtual machines in the root service rootserver. The priority communication queue priority_queue_t is implemented based on a doubly linked list, including the doubly linked list node structure list_head_t and the 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 virtual machine communication channel identifier shmid, the data buffer pointer buf, and a doubly linked list node node; S2: Virtual machines VM_A and VM_B respectively create and initialize the virtual machine shared device VMshm. The specific method is: The virtual machine divides two memory areas for the virtual machine shared device VMshm, one as a write buffer write buffer and the other as a read buffer 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 handle the read and write operations on 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; The virtual machine registers and initializes the virtual machine shared device VMshm in the Linux platform device, including reading device tree properties, mapping shared memory, creating character devices and generating device nodes; S3: When one of VM_A and VM_B needs to initiate communication with the other, it writes data to the write buffer of the bound VMshm device, initiates a hypercall, writes the VM communication channel 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 synchronization exception. It finds the corresponding processing function based on the exception type, then finds the notification pointer object during initialization and calls the notification_signal function to unblock the service thread used for virtual machine communication data management, transferring 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, it extracts the virtual machine communication channel identifier shmid, priority prio and communication data transmitted by the hypercall, and creates a new queue node to store this information. The specific method is as follows: first, the address of the write buffer associated with the shared memory is found according to the virtual machine communication channel identifier shmid, and the memory copy function is directly used to copy the data from the write buffer writebuffer 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 threads in the root server of the Hypervisor sequentially retrieve the head nodes from the priority communication queue priority_queue_t; when the virtual machine communication channel identifiers shmid of two nodes are the same, it indicates that these two virtual machines are establishing communication. Then, the communication data saved in the nodes is copied to the read buffer of the receiving virtual machine, the physical core information where the receiving virtual machine is located is found, inter-core communication is initiated, and the interrupt controller is notified to inject the corresponding virtual interrupt. After the receiving virtual machine receives the virtual interrupt, it determines that this is a device for virtual machine communication based on the interrupt number irq_num, and then calls the interrupt handler corresponding to the interrupt to read the data from the read buffer, completing 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