Communication method, computing device, storage medium and computer program product

Abstract

The embodiment of the invention provides a communication method applied to a hardware virtualization system. According to the system, two partitions for operating a first operating system and a second operating system respectively are isolated through a virtual machine monitoring program, and a first equipment file for a user program of the first operating system to access is created based on a shared memory. The method comprises the following steps: mapping the shared memory to an address space of a user program through the equipment file, so that the user program can directly read data written into the shared memory by the second operating system, or directly write the data and notify the second operating system to read the data. According to the scheme, intervention of a kernel of the first operating system is avoided, and data copying and context switching between a kernel mode and a user mode are eliminated, so that communication delay is remarkably reduced, throughput is improved, and efficient communication among different operating systems is realized.

Description

Technical Field

[0001] This specification relates to the field of computer application technology, specifically to a communication method between operating systems based on a multi-core processor, and more specifically to a communication method, computing device, storage medium, and computer program product. Background Technology

[0002] A multi-core processor is a processor architecture that integrates two or more processor cores (CPU Cores) on a single chip. Each processor core can execute instruction streams independently, and the cores can coordinate hardware resources and exchange data through on-chip buses and other means.

[0003] Taking embedded multi-core systems as an example, in some scenarios, embedded multi-core systems need to handle both real-time and non-real-time tasks. Common scenarios requiring real-time tasks include industrial control and sensor data acquisition, which often have high real-time requirements. Common non-real-time tasks include graphical interfaces, background data processing, log recording and analysis, etc., which have a higher tolerance for latency. A multi-system hybrid deployment solution on embedded multi-core systems can meet the requirements of both application scenarios. Specifically, a general-purpose operating system (GPOS) and a real-time operating system (RTOS) can be deployed simultaneously on the embedded multi-core system. The GPOS, with its focus on overall throughput, resource utilization, and human-computer interaction experience while balancing multi-task concurrency, and its lack of hard deterministic time constraints on task response, makes it particularly suitable for handling non-real-time tasks. Conversely, the RTOS, with its highly deterministic task scheduling and external event response, and its ability to complete execution within pre-defined time constraints, makes it particularly suitable for handling real-time tasks.

[0004] However, in actual use, it was found that the communication efficiency between multiple operating systems based on a multi-core system is low. Summary of the Invention

[0005] This specification provides a communication method, computing device, storage medium, and computer program product to improve communication efficiency between different operating systems.

[0006] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions: In one aspect, one embodiment of this specification provides a communication method applied to a hardware virtualization-based target system. The target system includes a first partition and a second partition isolated by a hypervisor. The first partition is used to run a first operating system, and the second partition is used to run a second operating system. The first and second operating systems communicate via shared memory. The hypervisor creates a target virtual device based on the shared memory. When the first operating system discovers the target virtual device, it can create a first device file. The first device file serves as an interface for user programs of the first operating system to interact with the shared memory. The communication method includes: Based on the first device file, the shared memory is mapped to the address space of the user program; Based on the shared memory mapped to the address space of the user program, the user program directly reads the received data written to the shared memory by the second operating system, and / or, the user program directly writes the transmitted data to the shared memory and notifies the second operating system to read the transmitted data from the shared memory.

[0007] Secondly, one embodiment of this specification provides a communication device applied to a hardware virtualization-based target system. The target system includes a first partition and a second partition isolated by a hypervisor. The first partition is used to run a first operating system, and the second partition is used to run a second operating system. The first and second operating systems communicate via shared memory. The hypervisor creates a target virtual device based on the shared memory. After discovering the target virtual device, the first operating system creates a first device file. The first device file is an interface for user programs of the first operating system to interact with the shared memory. The communication device includes: The first module is used to map the shared memory to the address space of the user program based on the first device file; The second module is used to, based on shared memory mapped to the address space of the user program, allow the user program to directly read received data written to the shared memory by the second operating system, and / or allow the user program to directly write transmitted data to the shared memory and notify the second operating system to read the transmitted data from the shared memory.

[0008] In one implementation, the user program directly reading the received data written to the shared memory by the second operating system includes: In response to the occurrence of a target event for the first device file, the user program of the first operating system directly reads and processes the received data from the shared memory, the target event being triggered by the second operating system, the target event indicating that the second operating system writes the first target data into the shared memory.

[0009] In one implementation, the process by which the second operating system triggers the target event includes: The second operating system writes to the doorbell register, which is virtualized by the virtual machine monitoring program; The virtual machine monitoring program monitors the second operating system writing to the doorbell register and sends a first interrupt to the first operating system; The kernel of the first operating system generates the target event in response to the first interrupt.

[0010] In one implementation, the user program directly writes the transmission data into the shared memory and notifies the second operating system to read the transmission data from the shared memory, including: The user program directly writes the data to be sent into the shared memory and writes the value of the doorbell register to trigger a second interrupt. The doorbell register is virtualized by the virtual machine monitoring program. The second interrupt is used to notify the second operating system to read the data to be sent from the shared memory.

[0011] In one implementation, the process of creating the first device file includes: The hypervisor registers the target virtual device with the kernel of the first operating system, and the target virtual device is identified based on an identity identifier; When the kernel of the first operating system detects the target virtual device, it loads and initializes the device driver module corresponding to the target communication device. The device driver module is used to register user-space input / output (UIO) devices with the kernel of the first operating system, so as to generate a first device file in the device file system for user programs to access.

[0012] In one implementation, the device driver module binds to the target virtual device through the identity identifier and calls the probe function to complete initialization; The device driver module is specifically used to: read the configuration information of the target virtual device to obtain the physical address and size parameters of the shared memory region, and request the physical address space resources of the shared memory region according to the parameters; Initialize the user space input / output UIO information structure, set memory region parameters and interrupt handling functions, and register the UIO device with the first operating system kernel to generate the first device file in the device file system; The interrupt handling function triggers a UIO event notification when an interrupt occurs in the target virtual device, enabling the user program to detect the target event based on the first device file.

[0013] In one implementation, the device driver module is further configured to disable the one-time interrupt mode of the target virtual device.

[0014] In one embodiment, the second operating system is used to process real-time tasks that communicate with the first operating system via the shared memory, and the real-time tasks are configured to have the highest priority. The kernel of the second operating system enables preemptive scheduling to ensure that the highest priority real-time tasks are executed first.

[0015] In one embodiment, the second operating system includes a circular buffer for accumulating data to be sent to the first operating system; When the amount of data accumulated in the circular buffer reaches a preset threshold, the second operating system writes the accumulated data in the circular buffer into the shared memory and triggers a third interrupt. The third interrupt is used to notify the first operating system to read the data written by the second operating system into the shared memory.

[0016] In one implementation, when the second operating system writes data to the circular buffer, it performs an atomic operation to update the write pointer and effective data length of the buffer, and when the effective data length reaches the preset threshold, it performs a write doorbell register operation to trigger the third interrupt.

[0017] In one implementation, it further includes: The third module optimizes the interrupt handling mechanism of the virtual machine monitor, and the optimization includes at least one of the following: Set the interrupt used for the shared memory communication as a high-priority interrupt; When initializing the interrupt controller, clear the active state of soft interrupts used for inter-core communication; During interrupt re-injection, if the interrupt to be injected is detected to be currently active, the interrupt is marked as active and pending.

[0018] Thirdly, one embodiment of this specification also provides a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the communication method described above.

[0019] Fourthly, one embodiment of this specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the communication method described above.

[0020] Fifthly, embodiments of this specification provide a computer program product or computer program, the computer program product including a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium, and when the processor executes the computer program, it implements the steps of the communication method described above. Optionally, the computer program may be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program from the readable storage medium or in the cloud.

[0021] As can be seen from the above technical solutions, the communication method provided in the embodiments of this specification is applied to a target system based on hardware virtualization. In the target system, the first partition and the second partition are isolated by the virtual machine monitor, providing different operating systems with isolated hardware operating resources. At the same time, the virtual machine monitor creates a target virtual device for communication based on shared memory. When the first operating system discovers the target virtual device, it can create a first device file, providing the user program of the first operating system with an interface for interaction with shared memory. In the implementation of the method, based on the first device file, shared memory is mapped to the address space of the user program of the first operating system, laying the foundation for the user program in user mode to directly access the shared memory. Based on the shared memory mapped to the address space of the user program, the user program in user mode can directly read the received data written to the shared memory by the second operating system, and / or, the user program can directly write the transmitted data to the shared memory and notify the second operating system to read the transmitted data from the shared memory, so as to achieve the purpose of communication between the first operating system and the second operating system. Moreover, the kernel of the first operating system does not need to participate in the communication process, avoiding the switching and data copying between different privilege levels of the kernel of the first operating system, reducing the number of data copying and kernel context switching overhead in the cross-system communication process, thereby significantly reducing communication latency, improving data throughput, and improving the communication efficiency between different operating systems in the target system. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the structure of a target system provided for one embodiment of this specification.

[0024] Figure 2 This is a flowchart illustrating a communication method provided for one embodiment of this specification.

[0025] Figure 3 This is a schematic diagram of the structure of a computing device provided for one embodiment of this specification. Detailed Implementation

[0026] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0027] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

[0028] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0029] Overview Before introducing the communication method provided in the embodiments of this specification, a brief explanation of the technical terms that may be involved in this specification will be given first: Jailhouse: A Linux-based static partitioning virtualization monitoring program (Hypervisor) that uses hardware virtualization technology to divide physical hardware resources into multiple isolated cells. Each cell can run an independent operating system or bare-metal applications, providing near-native performance.

[0030] Cell (partition): An isolated unit in a Jailhouse virtualization environment. The system typically consists of a root cell (running the host Linux system) and one or more non-root cells (running other operating systems such as FreeRTOS). Each cell has its own dedicated CPU cores, memory regions, and peripheral resources.

[0031] IVSHMEM (Inter-VM Shared Memory): A virtualization technology that creates a shared memory region between virtual machines, enabling different virtual machines to directly read and write to the same physical memory, thus achieving efficient data exchange.

[0032] GIC (Generic Interrupt Controller): A standardized interrupt controller in the ARM architecture, responsible for receiving interrupt requests from peripherals and routing them to the appropriate processor core for processing based on priority and dispatch strategy.

[0033] GPOS (General-Purpose Operating System): This refers to an operating system designed for handling a variety of general-purpose computing tasks, emphasizing throughput, resource utilization, and user experience rather than strict time determinism. Linux and Windows are typical examples of general-purpose operating systems.

[0034] UIO (Userspace I / O): A framework in the Linux kernel that allows the main part of a device driver to run in user space. Through UIO, user programs can directly access the memory-mapped regions of hardware devices and handle interrupts, reducing the overhead of context switching between kernel and user modes.

[0035] RTOS (Real-Time Operating System): An operating system specifically designed for real-time applications, ensuring that tasks respond within predictable and deterministic time constraints. FreeRTOS is one such popular open-source real-time operating system.

[0036] PCI (Peripheral Component Interconnect Device) devices are hardware devices that conform to the PCI standard and connect to the computer system via the PCI bus. In a virtualization environment, virtual PCI devices can be simulated by software for use by virtual machines.

[0037] mmap (Memory Map): A technique for mapping the memory of a file or device into the address space of a process. Through the mmap system call, a process can access the memory region of a file or device as if it were ordinary memory, avoiding explicit copying of data between user space and kernel space.

[0038] Hypervisor / VMM (Virtual Machine Monitor): A software layer that runs between the hardware and the operating system, responsible for creating, running, and managing virtual machines. It abstracts and virtualizes hardware resources, allowing multiple operating systems to share the same physical hardware.

[0039] Root Cell (Root Partition): In a Jailhouse, the first partition to boot from, typically running the host system (such as Linux). The root cell has permissions to manage other non-root cells and is responsible for system initialization and management tasks.

[0040] Non-Root Cell: An isolated partition created and managed by the root cell in the Jailhouse, running an independent operating system (such as FreeRTOS). The hardware resources of the non-root cell are statically allocated by the root cell.

[0041] Doorbell Register: A special register in the IVSHMEM device used to trigger interrupts. When one party writes to this register, an interrupt is generated on the other party, notifying them that data is ready or an event has occurred.

[0042] A ring buffer is a fixed-size buffer whose read / write pointers wrap around to the beginning when they reach the end of the buffer, forming a logical ring structure. It is commonly used in producer-consumer scenarios to achieve efficient data buffering and transfer.

[0043] SGI (Software Generated Interrupt): An internal interrupt generated by the processor core by writing to the interrupt controller register, typically used for inter-core communication (IPI). In the ARM GIC architecture, the SGI interrupt number can be 0-15.

[0044] SPI (Shared Peripheral Interrupt): A type of interrupt managed by the GIC interrupt controller, generated by an external device and can be routed to any processor core in the system. Interrupt numbers can start from 32.

[0045] After a preliminary introduction to the relevant concepts that may be involved, the following describes the process of discovering the technical problem that the implementation methods of this specification aim to solve: To meet the needs of real-time and non-real-time tasks in different application scenarios, related technologies have proposed solutions for hybrid deployment of multiple operating systems in multi-core systems using hardware virtualization technology. For example, the Jailhouse solution is proposed, a virtualization scheme based on a lightweight hypervisor that dynamically allocates resources such as processors, memory, and peripherals to run multiple systems. The core advantage of the Jailhouse solution lies in its strong hardware isolation, allowing for precise allocation of hardware resources and high isolation between partitions to prevent mutual interference. In terms of performance, it better utilizes the characteristics of hardware virtualization and has great potential for optimizing the performance of real-time tasks.

[0046] In multi-core systems with multiple operating systems deployed in a hybrid architecture, providing a mechanism for communication between these operating systems is an essential infrastructure requirement for every multi-core deployment. Taking Jailhouse as an example, it provides the IVSHMEM communication mechanism. However, research has shown that when FreeRTOS needs to send data to Linux via IVSHMEM, it writes the data to shared memory and sends an interrupt to Linux. Linux responds to this interrupt, reads the data written by FreeRTOS from shared memory, and completes the communication. During this process, the Linux kernel needs to participate in data transfer; that is, the kernel needs to copy data from kernel space to user space. Each communication process involves switching between kernel mode and user mode, resulting in low communication efficiency.

[0047] To address this issue, this specification provides a communication method applied to a hardware virtualization-based target system. In this system, a first partition and a second partition are isolated by a hypervisor, providing isolated hardware operating resources for different operating systems. Simultaneously, the hypervisor creates a target virtual device for communication based on shared memory. When the first operating system discovers the target virtual device, it can create a first device file, providing an interface for user programs of the first operating system to interact with shared memory. In the implementation of the method, based on the first device file, shared memory is mapped to the address space of the user program of the first operating system, laying the foundation for the user program in user mode to directly access the shared memory. Based on the shared memory mapped to the address space of the user program, the user program in user mode can directly read the received data written to the shared memory by the second operating system, and / or, the user program can directly write the transmitted data to the shared memory and notify the second operating system to read the transmitted data from the shared memory, so as to achieve the purpose of communication between the first operating system and the second operating system. Moreover, the kernel of the first operating system does not need to participate in the communication process, avoiding the switching and data copying between different privilege levels of the kernel of the first operating system, reducing the number of data copying and kernel context switching overhead in the cross-system communication process, thereby significantly reducing communication latency, improving data throughput, and improving the communication efficiency between different operating systems in the target system.

[0048] Based on the above concept, this specification provides a communication method. The communication method provided by this specification will be described exemplarily below with reference to the accompanying drawings.

[0049] Exemplary methods This specification provides a communication method applicable to, for example, […]. Figure 1 The target system 10 shown is based on hardware virtualization. The target system 10 includes a first partition 11 and a second partition 12 isolated by a hypervisor. The first partition 11 runs a first operating system, and the second partition 12 runs a second operating system. The first and second operating systems communicate via shared memory 13. The hypervisor creates target virtual devices for communication based on the shared memory 13. When the first operating system discovers the target virtual device, it can create a first device file. The first device file is the interaction interface between the user programs of the first operating system and the shared memory 13. The target system 10 may include multiple processor cores. Figure 1 In this context, these processor cores are represented as Core0~N, and the first partition 11 and the second partition 12 can be implemented based on different processor cores, such as... Figure 2As shown, the communication method includes: S201: Based on the first device file, map the shared memory 13 to the address space of the user program; S202: Based on the shared memory 13 mapped to the address space of the user program, the user program directly reads the received data written to the shared memory 13 by the second operating system, and / or, the user program directly writes the transmitted data to the shared memory 13 and notifies the second operating system to read the transmitted data from the shared memory 13.

[0050] In one embodiment, the hypervisor can be Jailhouse, the first partition 11 can be the root partition managed by Jailhouse, and the first operating system can be Linux; the second partition 12 can be a non-root partition managed by Jailhouse, and there can be one or more second partitions 12, with the second operating system being FreeRTOS. The first and second operating systems can communicate through shared memory 13 managed and configured by Jailhouse. For example, in one embodiment, during system initialization, Jailhouse can allocate a contiguous physical address space from physical memory as a shared memory 13 region according to a predefined configuration file, and map it to the address spaces of the first partition 11 and the second partition 12 respectively. Simultaneously, Jailhouse can create a virtual IVSHMEM PCI device, whose memory region (Bar register) corresponds to the shared memory 13 region. This virtual device can be allocated to both the first partition 11 and the second partition 12, allowing the operating systems of these partitions to recognize and access this virtual device, thereby achieving recognition and access to shared memory 13.

[0051] In the first operating system, still taking Linux as an example, the first device file can be generated through the UIO framework. This generation process includes: the Linux kernel loading the driver for the aforementioned virtual IVSHMEM PCI device. After probing the device, the driver does not directly provide a traditional data read / write interface, but instead registers a UIO device with the kernel. Upon successful registration, the system generates a character device file in the / dev directory, such as / dev / uio0, which is the first device file. This file becomes a secure and standardized interface between user-space programs and the underlying shared memory hardware resources.

[0052] In step S201, still using the Linux operating system as an example, a user program on Linux can open the first device file using a standard system call (e.g., `open`). Subsequently, using the `mmap` system call, the shared memory physical region 13 represented by the first device file can be directly mapped to the user program's user-mode virtual address space. In some implementations, after the mapping operation in step S201 is completed, the user program can hold a usable user-mode pointer for direct access to the shared memory 13. In this way, physical memory that was originally only accessible by the kernel driver can be exposed to the user program through memory mapping, bypassing the traditional path of accessing shared memory 13 that must go through the kernel, laying the foundation for subsequent zero-copy communication and eliminating the potential overhead of data copying between kernel mode and user mode. It is understood that step S201 can be a one-time operation during the initialization phase; that is, after step S201 is executed, the first and second operating systems can communicate multiple times based on the mapping relationship established in step S201.

[0053] Step S202 describes the bidirectional communication process between the first operating system and the second operating system. In one embodiment, for the first operating system, the data receiving process may include: when the second operating system has data to send, it can write the data to the shared memory region 13, and then trigger an interrupt by writing to the doorbell register. The UIO framework in the first operating system will capture this interrupt and notify the user program through an event mechanism. The user program does not need to request data from the kernel, but directly accesses the data in the shared memory region 13 through the mapping relationship established in step S201, thus realizing the transfer of data from the second operating system to the first operating system.

[0054] In one implementation, for the first operating system, the data transmission process may include: when a user program needs to send data to the second operating system, it can directly write the data to be sent into shared memory 13, and then trigger an interrupt by triggering the doorbell register to notify the second operating system that there is data to be read. The second operating system can respond to the interrupt and directly read the data from shared memory 13.

[0055] Thus, after establishing the mapping relationship between shared memory 13 and the address space of the user program in step S201, the communication between the first operating system and the second operating system can be transformed into direct read and write operations on shared memory 13, without the need for additional data transfer and kernel buffering, and without the need to re-establish the access path for each transmission, which greatly improves communication efficiency and reduces communication overhead.

[0056] It is understood that although the above description uses Jailhouse, Linux, and FreeRTOS as examples, the communication method can be applied to other virtualization environments that conform to this architecture. For example, the hypervisor can be any virtual machine monitor that provides static partitioning capabilities, in addition to Jailhouse. The first operating system can also be any other general-purpose operating system that supports a similar user-mode direct memory mapped I / O mechanism; the second operating system can also be any other real-time operating system or bare-metal application. As long as it meets the requirements of isolating partitions through the hypervisor, establishing shared memory 13 between partitions, and providing a persistently mapped interface for user programs of the first operating system to access the shared memory 13, this specification does not limit the specific types of the hypervisor, the first partition 11, the second partition 12, the first operating system, and the second operating system.

[0057] In one embodiment, a feasible process for a user program to receive data is provided. Specifically, the user program directly reads the received data written to the shared memory 13 by the second operating system, including: In response to the occurrence of a target event for the first device file, the user program of the first operating system directly reads and processes the received data from the shared memory 13. The target event is triggered by the second operating system, and the target event indicates that the second operating system writes the first target data into the shared memory 13.

[0058] Optionally, in one embodiment, the process by which the second operating system triggers the target event includes: The second operating system writes to the doorbell register, which is virtualized by the virtual machine monitoring program; The virtual machine monitoring program monitors the second operating system writing to the doorbell register and sends a first interrupt to the first operating system; The kernel of the first operating system generates the target event in response to the first interrupt.

[0059] Continuing with the example of Linux as the first operating system and FreeRTOS as the second, when the second operating system needs to send data to the first operating system, it can directly write the first target data into shared memory 13. After the data writing is complete, the second operating system can trigger an interrupt by writing to the doorbell register. This doorbell register can be provided by Jailhouse through virtualization, and the operation of writing to the doorbell register will be captured by Jailhouse at the Hypervisor layer (EL2 privilege level).

[0060] After Jailhouse captures the write operation to the doorbell register, it injects the corresponding interrupt into the Linux kernel running in the first partition 11 according to the configuration. In the Linux kernel, the UIO framework's interrupt handler function ivshm_irq_handler is called. This function does not perform data copying; its core responsibility is to perform minimal interrupt status handling and call the uio_event_notify function to trigger a UIO event associated with the / dev / uio0 device file (i.e., the first device file). This event is the target event, which notifies the user process listening to this device file through the kernel's event mechanism that new data has arrived in shared memory 13.

[0061] User programs can use the poll() system call to listen to the file descriptor of the first device file and wait for the POLLIN event (input ready event, i.e., the target event). When the kernel UIO driver triggers the uio_event_notify function, this poll() call returns, indicating that the target event has occurred.

[0062] User programs respond to the occurrence of this target event without requesting data from the kernel. User programs can directly access the received data in shared memory 13 to receive data.

[0063] In summary, in this implementation, all reading and writing operations of communication data are completed in user space. Users do not need to make system calls when reading data. The first operating system kernel is only used to trigger target events during communication, without actually participating in data transfer. This greatly reduces the processor context switching overhead caused by communication.

[0064] In one implementation, the user program directly writes the transmission data into the shared memory 13 and notifies the second operating system to read the transmission data from the shared memory 13, including: The user program directly writes the transmission data into the shared memory 13 and writes the value of the doorbell register to trigger a second interrupt. The doorbell register is virtualized by the virtual machine monitoring program. The second interrupt is used to notify the second operating system to read the transmission data from the shared memory 13.

[0065] The doorbell register can be a shared virtualized storage area used to trigger interrupts, abstracted by a hypervisor (such as Jailhouse) through hardware virtualization technology for communication between partitions (such as root cells and non-root cells). This doorbell register can be a specific physical memory area reserved and managed by the hypervisor, or it can be a register completely simulated by virtualization logic. When either operating system (the sender) performs a write operation to this doorbell register, the hypervisor captures this access at the hardware level (such as EL2) and, based on the written value, generates a virtual interrupt and injects it into the target operating system, thus completing a "knocking" notification. Both the first and second operating systems can trigger an interrupt to notify each other by writing to the same doorbell register.

[0066] In this embodiment, a feasible process for a first operating system to send data to a second operating system is provided. This process, together with the data receiving process of the first operating system described above, constitutes a symmetrical communication architecture that realizes data transfer entirely in user space. This architecture achieves zero copy and minimal kernel intervention at both ends of the communication, thereby greatly improving communication efficiency and reducing communication overhead.

[0067] In one implementation, the process of creating the first device file may include: The hypervisor registers the target virtual device with the kernel of the first operating system, and the target virtual device is identified based on an identity identifier; When the kernel of the first operating system detects the target virtual device, it loads and initializes the device driver module corresponding to the target communication device. The device driver module is used to register user-space input / output (UIO) devices with the kernel of the first operating system, so as to generate a first device file in the device file system for user programs to access.

[0068] Specifically, taking Jailhouse as the virtual machine monitoring program and Linux as the primary operating system as an example, the creation process can be described as follows: The hypervisor (such as Jailhouse) registers the target virtual device with the kernel of the first operating system (such as Linux). The target virtual device is identified based on an identity identifier. Specifically, the target virtual device is an IVSHMEM virtual PCI device, which is uniquely identified by the vendor ID (such as 0x110a) and device ID (such as 0x4106) in the PCI configuration space.

[0069] When the kernel of the first operating system detects the target virtual device, it loads and initializes the device driver module corresponding to the target virtual device. Specifically, the device driver module registers itself with the Linux kernel's PCI subsystem through the `module_pci_driver` macro and defines an `ivshm_device_id_table` containing the aforementioned identity identifier as a device matching rule. When the kernel's PCI bus enumeration detects a virtual PCI device matching this table, it automatically loads the driver module and calls its `ivshm_probe` probe function to complete the binding between the driver and the hardware and module initialization.

[0070] The core function of the device driver module is to register a user-space input / output (UIO) device with the kernel of the first operating system. In the `ivshm_probe` function, the driver ultimately calls `uio_register_device` to register a UIO device with the kernel. After successful registration, the kernel UIO framework generates a corresponding node under ` / sys / class / uio / ` and dynamically creates a character device file (e.g., ` / dev / uio0`) in the ` / dev` directory. This file is the "first device file" accessible to user programs.

[0071] In this implementation, the virtual communication hardware abstracted by the hypervisor is seamlessly integrated into the operating system kernel through a standardized target virtual device discovery and driver model, and converted into a user-friendly UIO device file (i.e., the first device file) interface. This achieves secure abstraction of user-mode access and lays a solid foundation for efficient communication without kernel data copying.

[0072] In one implementation, the device driver module binds to the target virtual device through the identity identifier and calls the probe function to complete initialization; The device driver module is specifically used to: read the configuration information of the target virtual device to obtain the physical address and size parameters of the shared memory 13 region, and request the physical address space resources of the shared memory 13 region according to the parameters; Initialize the user space input / output UIO information structure, set memory region parameters and interrupt handling functions, and register the UIO device with the first operating system kernel to generate the first device file in the device file system; The interrupt handling function triggers a UIO event notification when an interrupt occurs in the target virtual device, enabling the user program to detect the target event based on the first device file.

[0073] Optionally, the device driver module may specifically perform the following steps: Activation and Mapping: In ivshm_probe, pcim_enable_device is first called to activate the virtual PCI device, enabling its I / O and memory space access permissions. Subsequently, pcim_iomap_regions maps its BAR0 register region (containing device control and status registers) to the kernel virtual address space, laying the foundation for accessing hardware registers.

[0074] Reading Configuration and Resource Requests: The driver reads key parameters of the PCI configuration space using pci_read_config_dword and similar functions to obtain information such as the physical address and size of the shared memory region 13, which is preset by the hypervisor. Then, it calls functions such as devm_request_mem_region to request and reserve the physical address space resources of shared memory region 13 based on these parameters.

[0075] The driver initializes a `uio_info` structure. Based on the parameters read from the configuration space, it sets its memory region (mem) array, mapping different parts of shared memory 13 (such as the status table and data read / write area) to the various mem regions of the UIO. Simultaneously, it sets interrupt handlers (such as `ivshm_irq_handler`). Finally, it calls `uio_register_device` to complete the registration of the UIO device in the kernel, thereby generating the first device file (` / dev / uio0`) in the device file system.

[0076] When an interrupt occurs on the target virtual device, the core operation of the interrupt handler (ivshm_irq_handler) is to call the uio_event_notify function. This call triggers an event associated with the UIO device file, enabling the user program listening to that file descriptor via the poll, select, or read system calls to be woken up and detect the target event (i.e., data arrival notification).

[0077] In this implementation, the driver module completes the discovery, mapping, and abstraction of virtual hardware resources, but the actual data read and write operations are completely handed over to the user program to be completed directly through the mapped memory. This greatly simplifies the complexity of the kernel driver, allowing it to be responsible only for the most necessary resource management and event signal conversion, thereby minimizing kernel-mode overhead.

[0078] In one implementation, the device driver module is further configured to disable the one-time interrupt mode of the target virtual device.

[0079] One-shot interrupt mode means that the global interrupt enable bit is automatically cleared after each interrupt is triggered. When one-shot interrupt mode is enabled, the interrupt enable bit needs to be re-enabled after each interrupt is triggered. This extra operation not only introduces latency itself, but also requires the processor to switch exception levels (e.g., from EL1 to EL2), resulting in significant system overhead and latency.

[0080] Therefore, in this embodiment, by disabling the one-time interrupt mode of the target virtual device, the operation of repeatedly enabling the interrupt enable bit is avoided, thus avoiding frequent exception level switching caused by this operation.

[0081] In one specific implementation, the interrupt mode can be controlled by a specific configuration register of the target virtual device. Specifically, the control bit can be a designated bit (such as bit 0) in the Privileged Control Register within the Vendor-Specific Capability structure in the device's configuration space. When this bit is set to 1, the interrupt mode is enabled.

[0082] The IVSHMEM communication submodule of the hypervisor (such as Jailhouse) determines, within its interrupt triggering interface, whether the device driver module running in the kernel mode (EL1) of the first operating system (Linux) is configured with an interrupt mode. If this mode is detected as enabled, the global interrupt enable bit of the target virtual device will be automatically disabled after the interrupt is triggered in the execution path of this interface. This means that if this mode is not disabled, the interrupt enable bit must be re-enabled by software after each interrupt trigger, thereby introducing unnecessary software operation overhead and potential exception level switching delays.

[0083] In one embodiment, the second operating system is used to process real-time tasks that communicate with the first operating system via the shared memory 13, and the real-time tasks are configured to have the highest priority. The kernel of the second operating system enables preemptive scheduling to ensure that the highest priority real-time tasks are executed first.

[0084] In this embodiment, the priority of the real-time task used for communication is configured as the highest priority, and preemptive scheduling is enabled. This is beneficial for the highest priority real-time task to be executed by the second operating system first, ensuring that the communication task can be responded to in a timely manner, thereby improving the real-time performance of communication.

[0085] In one optional implementation, the second operating system includes a circular buffer for accumulating data to be sent to the first operating system; When the amount of data accumulated in the circular buffer reaches a preset threshold, the second operating system writes the accumulated data in the circular buffer into the shared memory 13 and triggers a third interrupt. The third interrupt is used to notify the first operating system to read the data written by the second operating system in the shared memory 13.

[0086] In some scenarios, the second operating system may need to frequently transmit small data packets to the first operating system (e.g., sensor data transmission scenarios). If an interrupt is triggered for each small data packet transmission, the interrupt triggering frequency will be high, requiring the first operating system to handle interrupts frequently, which may affect communication efficiency. To solve this problem, this embodiment designs a circular buffer. This circular buffer can be used to accumulate data to be sent to the first operating system. Only when the amount of data accumulated in the circular buffer reaches a preset threshold will the second operating system trigger a third interrupt, thereby greatly reducing the triggering frequency of the third interrupt. This helps to reduce the number of third interrupts that the first operating system needs to handle, thus reducing the burden on the first operating system and improving communication efficiency.

[0087] In one implementation, when the second operating system writes data to the circular buffer, it performs an atomic operation to update the write pointer and effective data length of the buffer, and when the effective data length reaches the preset threshold, it performs a write doorbell register operation to trigger the third interrupt.

[0088] In this implementation, atomic operations ensure the correctness and consistency of the internal state updates when multiple tasks concurrently write to the circular buffer.

[0089] The following example uses FreeRTOS running in a Non-Root Cell as the second operating system to illustrate the relevant improvements on the second operating system side: The configuration and initialization on the second operating system (FreeRTOS) side include: (1) Initialize the virtual device (IVSHMEM) for communication. In the second operating system, a task dedicated to handling communication needs to be created and configured with the highest priority. At the same time, the preemptive scheduling mechanism of the second operating system kernel is enabled to ensure that the communication task can receive an immediate response.

[0090] (2) Obtain the base address of the virtual PCI configuration space based on the communication zone information set by the virtual machine monitor (Jailhouse).

[0091] (3) Map the virtual PCI configuration space to the address space of the second operating system, and locate the virtual PCI device configured by the virtual machine monitor for IVSHMEM communication based on the device identification information.

[0092] (4) Parse and obtain the address and size information of the shared memory 13 region from the configuration space of the virtual PCI device, and complete the memory mapping and other access preparations.

[0093] (5) Set up an interrupt handling function to receive data arrival notifications from the first operating system.

[0094] Regarding optimizations for the circular buffer: The second operating system designs and maintains a circular buffer for temporarily accumulating data to be sent to the first operating system. Operations related to the circular buffer may include: (1) Initialization: By calling the memory allocation interface provided by the second operating system, a contiguous memory space of a specified size is requested as a circular buffer. During initialization, the internal read / write pointer is set to zero, the effective data length is set to zero, and a default data accumulation threshold (e.g., 512 bytes) is set.

[0095] (2) Destruction: The destruction function is responsible for releasing the buffer memory and resetting all state parameters. FreeRTOS's dynamic memory release interface vPortFree ensures the safety of resource reclamation in a multi-tasking environment and avoids memory leaks. After destruction, the buffer pointer is set to null to prevent dangling pointer issues and ensure system stability.

[0096] (3) Write Operation: When writing data to the circular buffer, interrupts and task switching are masked by entering a critical section to ensure data consistency. The operation includes checking the remaining space, performing data copying (which requires handling buffer wrap-around), and atomically updating the write pointer and the effective data length. When the effective data length reaches the preset threshold, the operation of writing to the doorbell register is triggered to achieve batch data notification.

[0097] (4) Read operations: Reading data from the circular buffer (e.g., before bulk moving it to shared memory 13) is also performed under critical section protection. A data copy is performed (handling read pointer wraparound) based on the requested length and the current valid data length, and the read pointer and valid data length are updated atomically. This design ensures the atomicity of data access in a multi-tasking environment and avoids data races.

[0098] In one embodiment, the communication method further includes: The hypervisor optimizes the interrupt handling mechanism, and the optimization includes at least one of the following: Set the interrupt used for communication in the shared memory 13 to a high-priority interrupt; When initializing the interrupt controller, clear the active state of soft interrupts used for inter-core communication; During interrupt re-injection, if the interrupt to be injected is detected to be currently active, the interrupt is marked as active and pending.

[0099] In one of the preceding embodiments, an optimization of the interrupt mechanism by disabling the one-time interrupt mode was described. In addition, at least one of the above-mentioned interrupt handling mechanisms can also be optimized.

[0100] Specifically, the interrupt used for shared memory communication can be set as a high-priority interrupt to improve real-time response capabilities. The implementation process can include adding an interface function to the Jailhouse's GIC (General Interrupt Controller) module to set the priority of shared peripheral interrupts. In this function, by manipulating the interrupt priority register in the GIC Distributor, a higher priority (i.e., a smaller value) is configured for the specific interrupt number assigned to IVSHMEM communication. This operation is typically completed when the Jailhouse initializes the IVSHMEM submodule, obtaining the corresponding interrupt number based on the configuration information and calling the priority setting function.

[0101] Alternatively, the active state of software interrupts used for inter-core communication can be cleared during interrupt controller initialization. This can fix a design flaw that could cause system hangs when creating non-root partitions under certain kernel versions. The specific implementation can include adding a processing logic to the Jailhouse's GIC module initialization function. Specifically, when initializing the interrupt controller interface for each CPU core, the active state register of that core's private interrupts (such as SGI) is read and cleared. For example, by reading the value of the GICR_ISACTIVER register and writing it to the GICR_ICACTIVER register, the active flag of all software-generated interrupts is cleared. This ensures that when Jailhouse takes over and initializes the interrupt controller, all software interrupt active states left over from the previous runtime environment are correctly cleared. This prevents the problem of subsequent inter-core communication interrupts failing to be triggered correctly due to residual "active" states, ensuring the stability and success rate of non-root partition creation and improving system robustness.

[0102] Alternatively, during interrupt re-injection, if the interrupt to be injected is already active, it can be marked as both active and pending (i.e., Active & Pending). This solves the problem of interrupts being lost when they arrive again after being processed in the virtual machine but not yet completed (in an active state). Specific implementation steps can include optimizing the Jailhouse interrupt re-injection function (e.g., gicv3_inject_irq). In this function, when attempting to inject an interrupt into the virtual machine, the virtual machine's interrupt status list is first checked. If an entry with the same ID as the interrupt is already "active," the new interrupt is not ignored; instead, the entry's status is modified to simultaneously mark it as "active" and "pending." This can be achieved by setting the corresponding status bits in the list register.

[0103] Exemplary device In one exemplary embodiment of this specification, a communication device is also provided, applied to a target system based on hardware virtualization. The target system includes a first partition and a second partition isolated by a hypervisor. The first partition is used to run a first operating system, and the second partition is used to run a second operating system. The first operating system and the second operating system communicate through shared memory. The hypervisor creates a target virtual device based on the shared memory. After discovering the target virtual device, the first operating system creates a first device file. The first device file is an interface for user programs of the first operating system to interact with the shared memory. The communication device includes: The first module is used to map the shared memory to the address space of the user program based on the first device file; The second module is used to, based on shared memory mapped to the address space of the user program, allow the user program to directly read received data written to the shared memory by the second operating system, and / or allow the user program to directly write transmitted data to the shared memory and notify the second operating system to read the transmitted data from the shared memory.

[0104] For specific limitations regarding the communication device, please refer to the limitations regarding the communication method above, which will not be repeated here. Each module in the aforementioned communication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware within or independently of the processor in the computer device, or stored in software within the memory of the computer device, so that the processor can invoke and execute the operations corresponding to each module.

[0105] Exemplary computing device Another embodiment of this application also proposes a computing device, see [link to relevant documentation] Figure 3 As shown, an exemplary embodiment of this specification also provides a computing device, including: a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform steps in the communication methods according to various embodiments of this specification described above. Optionally, the processor may be a multi-core processor.

[0106] The internal structure of the computing device can be as follows: Figure 3 As shown, the computing device includes a processor, memory, network interface, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it follows the steps of the communication methods according to various embodiments of this specification as described in the above embodiments.

[0107] The processor may include the main processor, as well as baseband chips, modems, etc.

[0108] It is understood that the processor in the embodiments of this specification can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this specification can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0109] It is understood that the memory in the embodiments of this specification may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0110] Input devices may include devices that receive data and information input by the user, such as keyboards, mice, cameras, scanners, light pens, voice input devices, touch screens, pedometers, or gravity sensors.

[0111] Output devices may include devices that allow information to be output to the user, such as displays, printers, speakers, etc.

[0112] The communication interface may include any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0113] The computing device may also include a display component and a voice component. The display component may be a liquid crystal display screen or an e-ink display screen. The input device of the computing device may be a touch layer covering the display component, or a button, trackball or touchpad set on the casing of the computing device, or an external keyboard, touchpad or mouse, etc.

[0114] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the solutions in this specification and do not constitute a limitation on the computing devices on which the solutions in this specification are applied. Specific computing devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0115] Exemplary computer program products and storage media In addition to the methods and devices described above, the communication methods provided in the embodiments of this specification can also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the communication methods according to various embodiments of this specification as described in the "Exemplary Methods" section above.

[0116] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0117] The computer program product described herein can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments described herein. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0118] Furthermore, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor of the steps in the communication methods according to various embodiments of this specification as described in the "Exemplary Methods" section above.

[0119] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this specification can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0120] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0121] The embodiments described above are merely illustrative of several implementation methods outlined in this specification. While the descriptions are specific and detailed, they should not be construed as limiting the scope of the solutions provided in this specification. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this specification, and these all fall within the scope of protection of this specification. Therefore, the scope of protection for this patent should be determined by the appended claims.

Claims

1. A communication method, characterized in that, This invention relates to a hardware virtualization-based target system, comprising a first partition and a second partition isolated by a hypervisor. The first partition runs a first operating system, and the second partition runs a second operating system. The first and second operating systems communicate via shared memory. The hypervisor creates a target virtual device based on the shared memory. After discovering the target virtual device, the first operating system creates a first device file, which serves as the interface for user programs of the first operating system to interact with the shared memory. The communication method includes: Based on the first device file, the shared memory is mapped to the address space of the user program; Based on the shared memory mapped to the address space of the user program, the user program directly reads the received data written to the shared memory by the second operating system, and / or, the user program directly writes the transmitted data to the shared memory and notifies the second operating system to read the transmitted data from the shared memory.

2. The method according to claim 1, characterized in that, The user program directly reads the received data written to the shared memory by the second operating system, including: In response to the occurrence of a target event for the first device file, the user program of the first operating system directly reads and processes the received data from the shared memory, the target event being triggered by the second operating system, the target event indicating that the second operating system writes the first target data into the shared memory.

3. The method according to claim 2, characterized in that, The process by which the second operating system triggers the target event includes: The second operating system writes to the doorbell register, which is virtualized by the virtual machine monitoring program; The virtual machine monitoring program monitors the second operating system writing to the doorbell register and sends a first interrupt to the first operating system; The kernel of the first operating system generates the target event in response to the first interrupt.

4. The method according to claim 1, characterized in that, The user program directly writes the data to be transmitted into the shared memory and notifies the second operating system to read the data from the shared memory, including: The user program directly writes the data to be sent into the shared memory and writes the value of the doorbell register to trigger a second interrupt. The doorbell register is virtualized by the virtual machine monitoring program. The second interrupt is used to notify the second operating system to read the data to be sent from the shared memory.

5. The method according to claim 1, characterized in that, The creation process of the first device file includes: The hypervisor registers the target virtual device with the kernel of the first operating system, and the target virtual device is identified based on an identity identifier; When the kernel of the first operating system detects the target virtual device, it loads and initializes the device driver module corresponding to the target communication device. The device driver module is used to register user-space input / output (UIO) devices with the kernel of the first operating system, so as to generate a first device file in the device file system for user programs to access.

6. The method according to claim 5, characterized in that, The device driver module binds to the target virtual device through the identity identifier and calls the detection function to complete the initialization; The device driver module is specifically used to: read the configuration information of the target virtual device to obtain the physical address and size parameters of the shared memory region, and request the physical address space resources of the shared memory region according to the parameters; Initialize the user space input / output UIO information structure, set memory region parameters and interrupt handling functions, and register the UIO device with the first operating system kernel to generate the first device file in the device file system; The interrupt handling function triggers a UIO event notification when an interrupt occurs in the target virtual device, enabling the user program to detect the target event based on the first device file.

7. The method according to claim 5, characterized in that, The device driver module is also used to disable the one-time interrupt mode of the target virtual device.

8. The method according to any one of claims 1 to 7, characterized in that, The second operating system is used to process real-time tasks that communicate with the first operating system via the shared memory, and the real-time tasks are configured to have the highest priority. The kernel of the second operating system enables preemptive scheduling to ensure that the highest priority real-time tasks are executed first.

9. The method according to claim 8, characterized in that, The second operating system includes a circular buffer, which is used to accumulate data to be sent to the first operating system; When the amount of data accumulated in the circular buffer reaches a preset threshold, the second operating system writes the accumulated data in the circular buffer into the shared memory and triggers a third interrupt. The third interrupt is used to notify the first operating system to read the data written by the second operating system into the shared memory.

10. The method according to claim 9, characterized in that, When the second operating system writes data to the circular buffer, it performs atomic operations to update the write pointer and effective data length of the buffer, and when the effective data length reaches the preset threshold, it performs a write operation to the doorbell register to trigger the third interrupt.

11. The method according to any one of claims 1 to 7, characterized in that, Also includes: The hypervisor optimizes the interrupt handling mechanism, and the optimization includes at least one of the following: Set the interrupt used for the shared memory communication as a high-priority interrupt; When initializing the interrupt controller, clear the active state of soft interrupts used for inter-core communication; During interrupt re-injection, if the interrupt to be injected is detected to be currently active, the interrupt is marked as active and pending.

12. A computing device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the communication method according to any one of claims 1 to 11.

13. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the communication method according to any one of claims 1 to 11.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the communication method as described in any one of claims 1 to 11.

Images