A method for shared memory communication between Linux and non-Linux systems

Abstract

The application provides a shared memory communication method between Linux and non-Linux systems, comprising the following steps: reserving a continuous memory area crossing Linux and non-Linux in physical memory, and establishing a mapping of the area to respective virtual address spaces; constructing a virtual interrupt controller on a hardware interrupt controller; defining a layered communication protocol, which comprises a physical layer, a transport layer, a synchronization layer and an application layer; maintaining cache consistency of the shared memory area by a directory protocol maintained by software; deploying virtualized communication agents on the Linux side and the non-Linux side to constitute a virtualized communication execution environment for dynamically optimizing a cross-system communication path; and providing a unified programming interface to an application program; the application aims to realize low-latency, low-overhead, high real-time, dynamically-optimizable cross-system communication and self-adaptive optimal configuration of performance.

Description

Technical Field

[0001] This invention relates to the field of operating system interaction technology, and in particular to a method for shared memory communication between Linux and non-Linux systems. Background Technology

[0002] With the rapid development of heterogeneous computing and multi-core processor architecture, the hybrid deployment mode of simultaneously deploying Linux and real-time operating systems, embedded systems, and virtual machines / emulation engines on a single hardware platform has become the mainstream solution in fields such as industrial control, autonomous driving, robotics, and aerospace embedded systems. Among them, Linux undertakes non-real-time tasks such as human-computer interaction, decision computing, and upper-level applications, while non-Linux systems such as FreeRTOS, RT-Thread, VxWorks, and QNX are responsible for real-time control, data acquisition, and instruction execution. In some scenarios, virtual machines and operating system execution engines are also introduced to achieve functional isolation and simulation verification. Current cross-system communication technologies have developed into multiple technical routes, but all have obvious limitations. Traditional network communication solutions such as TCP / IP and UDP rely on protocol stack encapsulation and multiple data copies, resulting in communication latency typically exceeding 100μs, high CPU usage, and large jitter, which cannot meet real-time control requirements. Shared storage solutions based on file systems or block devices suffer from I / O scheduling bottlenecks, unpredictable response times, and are unsuitable for high-frequency data interaction. Bus communication such as PCIe and CAN requires dedicated hardware support, leading to high system complexity, high cost, and poor versatility. Traditional POSIX shared memory and SystemV shared memory are only suitable for inter-process communication within the same operating system and cannot solve core issues such as memory mapping in heterogeneous systems, interrupt notification, and cache consistency. In recent years, virtualization and simulation technologies have been widely used in the development and verification of heterogeneous platforms. Virtual machines and operating system execution engines have further increased the complexity of communication links. Existing solutions cannot achieve unified interrupt routing and memory sharing between physical systems and virtualization / simulation instances. They lack dynamic scheduling mechanisms, resulting in unbalanced channel load, fixed interrupt routes, and unreasonable allocation of virtualization instance resources, leading to communication latency fluctuations, limited throughput, and inability to guarantee real-time performance. Therefore, existing cross-system communication technologies generally suffer from high latency, high overhead, poor compatibility, lack of support for virtualization / emulation, and inability to be dynamically optimized. They are difficult to meet the engineering requirements of low latency, high real-time performance, high reliability, and virtualization scalability of heterogeneous platforms at the same time. Therefore, there is an urgent need in this field for a shared memory communication method between Linux and non-Linux systems to solve the above problems. Summary of the Invention

[0003] This invention provides a shared memory communication method between Linux and non-Linux systems, aiming to overcome the shortcomings of existing heterogeneous cross-system communication such as high latency, large CPU overhead, difficulty in ensuring cache consistency, and incompatibility with virtualization / emulation environments. It achieves low latency, low overhead, high real-time performance, and dynamically optimizable cross-system communication, and realizes adaptive optimal performance configuration.

[0004] This invention provides a method for shared memory communication between Linux and non-Linux systems, comprising the following steps: Step 1: Reserve a contiguous memory region in physical memory that spans both Linux and non-Linux systems, and establish a mapping of this region to the respective virtual address spaces in both operating systems. Step 2: Build a virtual interrupt controller on top of the hardware interrupt controller to pass interrupt notifications across systems; Step 3: Define a layered communication protocol, which includes at least a physical layer for managing shared memory read and write, a transport layer for providing reliable data transmission, a synchronization layer for implementing cross-system atomic operations and locking mechanisms, and an application layer for providing user-mode programming interfaces. Step 4: Maintain cache consistency of the shared memory region through a software-maintained directory protocol; Step 5: Deploy virtualized communication agents on both the Linux system side and the non-Linux system side to form a virtualized communication execution environment. The virtualized communication execution environment includes at least one virtual machine instance or operating system execution engine simulation instance for dynamically optimizing cross-system communication paths. Step 6: Provide a unified programming interface to the application, which includes character devices or system calls on the Linux side and API function libraries on the non-Linux side.

[0005] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: 1. This invention reduces communication latency to the microsecond level through direct access to physically contiguous shared memory and interrupt-driven notification, significantly improving throughput. There is no data copying throughout the process, and CPU utilization is greatly reduced, meeting the requirements of strong real-time scenarios. It adopts a software directory protocol to maintain cache consistency, does not depend on hardware characteristics, and is compatible with various heterogeneous multi-core platforms such as ARM and RISC-V, with strong compatibility and high stability. 2. This invention decouples the physical layer, transport layer, synchronization layer, and application layer through a layered communication protocol, balancing reliability and ease of use. Upper-layer applications can adapt to cross-system communication without modification. It introduces a virtualized communication proxy and a virtual machine / operating system execution engine simulation instance to build a unified virtualized communication execution environment, achieving seamless interoperability between the physical system and the virtualization / simulation layer, thus expanding the applicability of the solution. 3. This invention enables dynamic calculation and scheduling of communication channel weights, interrupt route affinity, and virtualization instance time slices, automatically balancing loads, optimizing paths, and allocating resources. It maintains low jitter and high availability even under sudden traffic and load fluctuations, and can be widely applied to key scenarios such as autonomous driving, industrial control, and heterogeneous computing.

[0006] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0007] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention, but do not constitute a limitation thereof; in the drawings: Figure 1 This is a flowchart illustrating a shared memory communication method between Linux and non-Linux systems provided by the present invention. Detailed Implementation

[0008] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention. Example 1:

[0009] This invention provides a method for shared memory communication between Linux and non-Linux systems. Please refer to [link / reference]. Figure 1 This includes the following steps: Step 1: Reserve a contiguous memory region in physical memory that spans both Linux and non-Linux systems, and establish a mapping of this region to the respective virtual address spaces in both operating systems. Step 2: Build a virtual interrupt controller on top of the hardware interrupt controller to pass interrupt notifications across systems; Step 3: Define a layered communication protocol. The layered communication protocol should include at least a physical layer for managing shared memory read and write, a transport layer for providing reliable data transmission, a synchronization layer for implementing cross-system atomic operations and locking mechanisms, and an application layer for providing user-mode programming interfaces. Step 4: Maintain cache consistency of the shared memory region through a software-maintained directory protocol; Step 5: Deploy virtualization communication agents on both the Linux system side and the non-Linux system side to form a virtualization communication execution environment. The virtualization communication execution environment contains at least one virtual machine instance or operating system execution engine emulation instance for dynamically optimizing cross-system communication paths. Step 6: Provide a unified programming interface to the application, which includes character devices or system calls on the Linux side and API function libraries on the non-Linux side.

[0010] Specifically, in this embodiment, during the system startup phase, the bootloader (such as U-Boot) or device tree file reserves a segment of memory with contiguous physical addresses and a fixed size, and marks it as unallocated by the operating system. The Linux kernel parses this reserved information during startup and maps this segment of physical memory to the kernel virtual address space through the memory management module. For non-Linux systems (such as FreeRTOS), the region is used directly at the agreed physical address during startup. If the system supports the MMU, a virtual address mapping is also established. To enable real-time notification across systems, this embodiment abstracts a virtual interrupt layer above the hardware interrupt controller (such as the ARM General Interrupt Controller GIC). This layer intercepts software interrupts generated by one system, encapsulates them into virtual interrupt messages with the target system identifier, and passes them to the other system through a hardware interrupt line or inter-processor interrupt (IPI). Each operating system needs to register an interrupt service routine in advance to respond to virtual interrupts and read notifications from shared memory. This embodiment defines a layered communication protocol. The physical layer is responsible for reading and writing to shared memory, including address calculation, alignment, and byte order unification. The transport layer provides data verification (such as cyclic redundancy check), timeout retransmission, and sliding window flow control. The synchronization layer implements cross-system spinlocks, mutexes, and semaphores through atomic operation instructions (such as compare and swap). The application layer provides interfaces for application programs to create channels, send and receive messages, etc. To address the cache inconsistency issue that may arise from each system having its own independent cache in a multi-core processor, this embodiment employs a software directory protocol. A cache line status tracking table is allocated in shared memory to record the status of each cache line in each system's cache (e.g., modified, shared, invalid). When a system needs to write to shared memory, it first queries the directory table. If other systems hold a copy of the cache line, they are notified via a virtual interrupt to perform cache invalidation. After writing, the directory table is updated. Read operations are similar, and memory barrier instructions (such as data memory barriers) are used to ensure the sequential visibility of memory operations. This embodiment introduces a virtualized communication execution environment, namely, deploying a kernel-level virtualized communication agent (which can be a kernel thread or a lightweight virtual machine module) on the Linux side and a real-time task-based communication agent on the non-Linux side; these two agents together constitute a virtualized communication engine, which can monitor parameters such as queue length, latency, and bandwidth of each communication channel, and calculate dynamic access weight, interrupt affinity, and its own scheduling time slice through a built-in mathematical model, thereby adaptively adjusting channel priority, interrupt routing path, and agent CPU usage; To facilitate application use, this embodiment provides character device files (such as / dev / cross_os_comm) or adds system calls on the Linux side, which applications can access through standard operations such as opening, reading, writing, and controlling. On the non-Linux side, it provides function libraries consistent with the operating system API style, such as functions for sending and receiving messages, so that applications can achieve cross-system data exchange without understanding the underlying heterogeneous communication details.

[0011] In one implementation, step 1, the process of reserving a contiguous memory region in physical memory and establishing a mapping, includes: During system startup, a fixed-size contiguous block of memory is reserved from physical memory; Establish the mapping relationship between virtual addresses and physical addresses of contiguous memory blocks in both Linux and non-Linux systems; Configure the cache attributes of contiguous memory blocks to write-back mode or write-merge mode.

[0012] Specifically, during the system boot phase, this embodiment adds a reserved memory node by modifying the device tree file or the bootloader script, specifying the starting physical address and size (e.g., starting address 0x80000000, size 1MB), and setting attributes to mark this memory as not to be used as a general memory pool. When the Linux kernel starts, the memory management subsystem identifies this node and calls the reservation function to ensure that subsequent memory allocation will not occupy this area. For non-Linux systems, a memory region pointing to the same physical address is usually defined in the linker script, or the address is obtained by reading hardware registers during system initialization. In terms of memory mapping, the Linux kernel uses memory mapping functions to translate physical addresses into kernel virtual addresses. If user-space programs need to access these addresses, the same physical memory segment is mapped to the address space of the user process through a memory mapping interface (such as mmap). Non-Linux systems that support the MMU similarly create page table entries; those that do not support the MMU (such as bare-metal environments) directly use physical addresses for access. The cache attribute is set through the memory type field in the page table entry. Write-back mode means that the CPU writes to the cache first and then writes back to memory later, which is suitable for small data blocks that are frequently read and written. Write-merge mode merges multiple write operations into a burst transmission, which is suitable for writing large blocks of data. Preferably, write-back mode is used for control message channels and write-merge mode is used for batch data transmission channels.

[0013] In one implementation, the process of constructing a virtual interrupt controller (VIC) includes: Abstract a virtual interrupt layer above the hardware interrupt controller; Register cross-system interrupt service routines (ISRs) for Linux and non-Linux systems. Establish an interrupt routing table, which defines the mapping relationship between interrupt sources and the target operating system.

[0014] Specifically, the virtual interrupt layer is a software abstraction that runs in the kernels of both operating systems. It intercepts locally generated cross-system interrupt requests and converts them into interrupt signals that the target system can recognize. In its implementation, the Linux side can send interrupts to the non-Linux side by writing to a specific register or triggering an inter-processor interrupt, while the non-Linux side can send interrupts to the Linux side by configuring a dedicated interrupt line of the general interrupt controller. Each operating system needs to register a dedicated interrupt service routine for cross-system communication. In Linux, an interrupt handler is registered through an interrupt request registration function. This function is called when a virtual interrupt arrives and is responsible for retrieving a message from the shared memory receive queue and waking up the waiting process. In non-Linux systems, a hardware interrupt number is bound to a handler function through the interrupt registration interface provided by the operating system. This handler function should be as short as possible, usually setting only a flag or notifying a task. The interrupt routing table is a data structure stored in shared memory. Each record contains the interrupt source identifier, source operating system, target operating system, and current route enable flag. The initial routing table is written by the main control system during system initialization. When the interrupt affinity calculated by the virtualization communication agent according to the second formula is lower than the threshold, it can dynamically modify the interrupt routing table, such as remapping an interrupt source from the current interrupt line to another idle interrupt line, thereby improving response time.

[0015] In one implementation, the layered communication protocol includes: the physical layer managing read and write operations of shared memory regions; the transport layer providing data verification, retransmission, and flow control mechanisms; the synchronization layer implementing cross-system spinlocks, mutexes, or semaphores; and the application layer providing user-oriented message sending and receiving interfaces.

[0016] Specifically, the physical layer defines the specific layout of shared memory: it is usually divided into multiple circular buffers (one for each communication channel) and a control block area (which stores read / write pointers, status flags, and configuration parameters); the physical layer provides basic read / write primitives to ensure that data is stored correctly in shared memory and to handle byte order (unified to little-endian mode) and data alignment for different CPU architectures; The transport layer provides assurance for scenarios requiring reliable transmission. The sender adds a sequence number, timestamp, and checksum (such as CRC32) to the header of each message. The receiver verifies the data and replies with an acknowledgment message. If the sender does not receive an acknowledgment within a timeout period, a retransmission is triggered. The flow control mechanism uses a sliding window, whereby the receiver publishes the size of its remaining buffer at a specific location in shared memory, and the sender adjusts the transmission rate accordingly to avoid overflow. The synchronization layer implements cross-system locking mechanisms. Spin locks are implemented by atomically comparing and exchanging a flag bit in shared memory for instruction operations. Mutexes add wait queue management on top of spin locks and support timeout abandonment. Semaphores are used for the synchronization of counting resources, such as controlling the quantity relationship between producers and consumers. The acquisition and release operations of these locks need to be coordinated with memory barriers to prevent instruction reordering from causing lock failure. The application layer hides the complexity of the underlying layer from the upper layer, providing functions such as creating channels, sending messages, receiving messages, and closing channels. Users only need to specify the target operating system, data buffer, and length, and the application layer will automatically complete message encapsulation, channel selection, and underlying calls.

[0017] In one implementation, step 4, the process of maintaining cache consistency through a software-maintained directory protocol, includes: Establish a cache line status tracking table for the shared memory region to record the status of each cache line in the caches of various operating systems; When a change in cache line status is detected, a cache invalidation operation or a write-back operation is performed. Use memory barrier instructions to ensure the sequential visibility of memory operations across different operating systems.

[0018] Specifically, since Linux and non-Linux systems typically run on different CPU cores, each core has an independent L1 / L2 cache. When one side modifies shared memory data, the old value may still be retained in the cache on the other side, leading to data inconsistency. This embodiment solves this problem through a software directory protocol.

[0019] First, a directory table is allocated in the shared memory. The size of the table is equal to the total number of bytes in the shared memory divided by the cache line size (typically 64 bytes). Each directory entry records the status of the cache line, which can be "modified" (exclusively owned by this system and modified), "shared" (multiple systems have read-only copies), or "invalid" (no system holds a valid copy). In addition, the directory entry also records the system identifier that holds the cache line. When a Linux system is about to write to a shared memory address, it first queries the directory table. If the status is "shared" and other systems hold a copy, the Linux system sends a "cache invalidate" command to those systems via a virtual interrupt. Upon receiving the command, the other system executes the cache invalidate instruction, marking the corresponding line in its local cache as invalid. After the write is complete, the Linux system updates the directory table status to "modified". When a non-Linux system needs to read this address, if the directory table shows that the cache line has been modified by another system, it first sends a "write back" request to the other system. The other system writes the cache line back to the shared memory and updates the directory table status to "shared". Then the non-Linux system reads it from memory again. Memory barrier instructions (such as data memory barriers in the ARM architecture) are used to ensure that accesses after the barrier will not begin until all memory accesses before the barrier have been completed. This prevents out-of-order execution of shared memory operations by the compiler and CPU, ensuring that cross-system consistency protocols work correctly.

[0020] In one implementation, the process of deploying a virtualized communication agent to constitute a virtualized communication execution environment further includes: The dynamic access weight of the i-th communication channel in the shared memory region is calculated using the first formula. The first formula is: in, Let be the length of the data queue to be sent for the i-th channel at the current time t. The real-time communication delay of the i-th channel is... The preset attenuation coefficient, The total number of communication channels. It is the amplitude adjustment factor. The system scheduling cycle; The second formula is used to calculate the virtual interrupt controller to handle interrupt sources. Routing to the target operating system affinity The second formula is: in, This is the historical average outage response time. The currently predicted transmission interruption delay, The sensitivity coefficient, For the target operating system Currently available shared memory bandwidth, Total bandwidth for shared memory; The scheduling time slice of the k-th virtual machine instance or execution engine emulation instance in the virtualized communication execution environment is calculated using the third formula. The third formula is: in, As the reference time slice, This is the gain coefficient. This is the set of communication channels allocated to the k-th virtual machine instance or execution engine emulation instance. Let i be the real-time performance factor for the i-th channel. The attenuation constant is This represents the total number of virtual machine instances or execution engine simulation instances. It is a very small positive number; Based on the calculation , and It dynamically adjusts the access priority of each communication channel, the interrupt routing path, and the scheduling strategy of each virtual machine instance or execution engine simulation instance.

[0021] Specifically, this embodiment quantifies the cross-system communication status through a formula and adaptively adjusts resource allocation. The first formula is used to calculate a weight value between 0 and 1 for each communication channel, reflecting the proportion of transmission opportunities that the channel should obtain at the current moment. The larger the weight, the higher the priority the channel is served. The formula takes into account the real-time load (queue length) and communication latency of the channel and introduces periodic fluctuations to avoid oscillations caused by multiple channels competing at the same time. In the formula, The total number of bytes of data to be sent in the transmission queue of channel i is obtained by the virtualization communication agent in each scheduling cycle. The real-time communication delay of channel i is expressed in microseconds. It is obtained by recording the difference between the message sending time and the receiving end acknowledgment time, and then filtering it using an exponentially weighted moving average. This is the attenuation coefficient, a preset constant with a typical value of 0.5. This coefficient controls the degree to which delay penalizes the weights; the greater the delay, the greater the penalty imposed on the exponential term. The smaller; The total number of communication channels created by the system, configured by the upper layer; This is the amplitude adjustment factor, a preset constant with a typical value of 0.2, used to control the amplitude of sinusoidal fluctuations; This is the system scheduling cycle, a preset constant, with a typical value of 10 milliseconds. The item introduces time-related sinusoidal fluctuations, causing the weights to change slightly over time, which helps to break the balance when the weights of multiple channels are similar and avoid long-term conflicts. In this formula, the numerator is the queue length multiplied by a delay penalty term, the denominator is the sum of the numerators of all channels (normalized), and finally multiplied by a periodic modulation factor to make the weight fluctuate around the normalized value. Within each scheduling cycle, the virtualized communication agent adjusts the weights according to the channel's... In allocating transmission time, the agent maintains a virtual clock, with the transmission opportunity interval for each channel being equal to... In direct proportion, channels with higher weights are scheduled more frequently; The second formula is used to evaluate the efficiency of the path from the interrupt source s (e.g., the data ready signal on the Linux side) to the target operating system d; the higher the affinity, the more stable the response time and the sufficient bandwidth of the route path. This formula is used to guide the virtual interrupt controller to select the best interrupt route. In the formula, The historical average interrupt response time is measured in microseconds. After each interrupt is processed, the delay from triggering to the other party's response is recorded and updated using an exponentially weighted moving average. The predicted interrupt transmission latency is estimated based on the current shared memory load and interrupt controller state, for example, by linearly predicting the response time trend of the most recent interrupts. This is the sensitivity coefficient, a preset constant with a typical value of 2.0, used to control the severity of the penalty imposed on affinity by the prediction error; The currently available shared memory bandwidth for the target operating system is measured in MB / s, and is obtained by counting the amount of data successfully written to shared memory per unit of time. The maximum total bandwidth for shared memory is determined by the hardware platform; for example, a typical value for the ARMv8 platform is 10GB / s. Formula Part 1 This is a penalty for response time prediction errors; the larger the error, the lower the affinity, encouraging stable and predictable response times for routing paths; Part Two It is a logarithmic reward for available bandwidth; the higher the bandwidth, the higher the affinity, but the growth gradually saturates. The virtual interrupt controller periodically calculates the affinity of each interrupt source to each target system. If the affinity of the currently used routing path is lower than a preset threshold (e.g., 0.3), the interrupt routing table is reconstructed, which maps the interrupt source to another virtual interrupt line with higher affinity (which may be a different hardware interrupt number or a different interrupt priority). The reconstruction is achieved by writing new routing configurations to the interrupt controllers of the two systems. The third formula is used to dynamically allocate runtime slices for each virtualized communication agent (i.e., virtual machine instance or execution engine instance), so that CPU resources are tilted towards agents with heavy load and high real-time requirements. In the formula, This is the reference time slice, a preset constant, with a typical value of 500 microseconds; This is a preset gain coefficient, typically 0.5, used to control the aggressiveness of time slice adjustment; The set of communication channels assigned to the kth virtualization agent, for example, the Linux-side agent may manage channels 1 and 2, and the FreeRTOS-side agent may manage channel 3. This allocation relationship is determined during system initialization. Dynamic weights derived from the first formula; This is the real-time performance level factor for channel i, ranging from 0 to 1, and is specified by the user when creating the channel. 0.9 indicates high real-time performance (such as brake control), and 0.2 indicates low real-time performance (such as log transmission). This is a preset attenuation constant, typically 2.0; This item is used to convert the real-time level into a gain value between 0 and 1, with higher real-time channels receiving higher gain; The total number of virtualized agents. It is a very small positive number, used to prevent the denominator from being zero; The numerator in the formula is the weighted sum of all channels assigned to the agent, where the weight of each channel is... Multiply by real-time gain The denominator is the sum of the numerators of all agents, achieving normalization; the normalized ratio is multiplied by the gain coefficient β and then 1 is added to obtain the time slice scaling factor; the final time slice fluctuates around the reference time slice. The scheduler in the virtualized communication execution environment calculates... Set the actual runtime of each agent; for example, if the Linux agent gets 630 microseconds and the FreeRTOS agent gets 620 microseconds, the scheduler ensures that each agent has exclusive access to CPU resources during its time slice through timer interrupts, and switches to another agent after the time slice expires. Furthermore, the specific execution process of the dynamic adjustment strategy includes: At the beginning of each scheduling cycle (e.g., 10 milliseconds), the following closed-loop feedback process is executed: Data collection: Each virtualization agent reads statistical information such as queue length, communication latency, and available bandwidth for each channel from shared memory and updates historical data; Calculation: The agent executes the first formula to calculate the value for each channel. The second formula is executed to calculate the affinity of each interrupt source to the target system. Execute the third formula to calculate the value of each agent. ; Decision: A priority table is written to shared memory, and the physical layer of the sending end prioritizes the channel with the higher weight when sending. If the current affinity of a certain interrupt source If the value is below the threshold, the virtual interrupt controller reconfigures the hardware interrupt routing, maps the interrupt to the new interrupt line, and updates the interrupt routing table. The scheduler according to the new Reset the timer for each agent, and subsequent scheduling will be executed according to the new time slice; Execution: The new parameters take effect immediately and remain in effect until the next calculation cycle; Through this closed-loop feedback, the system can adaptively optimize cross-system communication performance and maintain high efficiency and stability in scenarios such as sudden traffic spikes and latency jitter.

[0022] In one implementation, deploying a virtualized communication agent includes: Deploy the first virtualization communication agent on the Linux system side as a kernel virtual machine module or a lightweight container; Deploy a second virtualized communication agent on the non-Linux system side as a real-time task or system service; The first virtualized communication agent and the second virtualized communication agent together constitute a virtualized communication execution environment, and perform simulation and scheduling of cross-system communication paths based on the calculation results of the first formula, the second formula and the third formula.

[0023] Specifically, the proxy on the Linux side can take one of two forms: Kernel virtual machine module form: It runs as an independent kernel thread with the highest priority and can directly access physical memory and the interrupt controller; this thread is created during system initialization and bound to a specified CPU core to avoid being preempted by other processes; Lightweight container approach: This approach uses Linux container technology (such as Docker) to encapsulate the agent process and allocates CPU and memory resources through a control group; it is suitable for scenarios that require isolation of multiple communication instances. On non-Linux sides (such as FreeRTOS), the agent exists as a high-priority real-time task. This task is created by the task creation function provided by the real-time operating system when the system starts, allocated an independent task stack (e.g., 1024 bytes), and has the highest priority set by the system. The main body of this task is an infinite loop that waits for virtual interrupts or message queues to be triggered. The two agents coordinate through a command channel in shared memory, such as synchronizing configuration parameters and exchanging formula calculation results. The agents periodically execute the above three formulas and notify each other of the results through shared memory or virtual interrupts, jointly completing the simulation of cross-system communication paths (i.e., simulating performance under different scheduling strategies) and actual scheduling adjustments.

[0024] In one implementation, providing a unified programming interface to applications further includes: Provides an asynchronous notification mechanism based on signals or callback functions to notify the application when new data arrives in shared memory or when sending is complete.

[0025] Specifically, to support asynchronous communication and avoid applications polling shared memory, this embodiment provides two notification mechanisms: On the Linux side, using standard signal or I / O event notification mechanisms, when there is new data in the receive queue of shared memory, the kernel driver sends a real-time signal to the process that has registered a signal handler through an asynchronous notification interface; the application can bind a signal handler function through the signal registration function; a more efficient way is to use a multiplexed interface (such as poll or epoll), and the driver wakes up the process waiting on the interface when new data arrives. On the non-Linux side, a callback function registration interface is provided. An application can register a callback function and corresponding parameters for a communication channel. When the virtual interrupt agent receives new data, it calls the registered callback function in the lower half of the interrupt service routine or in a dedicated task and passes the data pointer to it. The callback function should be as short as possible and is usually only responsible for waking up the main processing task of the application. Preferably, the Linux side also supports an event file descriptor mechanism, whereby the driver writes to the event counter when new data arrives, and the application can combine it with a multiplexing interface to achieve efficient event-driven operation.

[0026] In one implementation, the non-Linux system includes a real-time operating system, an embedded operating system, or a bare-metal environment; the method is applied to heterogeneous computing platforms, real-time control systems, or autonomous driving systems.

[0027] Specifically, non-Linux systems can be, but are not limited to, real-time operating systems such as FreeRTOS, Zephyr, RT-Thread, VxWorks, and QNX, or even bare-metal programs without any operating system. The virtualization communication agent in this embodiment has corresponding porting layers for different systems. For systems supporting POSIX threads, the agent runs as a regular thread; for bare-metal environments, the agent is periodically called as a background main loop.

[0028] Typical application scenarios include: heterogeneous computing platforms, such as the ARM big.LITTLE architecture, where Linux runs on a high-performance large core and the RTOS runs on a low-power small core, sharing sensor data through this method. Real-time control systems: In industrial robots, Linux is responsible for the human-machine interface and path planning, while the RTOS is responsible for joint servo control, with communication latency required to be less than 10 microseconds. Autonomous driving systems: Linux processes camera images and decision-making algorithms, while FreeRTOS processes braking and steering commands on the CAN bus. This method ensures that decision results are delivered to the real-time side within microseconds.

[0029] In one implementation, the method further includes: when a communication timeout or data corruption is detected, triggering a reset operation of the shared memory region and interrupting the dynamic reconstruction operation of the routing table through the virtualized communication execution environment.

[0030] Specifically, this embodiment incorporates an error detection and recovery mechanism. Each sent message carries a sequence number and a sending timestamp. The receiver replies with an acknowledgment message after receiving the message. The sender starts a timeout timer. If no acknowledgment is received within a preset time (e.g., 100 milliseconds), it is determined that the communication has timed out. The transport layer appends a Cyclic Redundancy Check (CRC) code to the end of each message. The receiver recalculates the checksum; if a match is not found, the message is discarded and a negative acknowledgment is sent. When consecutive timeouts or checksum failures exceed a threshold (e.g., 3 times), the virtualized communication execution environment initiates a recovery process. The two agents notify each other to enter the reset state via a virtual interrupt; the agents stop all data transmission and reception, clear all send and receive queues, reset all control flags (such as read / write pointers and status flags) to their initial values, and reinitialize the directory protocol table; The virtual interrupt controller clears all current routing entries, re-executes the initial discovery process (e.g., by hardware probing or reading the default configuration in the device tree), and then the second formula recalculates the affinity of each interrupt source to the target system, establishes a new routing mapping, and writes the optimal route to the hardware interrupt controller. Once the recovery is complete, the agent reports the error to the application via an asynchronous notification mechanism and automatically resumes communication.

[0031] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for shared memory communication between Linux and non-Linux systems, characterized in that, Includes the following steps: Step 1: Reserve a contiguous memory region in physical memory that spans both Linux and non-Linux systems, and establish a mapping of this region to the respective virtual address spaces in both operating systems. Step 2: Build a virtual interrupt controller on top of the hardware interrupt controller to pass interrupt notifications across systems; Step 3: Define a layered communication protocol, which includes at least a physical layer for managing shared memory read and write, a transport layer for providing reliable data transmission, a synchronization layer for implementing cross-system atomic operations and locking mechanisms, and an application layer for providing user-mode programming interfaces. Step 4: Maintain cache consistency of the shared memory region through a software-maintained directory protocol; Step 5: Deploy virtualized communication agents on both the Linux system side and the non-Linux system side to form a virtualized communication execution environment. The virtualized communication execution environment includes at least one virtual machine instance or operating system execution engine simulation instance for dynamically optimizing cross-system communication paths. Step 6: Provide a unified programming interface to the application, which includes character devices or system calls on the Linux side and API function libraries on the non-Linux side.

2. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, Step 1 includes: During system startup, a fixed-size contiguous block of memory is reserved from physical memory; Establish a mapping relationship between virtual addresses and the physical addresses of the contiguous memory blocks in both Linux and non-Linux systems; Configure the cache attributes of the contiguous memory blocks to write-back mode or write-merge mode.

3. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, The process of constructing the virtual interrupt controller includes: Abstract a virtual interrupt layer above the hardware interrupt controller; Register cross-system interrupt service routines for Linux and non-Linux systems; An interrupt routing table is established, which is used to define the mapping relationship between interrupt sources and target operating systems.

4. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, In the layered communication protocol: the physical layer manages read and write operations of the shared memory region; the transport layer provides data verification, retransmission, and flow control mechanisms; the synchronization layer implements cross-system spinlocks, mutexes, or semaphores; and the application layer provides user-oriented message sending and receiving interfaces.

5. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, Step 4 includes: Establish a cache line status tracking table for the shared memory region to record the status of each cache line in the caches of various operating systems; When a change in cache line status is detected, a cache invalidation operation or a write-back operation is performed. Use memory barrier instructions to ensure the sequential visibility of memory operations across different operating systems.

6. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, The process of deploying the virtualized communication agent to form a virtualized communication execution environment further includes: The dynamic access weight of the i-th communication channel in the shared memory region is calculated using the first formula. The first formula is: in, Let be the length of the data queue to be sent for the i-th channel at the current time t. The real-time communication delay of the i-th channel is... The preset attenuation coefficient, The total number of communication channels. It is the amplitude adjustment factor. The system scheduling cycle; The second formula is used to calculate the virtual interrupt controller to handle interrupt sources. Routing to the target operating system affinity The second formula is: in, This is the historical average outage response time. The currently predicted transmission interruption delay, The sensitivity coefficient, For the target operating system Currently available shared memory bandwidth, Total bandwidth for shared memory; The scheduling time slice of the k-th virtual machine instance or execution engine emulation instance in the virtualized communication execution environment is calculated using the third formula. The third formula is: in, As the reference time slice, This is the gain coefficient. This is the set of communication channels allocated to the k-th virtual machine instance or execution engine emulation instance. Let i be the real-time performance factor for the i-th channel. It is the attenuation constant. This represents the total number of virtual machine instances or execution engine simulation instances. It is a very small positive number; Based on the calculation , and It dynamically adjusts the access priority of each communication channel, the interrupt routing path, and the scheduling strategy of each virtual machine instance or execution engine simulation instance.

7. The method for shared memory communication between Linux and non-Linux systems according to claim 6, characterized in that, The deployment of the virtualized communication agent includes: Deploy the first virtualization communication agent on the Linux system side as a kernel virtual machine module or a lightweight container; Deploy a second virtualized communication agent on the non-Linux system side as a real-time task or system service; The first virtualized communication agent and the second virtualized communication agent together constitute the virtualized communication execution environment, and perform simulation and scheduling of cross-system communication paths based on the calculation results of the first formula, the second formula and the third formula.

8. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, Providing a unified programming interface to applications also includes: Provides an asynchronous notification mechanism based on signals or callback functions to notify the application when new data arrives in shared memory or when sending is complete.

9. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, The non-Linux system includes a real-time operating system, an embedded operating system, or a bare-metal environment; the method is applied to heterogeneous computing platforms, real-time control systems, or autonomous driving systems.

10. The method for shared memory communication between Linux and non-Linux systems according to claim 1, characterized in that, Also includes: When a communication timeout or data corruption is detected, the virtualized communication execution environment triggers a reset operation of the shared memory region and a dynamic reconstruction operation of the interrupt routing table.

Images