WO2023103767A1 - Homogeneous multi-core-based multi-operating system, communication method, and chip - Google Patents

Abstract

Provided in the present application are a homogeneous multi-core-based multi-operating system, a communication method therefor, and a chip. The multi-operating system at least comprises a first operating system and a second operating system, wherein the first operating system and the second operating system are located in different cores of the same processor. The communication method comprises: upon detecting a first data write operation, a first operating system updating first data to a cache unit of a second operating system by means of a cache coherence mechanism; upon detecting that the first data write operation is completed, the first operating system sending a sharing notification to the second operating system; and the second operating system receiving the sharing notification and acquiring the first data from the cache unit. By means of the method, the efficiency of data synchronization between operating systems can be improved.

Description

Multi-operating system, communication method, and chip based on isomorphic multi-core 【Technical field】

The present application relates to the technical field of multi-system communication, in particular to a multi-operating system based on homogeneous multi-core, a communication method, and a chip.

【Background technique】

At present, the "single-chip multi-system" solution on the car is becoming more and more popular. Complicated work often requires the coordination and cooperation between multiple operating systems to complete, and the cooperation between systems requires a good data communication mechanism.

Single-chip multi-system solutions are currently mainstream in vehicles, such as software virtualization solutions (Hypervisor), hardware intra-chip isolation solutions (in the case of heterogeneous multi-systems), etc. Different operating systems are responsible for different tasks. For the software virtualization solution, its general implementation is to design a layer of software on the CPU EL2 (Exception Level), and the EL2 software is responsible for managing data sharing and synchronization. For heterogeneous multi-system solutions, it is usually implemented by using hardware IPC combined with shared memory technology. However, the data synchronization efficiency between the systems of these two schemes is low.

【Content of invention】

The technical problem mainly solved by this application is to provide a multi-operating system based on isomorphic multi-core and its data synchronization method and chip, so as to improve the efficiency of data synchronization between operating systems.

In order to solve the above technical problems, the present application provides a communication method based on homogeneous multi-core multi-operating systems. The multi-operating system includes at least a first operating system and a second operating system, the first operating system and the second operating system are located in different cores of the same processor, the communication method includes: monitoring the first data write operation, the first operating system Update the first data to the cache unit of the second operating system through the cache consistency mechanism; detect that the first data write operation is completed, and the first operating system sends a sharing notification to the second operating system; the second operating system receives the sharing notification , acquire the first data from the cache unit.

In order to solve the above technical problems, the present application provides a multi-operating system based on homogeneous multi-core. The multi-operating system based on isomorphic multi-core at least includes: a first operating system and a second operating system, the first operating system and the second operating system are located in different cores of the same processor, and the first operating system detects the first data write operation , update the first data to the cache unit of the second operating system through the cache coherency mechanism; the first operating system detects that the first data write operation is completed, and sends a sharing notification to the second operating system; the second operating system receives the sharing Notify to obtain the first data from the cache unit.

In order to solve the above technical problems, the present application provides a chip. The chip runs multiple operating systems based on isomorphic multi-core, and the multiple operating systems include at least a first operating system and a second operating system, and the first operating system and the second operating system are located in different cores of the same processor, wherein the processor adopts the above-mentioned The communication method of the multi-operating system based on the homogeneous multi-core realizes the multi-communication system communication.

Compared with the prior art, the beneficial effects of the present application are: the multi-operating system of the present application includes at least a first operating system and a second operating system, the first operating system and the second operating system are located in different cores of the same processor, and the second operating system An operating system first updates the first data to the cache unit of the second operating system through a cache consistency mechanism, and after the first data write operation is completed, it notifies the second operating system to directly obtain the first data from its cache unit; therefore, the first When an operating system synchronizes the first data to the second operating system, the first operating system does not need to store the first data in its cache unit in the physical memory, and the second operating system does not need to clear the data in its cache unit, Instead, the first data may be directly read from the cache unit of the first operating system after receiving the sharing notification from the first operating system. Therefore, the efficiency of data synchronization between operating systems can be improved.

【Description of drawings】

FIG. 1 is a schematic structural diagram of an embodiment of a multi-operating system based on homogeneous multi-core in the present application;

FIG. 2 is a schematic flowchart of an embodiment of a communication method based on a homogeneous multi-core multi-operating system in the present application;

Fig. 3 is a schematic flow chart of step S21 in the embodiment of Fig. 2;

Fig. 4 is a schematic flow chart of step S35 in the embodiment of Fig. 2;

FIG. 5 is a schematic diagram of a data synchronization process in the prior art;

Fig. 6 is a schematic diagram of the direction of data flow in the embodiment of Fig. 5;

Fig. 7 is a schematic diagram of the data synchronization process in the embodiment of Fig. 2;

Fig. 8 is a schematic diagram of the direction of data flow in the embodiment of Fig. 7;

FIG. 9 is a schematic flowchart of an embodiment of a communication method based on a homogeneous multi-core multi-operating system of the present application;

FIG. 10 is a schematic flowchart of an embodiment of a communication method based on a homogeneous multi-core multi-operating system in the present application.

【Detailed ways】

The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

Single-chip multi-system solutions are currently mainstream in vehicles, such as software virtualization solutions (Hypervisor), hardware intra-chip isolation solutions (in the case of heterogeneous multi-systems), etc. Different operating systems are responsible for different tasks. For the software virtualization solution, its general implementation is to design a layer of software on the CPU EL2 (Exception Level), and the EL2 software is responsible for managing data sharing and synchronization. For heterogeneous multi-system solutions, it is usually implemented by using hardware IPC combined with shared memory technology. However, the data synchronization efficiency between the systems of these two schemes is low.

Communication between heterogeneous systems requires additional external hardware to trigger interrupts, while multi-cores in homogeneous systems can trigger interrupts faster; caches between heterogeneous systems are usually not shared, so consistency cannot be guaranteed , This leads to the long process of data transfer between systems: writing cache + flushing to memory and clearing cache + reading from memory, which affects the synchronization efficiency of data.

In order to solve the above problems, the present application first proposes a multi-operating system based on homogeneous multi-core, as shown in FIG. 1 , which is a schematic structural diagram of an embodiment of a multi-operating system based on homogeneous multi-core in the present application. The multi-operating system (not shown) based on homogeneous multi-core in this embodiment includes at least a first operating system 10 and a second operating system 20 , and the first operating system 10 and the second operating system 20 are located in different cores of the same processor. Wherein, the first operating system 10 monitors the first data write operation (the operation of writing into the cache unit 11), and updates the first data (from the cache unit 11) to the cache unit of the second operating system 20 through the cache consistency mechanism In 21 : the first operating system 10 detects that the writing operation of the first data is completed, and sends a sharing notification to the second operating system 20 ; the second operating system 20 receives the sharing notification, and obtains the first data from the cache unit 21 .

When the first operating system 10 of this embodiment synchronizes the first data to the second operating system 20, the first operating system 10 does not need to store the first data in its cache unit 11 in the physical memory 30, and the second operating system 20 There is also no need to clear the data in its cache unit 21, but directly read the first data from its cache unit 21 after receiving the sharing notification from the first operating system 10. Therefore, data synchronization between operating systems can be improved s efficiency.

The multi-operating system of isomorphic multi-core in the present embodiment and the following embodiment is described by taking the ARM processor (4 core CortexA53) as an example, the first operating system 10 is an audio-visual entertainment system IVI system, and the second operating system is an instrument system RTOS system.

Using an ARM CortexA53 (4 cores), the RTOS system control and IVI system control solutions are simultaneously implemented on the vehicle platform. When the IVI system tries to transmit phone information, map information, music playlist information, etc. to the RTOS system for displaying relevant information on the instrument side, the solution of this embodiment can realize efficient synchronization of data.

Among them, the IVI system configuration uses Core 0-Core2 three cores to run the Android system, and the RTOS system task is relatively simple, so the configuration uses Core3 one core to run the RTOS system. Because the IVI system and the RTOS system are isomorphic systems, the two operating systems need to access exactly the same physical memory unit. Therefore, in order to prevent the mutual influence on memory data between the two operating systems, it is necessary to additionally configure MMU mapping for memory isolation, that is, to map the virtual addresses of some cache units 11 of the IVI system to the virtual addresses of the IVI system through the Stage2 mapping of the MMU mapping. Exclusive physical memory unit and mapping the virtual address of part of the cache unit 21 of the RTOS system to the exclusive physical memory unit of the RTOS system. In order to reduce the data transmission time between the IVI system and the RTOS system, data synchronization between multiple operating systems requires a shared physical memory, which is used in the case where both the IVI system and the RTOS system can be accessed; through the Stage2 mapping of the MMU mapping, the other part of the IVI system is mapped The virtual address of a part of the cache unit and the virtual address of another part of the cache unit of the RTOS system are mapped to the shared physical memory unit.

Wherein, the MMU mapping is controlled by the processor, and its function is to realize the conversion from the virtual address of the cache unit to the physical address. The conversion process is divided into two stages: Stage 1, used to convert the input VA (virtual address) into PA (physical address) or IPA (corrected virtual address) output; Stage 2, used to convert IPA into pa. Or combine Stage 1 and Stage 2 to input VA->IPA->PA.

The physical memory of the multi-operating system is divided into three parts, in which the IVI system exclusively occupies one physical memory, and the RTOS system exclusively occupies the other physical memory, which can reduce the abnormality caused by stepping on the memory between the systems. The VI system and the RTOS system share the shared physical memory. .

Among them, the effect of the physical memory unit on the cache consistency includes: as an intermediate bridge where the address of the cache unit 21 of the RTOS system is consistent with the address of the cache unit 11 of the IVI system, that is, the virtual addresses of the cache unit 21 and the cache unit 11 are respectively mapped to the shared physical memory unit, and the two virtual addresses are consistent; and after the data in the cache unit 11 is full, when writing data, it is necessary to transfer the existing data of the cache unit 11 to the shared physical memory unit. At this time, the shared physical memory unit is equivalent to the cache Trash can in unit 11.

In this embodiment, the same spinlock driver is added in the first operating system 10 and the second operating system 20, and the first operating system 10 and the second operating system 20 are required to use the spinlock driver when applying for the protection of shared resources. When applying for a lock, the address of the shared physical memory unit occupied by the applied spin lock is the same. In order to achieve exclusive access to memory, a separate hardware module "Exclusive Monitor (Exclusive Monitor)" is provided to support this function, and this embodiment only needs a local monitor to implement a more convenient spinlock mechanism, while saving Snooping on the external bus optimizes control transfer times.

Among them, the spin lock driver requires that the first operating system 10 and the second operating system 20 can be allocated on demand, and the same lock is used when mutually exclusive access between the first operating system 10 and the second operating system 20, This requires that the allocation of locks also needs to be in shared physical memory units.

The present application further proposes a communication method for multi-operating systems based on homogeneous multi-cores, which is used for the above-mentioned multi-operating systems based on homogeneous multi-cores. As shown in FIG. 2 , FIG. 2 is a schematic structural diagram of an embodiment of a communication method based on a homogeneous multi-core multi-operating system in the present application. This embodiment specifically includes the following steps:

Step S21: When the first data writing operation is detected, the first operating system updates the first data to the cache unit of the second operating system through a cache coherence mechanism.

After monitoring the operation of writing the first data into the cache unit of the first operating system, the first operating system updates the first data from the cache unit of the first operating system to the cache unit of the second operating system through a cache coherence mechanism.

Taking the MOESI protocol as an example to introduce the cache consistency mechanism:

In this embodiment, a cache coherence mechanism is used to manage data transmission between cores of different operating systems. Its core mechanism is to represent each cache unit (Cache line) with a state:

M (Modify) bit: M is 1, indicating that the data contained in the current Cache line is inconsistent with the data in the physical memory unit, and it is only valid in the Cache line of this CPU (core), and does not exist in the Cache lines of other CPUs Copy, the data in this Cache row is the latest data copy in the current operating system. When the CPU replaces the Cache line, it will inevitably trigger a write cycle on the system bus to synchronize the data in the Cache line with the data in the memory.

E (Exclusive) bit: When E is 1, it means that the data contained in the current Cache line is valid, and the data is only valid in the Cache line of the current CPU, and there is no copy in the Cache lines of other CPUs. The data in the Cache row is the latest data copy in the current operating system, and is consistent with the data in the physical memory unit.

S (Shared) bit: S being 1 indicates that the data contained in the Cache line is valid, and there is a copy in the current CPU and at least one other CPU. When the state of a cache line is S, the data it contains is not necessarily consistent with the physical memory unit. If there is no copy with state O in the cache of other CPUs, the data in the cache line is consistent with the memory; if there is a copy with state O in the cache line of other CPUs, the data in the cache line is consistent with the physical memory Units are inconsistent.

I (Invalid) bit: I being 1 indicates that there is no valid data in the current Cache line or the Cache line is not enabled. When the MESI protocol performs Cache line replacement, it will preferentially use the Cache line whose I bit is 1.

O (Owned) bit: O being 1 indicates that the data contained in the current Cache line is the latest data copy of the current operating system, and there must be a copy of the Cache line in other CPUs, and the Cache line status of other CPUs is S. If the data of the physical memory unit has copies in the Cache lines of multiple CPUs, there is only one CPU whose Cache line status is O, and the Cache line status of other CPUs can only be S. Different from the S state in the MESI protocol, the data in the Cache row whose state is O is not consistent with the data in the physical memory unit.

The ARM processor is responsible for monitoring and maintaining the cache coherence between the cores through the snoop control unit (Snoop Control Unit, SCU), and also provides arbitration access to the L2Cache. Usually, each core in the SMP system has a register to control the switch of the cache coherency unit. Taking the Cortex A53 of ARM as an example, if the register CPUECTLR.smp bit is set, the SCU is turned on. In this embodiment, the SCU combined with the MOESI protocol can maintain the consistency of the data in the cache unit in time, and ensure the accuracy of the data obtained between each core, and these operations do not require software participation, which improves the maintainability of the software.

When the cache unit in the system is filled, if a new cache unit needs to be filled, a cache Evict operation is required, which is completed by hardware.

When the IVI system writes data to the cache, the SCU can monitor changes in the status of the Cache line corresponding to the physical memory unit in the IVI system, and can actively maintain cache consistency.

Optionally, step S21 may be implemented by the method shown in FIG. 3 . The method of this embodiment includes step S30 to step S35.

Step S30: The first data writing operation is detected.

An operation of writing the first data into the cache unit of the first operating system is monitored.

Step S31: the first operating system writes the first data into the cache unit of the first operating system.

The first operating system writes the first data into a corresponding Cache line in the first operating system.

Step S32: If the cache unit of the second operating system is empty, the cache unit of the first operating system writes the first data into the cache unit of the second operating system.

The data of the cache unit of the core where the first operating system is located is automatically synchronized to the cache unit of the core where the second operating system is located.

If there is no data in the corresponding Cache line in the RTOS system, the first operating system directly writes the first data in the corresponding Cache line into the corresponding Cache line in the RTOS.

Step S33: If the cache unit of the second operating system stores the second data, mark the status of the cache unit of the second operating system as invalid.

If the corresponding Cache line in the RTOS system has stored the second data, the state of the corresponding Cache line in the RTOS system is changed to I (Invalid).

Step S34: Determine whether there is a copy of the second data in the second operating system.

The RTOS system does not need to clear the cache when it starts to receive data, but can directly initiate a read request. At this time, other cores in the RTOS system can monitor the read request and actively check whether its own cache has a copy of the second data. .

Step S35: If the second operating system has a copy of the second data, update the first data to the cache unit of the second operating system based on the storage of the first data by the first operating system.

If a copy of the second data is cached in the RTOS system, writing the first data synchronized from the IVI system into the Cache line storing the second data in the RTOS system will not cause loss of the second data. At this time, the first data may be updated to the Cache line in the RTOS system based on the storage of the first data by the IVI system.

Optionally, in this embodiment, step S35 may be implemented through the method shown in FIG. 4 . The method of this implementation includes step S41 and step S42.

Step S41: If the first operating system has a copy of the first data, and the copy of the first data is consistent with the data in the corresponding physical memory, directly write the copy of the first data into the cache unit of the second operating system .

If the CPU in the IVI system finds a local copy, and the status is S, then directly flush the first data in the Cache row to the Cache row in the RTOS system, and the status of the corresponding Cache row in the RTOS system is changed to S;

If the CPU in the IVI system finds a local copy and the status is E, it will directly flush the first data in the Cache line to the Cache line in the RTOS system. At this time, the statuses of the Cache lines corresponding to the RTOS system and the IVI system are both changed to S.

Step S42: If the first operating system has a copy of the first data, and the copy of the first data is inconsistent with the data in the corresponding physical memory, first write the copy of the first data into the corresponding physical memory unit, and then Writing the copy of the first data in the corresponding physical memory unit into the cache unit of the second operating system.

If the CPU in the IVI system finds a local copy, and the state is M, it first updates the content in the Cache line to the physical memory unit. At this time, the state of the Cache line in the IVI system changes from M to S. At this time, the RTOS system needs to change from Acquire the first data from the physical memory unit.

Step S22: Upon detecting that the first data writing operation is completed, the first operating system sends a sharing notification to the second operating system.

In the prior art, the sign that the shared data writing is completed is the completion of flushing the cache, but in this embodiment, the cache consistency mechanism is used for self-maintenance, so the sign that the shared data writing is completed is the writing operation of the software (for example: memcpy, memset, etc. ).

After the first data writing of the IVI system is completed, a shared notification can be sent to the RTOS system through an inter-core interrupt (Software Generate Interrupt, SGI).

Traditional heterogeneous systems require additional hardware to support interrupt control between different CPUs. For the solution of virtualization under homogeneous systems, the communication between operating systems is more complicated in software implementation. This embodiment implements a message transmission mode between different operating systems based on an inter-core communication mechanism. Taking ARM as an example, the interrupt notification between operating systems can be realized through SGI, without external docking hardware, and the communication method is more convenient.

Step S23: the second operating system receives the sharing notification, and acquires the first data from the cache unit.

The RTOS system receives the sharing notification, and acquires the first data from the corresponding cache unit.

In the prior art, when the IVI system needs to share data to the RTOS system, the IVI system needs to first write the data in the shared physical memory unit; after the data of the IVI system is written, the RTOS system reads the data in the shared physical memory unit. data. Compared with the multi-system communication scheme commonly used in the industry, its operation process is roughly shown in Figure 5, and its corresponding data flow is shown in Figure 6.

In the prior art, in order to eliminate the cache interference between the IVI system and the RTOS system and ensure the accuracy of the data, the IVI system of the data sending party usually has two methods: close the cache unit in the corresponding area or after each data write is completed Actively refresh the cache. If the RTOS system of the corresponding data receiver does not close the cache unit in the corresponding area, it will clear the cache of the RTOS system before trying to receive the data, and then obtain the data from the shared physical memory unit. If the IVI system does not refresh the cache, there will be data inconsistency: the IVI system writes the data, but some data still exists in the cache line and has not been written into the shared physical memory unit. The data obtained by the physical memory unit is stale; if the RTOS system does not perform the operation of clearing the Cache, data inconsistency will also occur: the IVI system writes the data and completely flushes the data to the shared physical memory unit. The RTOS system directly reads the data because there is a cache. If the current RTOS system has previously backed up the data of the corresponding address in the Cache line (that is, the CPU read operation), then the RTOS system will directly read from its own Cache when it reads again. The old data is read out from the row without re-acquiring new data from the shared physical memory unit. Although the way of closing the cache avoids the above two problems, it undoubtedly affects the overall data transmission efficiency, and the way of actively refreshing and clearing the cache also increases the complexity and delay of the software to a certain extent.

In this embodiment, when the IVI system needs to synchronize data to the RTOS system, the operation flow is shown in FIG. 7 , and the corresponding data flow is shown in FIG. 8 . This embodiment uses the cache consistency mechanism to solve the above problems. When performing data synchronization operations, there is no need to actively operate the cache unit, and there is no need to care about whether it is the operation of flushing the Cache of the write operator or the operation of clearing the Cache of the read operator. The existence of the cache unit also increases the rate of data transfer.

The present application further proposes a communication method for a multi-OS based on homogeneous multi-core in another embodiment, which is used in the multi-OS based on homogeneous multi-core. As shown in FIG. 9 , FIG. 9 is a schematic structural diagram of an embodiment of a communication method based on a homogeneous multi-core multi-operating system in the present application. This embodiment specifically includes the following steps:

Step S91: Configuring a shared physical memory unit for the first operating system and the second operating system.

The first exclusive physical memory unit is configured for the first operating system, the second exclusive physical memory unit is configured for the second system, and the shared physical memory unit is configured for the first operating system and the second operating system.

Among them, the role of the shared physical memory unit on cache coherence includes: as an intermediate bridge between the addresses of the cache unit of the RTOS system and the cache unit of the IVI system: the virtual address of each cache unit must be mapped to a real physical address (convenient in Non-cache consistency, that is, in the non-communication state, each operating system can access the shared physical memory unit separately), so they are respectively mapped to the shared physical memory unit, and the two virtual addresses are consistent; under the condition of cache consistency , shared physical memory provides the real physical address as an intermediate mapping of the addresses of the cache units of the two operating systems. After the data in the cache unit is full, when writing data, the existing data in the cache unit needs to be moved to the shared physical memory unit. At this time, the shared physical memory unit is equivalent to the trash can of the cache unit.

Step S92: Map the virtual address of the cache unit of the first operating system and the virtual address of the cache unit of the second operating system to the shared physical memory unit through MMU mapping.

Map the virtual address of part of the cache unit of the first operating system to the first exclusive physical memory unit and map the virtual address of the part of the cache unit of the second operating system to the second exclusive physical memory unit through MMU mapping, and map the second exclusive physical memory unit through MMU mapping. The virtual address of another part of the cache unit of one operating system and the virtual address of another part of the cache unit of the second operating system are mapped to the shared physical memory unit.

The IVI system and the RTOS system achieve cache coherence through the shared physical memory unit of the two.

Because the IVI system and the RTOS system are isomorphic systems, the two operating systems can access exactly the same physical memory unit, that is, share the physical memory unit. Therefore, in order to prevent the mutual influence of memory data between the two operating systems, it is necessary to additionally configure MMU mapping for memory isolation, that is, to map the virtual addresses of some cache units of the IVI system to the first stage of the IVI system through the Stage2 mapping of the MMU mapping. An exclusive physical memory unit and the virtual address of the part cache unit of the RTOS system are mapped to the second exclusive physical memory unit of the RTOS system. The same physical address of multiple operating systems is mapped to the physical memory unit; for reducing the distance between the IVI system and the RTOS system The time of data transfer, data synchronization between multiple operating systems requires a shared physical memory unit, which is used in the case where both the IVI system and the RTOS system can be accessed. The Stage2 mapping of the MMU mapping will map the virtual address of another part of the cache unit of the IVI system and The virtual address of another part of the cache unit of the RTOS system is mapped to the shared physical memory unit.

That is, the virtual address of the cache unit 11 of the IVI system and the virtual address of the cache unit 21 of the RTOS system are mapped to the same physical address of multiple operating systems through MMU mapping, that is, to a shared physical memory unit.

Wherein, the data caching methods of multiple operating systems include: VIVT, VIPT or PIPT.

Specifically, VIVT (Virtual Index Virtual Tag) is a tag field using a virtual address index field and a virtual address; VIPT (Virtual Index Physical Tag) is a tag using a virtual address index field and a physical address; PIPT (Physical Index Physical Tag) It is an index field using a physical address and a tag field of a physical address.

Step S93: In response to the fact that the data caching mode is VIVT, different flags are set for the virtual address space of the first operating system and the virtual address space of the second operating system.

In response to the fact that the data cache mode is VIVT, the same mapping relationship is configured for the Stage1 mapping of the MMU mapping of the shared physical memory unit by the first operating system and the second operating system, and are respectively the virtual address space of the first operating system and the second operating system. The operating system's virtual address space sets different flags.

When the data caching mode (that is, the relationship between the cache unit and the memory unit) is VIPT and PIPT, the position in the cache is strongly related to the physical address, so the cache consistency maintenance can be designed to be consistent based on the physical address, for multiple operating systems The mapping method does not require additional requirements. It only needs to use the same physical address when sharing data. When two operating systems operate on the virtual address corresponding to the same physical address, the cache consistency is maintained by the SCU itself.

When the data cache mode is VIVT, the first operating system and the second operating system need to configure the same mapping relationship for the Stage1 mapping of the shared memory area, so as to ensure the consistency of the cache.

Furthermore, when the data cache mode is VIVT, it may cause the problem of cache aliases, that is, multiple identical virtual addresses may be mapped to the same physical address; for example, inter-process communication, which will lead to pointing to the same physical address The caches of the virtual addresses are stored separately, so there may be consistency problems. For example, after changing the cache line of a virtual address, the cache of the virtual address pointing to the same physical address is not changed, resulting in data inconsistency. In this case, in this embodiment, different virtual address spaces are distinguished by adding a tag (ASID) to each virtual address space.

Step S94: The first operating system updates the first data into the cache unit of the second operating system through a cache coherence mechanism.

After detecting the write operation of the first data, the first operating system updates the first data to the cache unit of the second operating system through a cache consistency mechanism.

Step S95: upon detecting that the first data writing operation is completed, the first operating system sends a sharing notification to the second operating system.

Step S96: The second operating system receives the sharing notification, and obtains data from the cache unit.

Steps S94 to S96 are similar to the above steps S11 to S13 and will not be repeated here.

The present application further proposes a communication method for a multi-OS based on homogeneous multi-core in another embodiment, which is used in the multi-OS based on homogeneous multi-core. As shown in FIG. 10 , FIG. 10 is a schematic structural diagram of an embodiment of a communication method based on a homogeneous multi-core multi-operating system in the present application. This embodiment specifically includes the following steps:

Step S101: upon detecting the first data write operation, the first operating system updates the first data to the cache unit of the second operating system through a cache coherence mechanism.

Step S102: upon detecting that the first data writing operation is completed, the first operating system sends a sharing notification to the second operating system.

Step S103: the second operating system receives the sharing notification, and obtains data from the cache unit.

Steps S101 to S103 are similar to the above steps S11 to S13 and will not be repeated here.

Step S104: It is detected that the first operating system and the second operating system jointly access the same shared physical memory unit, and the spin lock application of the first operating system or the second operating system is detected, and a variable is created in the shared physical memory unit to Store current data in the same shared physical memory unit.

Step S105: Locally monitor multiple operating systems, and write current data into the same shared physical memory unit after the monopoly of the same shared physical memory unit ends.

In this embodiment, when a certain resource (shared physical memory unit) in multiple operating systems is jointly accessed by cores of multiple operating systems, such as during read and write operations, the multiple operating systems need to protect this part of the resource; this embodiment is described in The same spin lock driver is added to the first operating system and the second operating system, and the first operating system and the second operating system are required to apply for the lock through the spin lock driver when applying for the protection of shared resources. The applied spin lock The addresses of the occupied shared physical memory units are the same (based on the implementation of VIPT and PIPT). In order to achieve exclusive access to memory, the ARM processor provides a separate hardware module "Exclusive Monitor (Exclusive Monitor)" to support this function, and this embodiment only needs a local monitor to implement a more convenient spinlock mechanism, and at the same time Elimination of external bus snooping optimizes control transfer times.

To keep data synchronized in the case of multi-threading, it is necessary to introduce operations called Load-Link (LL) and Store-Conditional (SC), and create variables in the shared physical memory unit, and the shared physical memory to be accessed by the LL operation The current data in the memory unit is stored in the variable, and the shared physical memory unit is marked as exclusive; SC operation, after the occupied shared physical memory unit is completed, the current data in the variable is written back to the shared physical memory unit , and cancel the exclusive mark. For the ARM platform, it also provides support for LL/SC at the hardware level. Taking Cortex-A53 as an example, the LL operation uses the LDREX instruction, and the SC operation uses the STREX instruction.

Furthermore, in other embodiments, a hardware firewall may be added for monitoring memory access control, and the minimum unit that the hardware firewall can monitor needs to be each core. In this way, even if there is a problem with the system MMU configuration, the memory conflict of the system can be isolated from the hardware to ensure the independence of the system.

Furthermore, since there is a swapping-out mechanism in the cache, assembly-level process optimization can be added to the part of shared data to reduce the high latency caused by data swapping in and out.

Furthermore, the above process is considered based on ARM series CPUs. For CPUs with other architectures, there may be different cache coherence mechanisms and hardware modules, and related software needs to be implemented in a targeted manner.

The present application further proposes a chip. The chip in this embodiment runs multiple operating systems. The multiple operating systems include at least a first operating system and a second operating system. The first operating system and the second operating system are located in different cores of the same processor. , the processor adopts the communication method based on the homogeneous multi-core multi-operating system in the above-mentioned embodiment to implement multi-communication system communication.

Different from the prior art, the multi-operating system of the present application includes at least a first operating system and a second operating system. The first operating system and the second operating system are located in different cores of the same processor. The first operating system first passes the cache coherency The mechanism updates the first data to the cache unit of the second operating system. After the first data write operation is completed, the second operating system is notified to obtain the first data directly from its cache unit; therefore, the first operating system synchronizes the first data When the second operating system arrives, the first operating system does not need to store the first data in its cache unit into the physical memory, and the second operating system does not need to clear the data in its cache unit, but directly receives the first After the sharing notification of the operating system, the first data can be directly read from its cache unit, therefore, the efficiency of data synchronization between operating systems can be improved.

Furthermore, based on the cache coherence mechanism, the synchronization of data transmission between cores of different operating systems is more free, without too much software participation; memory isolation technology is added to clarify shared memory and non-shared memory, reducing multi-operation Interaction between systems; multiple operating systems use a unified spin lock driver to provide a more convenient protection mechanism for accessing critical resources between multiple operating systems.

The above is only the implementation of the application, and does not limit the patent scope of the application. Any equivalent structure or equivalent process conversion made by using the specification and drawings of the application, or directly or indirectly used in other related technologies fields, are all included in the scope of patent protection of this application in the same way.

Claims (10)

A communication method based on a homogeneous multi-core multi-operating system, characterized in that the multi-operating system includes at least a first operating system and a second operating system, and the first operating system and the second operating system are located in the same different cores of the processor, the communication method comprising: When a first data write operation is detected, the first operating system updates the first data to the cache unit of the second operating system through a cache coherency mechanism; Upon detecting that the first data writing operation is completed, the first operating system sends a sharing notification to the second operating system; The second operating system receives the sharing notification, and obtains the first data from the cache unit. The communication method according to claim 1, wherein the first operating system updates the first data into the cache unit of the second operating system through a cache coherence mechanism, comprising: The first operating system writes the first data into a cache unit of the first operating system; If the cache unit of the second operating system is empty, the cache unit of the first operating system writes the first data into the cache unit of the second operating system. The communication method according to claim 1, wherein the first operating system updates the first data into the cache unit of the second operating system through a cache coherency mechanism, further comprising: If the cache unit of the second operating system stores the second data, modify the state of the cache unit of the second operating system to be invalid; determining whether a copy of the second data exists for the second operating system; If the second operating system has a copy of the second data, updating the data into the cache unit of the second operating system based on the storage of the first data by the first operating system. The communication method according to claim 3, wherein the updating of the data into the cache unit of the second operating system based on the storage of the first data by the first operating system includes : If the first operating system stores a copy of the first data, and the copy of the first data is consistent with the data in the corresponding physical memory unit, directly write the copy of the first data into the In the cache unit of the second operating system. The communication method according to claim 3, wherein the first data is updated to the cache unit of the second operating system based on the storage of the first data by the first operating system , further including: If the first operating system stores a copy of the first data, and the copy of the first data is inconsistent with the data in the corresponding physical memory, first write the copy of the first data into the corresponding and then write the copy of the first data in the corresponding physical memory unit into the cache unit of the second operating system. The communication method according to claim 1, further comprising: configuring a shared physical memory unit for the first operating system and the second operating system; The virtual address of the cache unit of the first operating system and the virtual address of the cache unit of the second operating system are mapped to the shared physical memory unit through MMU mapping. The communication method according to claim 6, wherein the data caching method of the multi-operating system comprises: VIVT, VIPT or PIPT, and the communication method further comprises: In response to the data caching mode being the VIVT, different flags are respectively set for the virtual address space of the first operating system and the virtual address space of the second operating system. The communication method according to claim 1, wherein upon detecting that the data writing operation is completed, the first operating system sends a sharing notification to the second operating system, comprising: After detecting that the first data writing operation is completed, the first operating system sends a sharing notification to the second operating system in an inter-core interrupt manner. A multi-operating system based on isomorphic multi-core, characterized in that it includes at least: a first operating system and a second operating system, the first operating system and the second operating system are located in different cores of the same processor, so The first operating system detects the first data write operation, and updates the first data to the cache unit of the second operating system through a cache coherence mechanism; the first operating system detects that the first data After the write operation is completed, a sharing notification is sent to the second operating system; the second operating system receives the sharing notification, and acquires the first data from the cache unit. A chip, characterized in that it runs a multi-operating system based on isomorphic multi-core, the multi-operating system includes at least a first operating system and a second operating system, and the first operating system and the second operating system are located in the same Different cores of the processor, wherein the processor implements the multi-communication system communication by using the communication method based on the multi-operating system based on homogeneous multi-core according to any one of claims 1-8.

Images