CN114416387A - Multi-operating system based on isomorphic multi-core, communication method and chip - Google Patents
Multi-operating system based on isomorphic multi-core, communication method and chip Download PDFInfo
- Publication number
- CN114416387A CN114416387A CN202111476557.9A CN202111476557A CN114416387A CN 114416387 A CN114416387 A CN 114416387A CN 202111476557 A CN202111476557 A CN 202111476557A CN 114416387 A CN114416387 A CN 114416387A
- Authority
- CN
- China
- Prior art keywords
- operating system
- data
- cache
- cache unit
- communication method
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/543—Local
Abstract
The application provides a multi-operation system based on isomorphic multi-core, a communication method and a chip thereof. 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 positioned in different kernels of the same processor, and the communication method comprises the following steps: when the write operation of the first data is monitored, the first operating system updates the first data to a cache unit of a second operating system through a cache consistency mechanism; when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system; and the second operating system receives the sharing notice and acquires the first data from the cache unit. In this way, the efficiency of data synchronization between operating systems can be improved.
Description
Technical Field
The present application relates to the field of multi-system communication technologies, and in particular, to a multi-operating system, a communication method, and a chip based on homogeneous multi-core.
Background
Currently, a scheme of 'single chip multi-system' on a vehicle machine is more and more popular. Complex tasks often require coordination among multiple operating systems, which requires a good data communication mechanism.
The single-chip multi-system scheme is currently mainstream on a vehicle machine, such as a software virtualization scheme (Hypervisor), a hardware on-chip isolation scheme (heterogeneous multi-system situation), and the like, and different operating systems are responsible for different task contents. For the software virtualization scheme, a layer of software is designed in the CPU EL2(Exception Level), and the software of the EL2 is responsible for managing sharing and synchronization of data. For heterogeneous multi-system schemes, hardware IPC is usually used in combination with shared memory technology. But the data synchronization between the systems of the two schemes is inefficient.
Disclosure of Invention
The technical problem mainly solved by the application is to provide a multi-operating system based on isomorphic multi-core and a data synchronization method and a chip thereof, so as to improve the efficiency of data synchronization among the operating systems.
In order to solve the technical problem, the present application provides a communication method based on a homogeneous multi-core multi-operating system. 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 positioned in different kernels of the same processor, and the communication method comprises the following steps: when the write operation of the first data is monitored, the first operating system updates the first data to a cache unit of a second operating system through a cache consistency mechanism; when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system; and the second operating system receives the sharing notice and acquires the first data from the cache unit.
In order to solve the technical problem, the application provides a multi-operating system based on homogeneous multi-core. The homogeneous multi-core based multi-operating system at least comprises: the first operating system monitors the write operation of the first data and updates the first data to a cache unit of the second operating system through a cache consistency mechanism; when monitoring that the first data writing operation is completed, the first operating system sends a sharing notice to the second operating system; and the second operating system receives the sharing notice and acquires the first data from the cache unit.
In order to solve the technical problem, the application provides a chip. The chip runs a multi-operating system based on the isomorphic multi-core, the multi-operating system at least comprises a first operating system and a second operating system, the first operating system and the second operating system are located in different kernels of the same processor, and the processor adopts the communication method based on the isomorphic multi-core multi-operating system to realize multi-communication system communication.
Compared with the prior art, the beneficial effects of this application are: 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 positioned in different kernels of the same processor, the first operating system updates first data into a cache unit of the second operating system through a cache consistency mechanism, and after the write operation of the first data is finished, the second operating system is informed to directly acquire the first data from the cache unit of the second operating system; therefore, when the first operating system synchronizes the first data to the second operating system, the first operating system does not need to store the first data in the cache unit of the first operating system in the physical memory, and the second operating system does not need to empty the data in the cache unit of the second operating system, but directly reads the first data from the cache unit of the second operating system after receiving the sharing notification of the first operating system, so that the efficiency of data synchronization between the operating systems can be improved.
Drawings
FIG. 1 is a schematic structural diagram of an embodiment of a homogeneous multi-core based multi-operating system according to the present application;
FIG. 2 is a flowchart illustrating an embodiment of a communication method based on a multi-operating system with homogeneous multi-cores according to the present application;
FIG. 3 is a detailed flowchart of step S21 in the embodiment of FIG. 2;
FIG. 4 is a detailed flowchart of step S35 in the embodiment of FIG. 2;
FIG. 5 is a prior art data synchronization flow diagram;
FIG. 6 is a schematic diagram of the data flow orientation of 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 data flow orientation of the embodiment of FIG. 7;
FIG. 9 is a flowchart illustrating an embodiment of a communication method based on a multi-OS with homogeneous multi-core according to the present application;
fig. 10 is a flowchart illustrating an embodiment of a communication method based on a multi-operating system with homogeneous multiple cores according to the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The single-chip multi-system scheme is currently mainstream on a vehicle machine, such as a software virtualization scheme (Hypervisor), a hardware on-chip isolation scheme (heterogeneous multi-system situation), and the like, and different operating systems are responsible for different task contents. For the software virtualization scheme, a layer of software is designed in the CPU EL2(Exception Level), and the software of the EL2 is responsible for managing sharing and synchronization of data. For heterogeneous multi-system schemes, hardware IPC is usually used in combination with shared memory technology. But the data synchronization between the systems of the two schemes is inefficient.
Communication between heterogeneous systems needs to add external hardware to trigger interruption, and interruption can be triggered more quickly among multiple cores of homogeneous systems; caches between heterogeneous systems are usually not shared, and therefore consistency cannot be guaranteed, which results in data transfer between systems through: the lengthy flow of writing in the cache, brushing in the memory and clearing the cache and reading from the memory affects the data synchronization efficiency.
To solve the above problem, the present application first proposes a multi-operating system based on homogeneous multi-core, as shown in fig. 1, and fig. 1 is a schematic structural diagram of an embodiment of the multi-operating system based on homogeneous multi-core. The multi-os (not shown) based on homogeneous multi-core in this embodiment at least includes a first os 10 and a second os 20, and the first os 10 and the second os 20 are located in different cores of the same processor. Wherein, the first operating system 10 monitors the first data writing operation (the operation of writing into the cache unit 11), and updates the first data (from the cache unit 11) to the cache unit 21 of the second operating system 20 through the cache consistency mechanism; when monitoring that the first data writing operation is completed, the first operating system 10 sends a sharing notification to the second operating system 20; the second operating system 20 receives the sharing notification, and acquires the first data from the cache unit 21.
When the first operating system 10 synchronizes the first data to the second operating system 20 in this embodiment, the first operating system 10 does not need to store the first data in the cache unit 11 in the physical memory 30, and the second operating system 20 does not need to empty the data in the cache unit 21, but directly reads the first data from the cache unit 21 after receiving the sharing notification of the first operating system 10, so that the efficiency of data synchronization between the operating systems can be improved.
In this embodiment and the following embodiments, the ARM processor (4-core cortex xa53) is taken as an example of the homogeneous multi-core multi-operating system, the first operating system 10 is an IVI system, and the second operating system is an RTOS system.
An ARM cortex xA53(4 cores) is used for simultaneously realizing management of an RTOS system and management of an IVI system on an on-board platform. When the IVI system attempts to deliver phone information, map information, music playlist information, etc. to the RTOS system for displaying relevant information at the meter end, efficient synchronization of data can be achieved by the scheme of this embodiment.
The IVI system is configured to run an Android system by using three cores of Core 0-Core2, and the RTOS system is relatively simple in task, so that the Core3 is configured to run the RTOS system by using one Core. Because the IVI system and the RTOS system are homogeneous systems, the two operating systems need to access the exact same physical memory location. Therefore, in order to prevent the memory data from affecting each other between the two operating systems, MMU mapping is additionally configured to perform memory isolation, that is, mapping the virtual address of the partial cache unit 11 of the IVI system to the exclusive physical memory unit of the IVI system and mapping the virtual address of the partial cache unit 21 of the RTOS system to the exclusive physical memory unit of the RTOS system by using Stage2 mapping of MMU mapping. In order to reduce the time for data transmission between the IVI system and the RTOS system, a segment of shared physical memory is required for data synchronization between multiple operating systems, and the shared physical memory is used for the condition that the IVI system and the RTOS system can access; stage2 mapping by MMU maps the virtual address of another portion of the cache location of the IVI system and the virtual address of another portion of the cache location of the RTOS system to a shared physical memory location.
The MMU mapping is controlled by the processor, and the function of the MMU mapping is to realize the translation of the virtual address into the physical address of the cache unit. The conversion process is divided into two phases: stage1 for converting input VA (virtual address) into PA (physical address) or IPA (modified virtual address) and outputting it; stage2 for conversion of IPA to PA. Or VA- > IPA- > PA which is input by combining Stage1 and Stage 2.
The physical memory of the multi-operating system is divided into 3 parts, wherein the IVI system exclusively uses one physical memory, the RTOS system exclusively uses the other physical memory, so that the abnormity caused by stepping on the memory among the systems can be reduced, and the VI system and the RTOS system share the shared physical memory.
The effect of the physical memory unit on the cache consistency includes: as an intermediate bridge between the address consistence of the cache unit 21 of the RTOS system and 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; after the data in the cache unit 11 is fully written, when the data is written, the existing data in the cache unit 11 needs to be transported to the shared physical memory unit, and the shared physical memory unit is equivalent to a garbage can of the cache unit 11.
In this embodiment, the same spin lock 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 apply for a lock through the spin lock driver when applying for protection of a shared resource, and addresses of shared physical memory units occupied by the applied spin lock are the same. In order to realize Exclusive access of the memory, an independent hardware module, namely an Exclusive Monitor (Exclusive Monitor), is provided to support the function, and the embodiment can realize a more convenient spin lock mechanism only by a local Monitor, and simultaneously saves monitoring of an external bus and optimizes control transfer time.
The spinlock driver requires that the use between the first operating system 10 and the second operating system 20 can be allocated as required, and the same lock is used for the exclusive access between the first operating system 10 and the second operating system 20, which requires that the allocation of the lock also needs to be in the shared physical memory unit.
The application further provides a communication method of the multi-operating system based on the isomorphic multi-core, which is used for the multi-operating system based on the isomorphic multi-core. 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 according to the present application. The embodiment specifically comprises the following steps:
step S21: and when the first data writing operation is monitored, the first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism.
And monitoring the operation of writing the first data into the cache unit of the first operating system, and updating the first data from the cache unit of the first operating system to the cache unit of the second operating system by the first operating system through a cache consistency mechanism.
The MOESI protocol is taken as an example to introduce a cache consistency mechanism:
the present embodiment utilizes a cache coherency mechanism to manage data transfers between cores of different operating systems. The core mechanism is that each Cache unit (Cache line) is expressed by a state:
m (modify) bit: m is 1, which indicates that the data contained in the current Cache line is inconsistent with the data in the physical memory unit, and the data is only valid in the Cache line of the CPU (core), and no copy exists in the Cache lines of other CPUs, and the data in the Cache line is the latest data copy in the current operating system. When the CPU performs a replacement operation on the Cache line, a write cycle of the system bus is inevitably initiated, and the data in the Cache line is synchronized with the data in the memory.
E (exclusive) bit: when E is 1, 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 no copy exists in the Cache lines of other CPUs. The data in the Cache line is the latest copy of data in the current operating system and is consistent with the data in the physical memory unit.
S (shared) bit: s is 1 indicating that the data contained in the Cache line is valid and that there are copies in the current CPU and at least one other CPU. When a Cache line state is S, the data it contains is not necessarily consistent with physical memory units. If the copy in the state of O does not exist in the caches of other CPUs, the data in the Cache line is consistent with the memory; and if the copies in the O state exist in the Cache lines of other CPUs, the data in the Cache lines are inconsistent with the physical memory units.
I (Invalid) bit: i is 1, which means that no valid data exists in the current Cache line or the Cache line is not enabled. When the Cache line is replaced, the MESI protocol preferentially uses the Cache line with the I bit of 1.
O (owned) bit: an O of 1 indicates that the data included in the current Cache line is the latest data copy of the current operating system, and a copy of the Cache line is necessarily provided in other CPUs, and the Cache line states of the other CPUs are S. If the data of the physical memory unit has copies in the Cache lines of a plurality of CPUs, the Cache line state of one CPU is O, and the Cache line states of other CPUs can only be S. Unlike the S state in the MESI protocol, the data in the Cache line with the state O is not consistent with the data in the physical memory unit.
The ARM processor is responsible for monitoring and maintaining Cache consistency among cores through a Snoop Control Unit (SCU), and also provides arbitration access to the L2 Cache. Generally, each core in an SMP system has a register for controlling the switch of a cache coherence unit, and taking Cortex a53 of ARM as an example, if the register cpuectlr. In this embodiment, the SCU and the MOESI protocol are used to maintain the consistency of data in the cache unit in time, so as to ensure the accuracy of data acquisition between cores, and these operations do not need software to participate, thereby improving the maintainability of software.
When the cache units in the system are filled, if new cache units need to be filled, cache Evict operation needs to be carried out and is completed by hardware.
When the IVI system writes data into the Cache, the SCU can monitor that the Cache line state of a corresponding physical memory unit in the IVI system is changed, and can actively maintain Cache consistency.
Alternatively, step S21 may be implemented by a method as shown in fig. 3. The method of the present embodiment includes steps S30 to S35.
Step S30: a first data write operation is monitored.
And monitoring the operation of writing the first data into the cache unit of the first operating system.
Step S31: the first operating system writes the first data into a cache unit of the first operating system.
And the first operating system writes the first data into a corresponding Cache line in the first operating system.
Step S32: and 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.
And automatically synchronizing the data of the cache unit of the core of the first operating system to the cache unit of the core of the second operating system.
And if no data exists in the corresponding Cache line in the RTOS, the first operating system directly writes the first data in the corresponding Cache line into the corresponding Cache line in the RTOS.
Step S33: and if the cache unit of the second operating system stores the second data, marking the state of the cache unit of the second operating system as invalid.
And if the corresponding Cache line in the RTOS system has the second data, modifying the state of the corresponding Cache line in the RTOS system into I (Invalid).
Step S34: it is determined whether a copy of the second data exists for the second operating system.
The RTOS system does not need to perform cache clearing operation when beginning to receive data, but can directly initiate a read request, and at the moment, other cores in the RTOS system can monitor the read request and actively check whether the copy of the second data is cached in the RTOS system.
Step S35: and if the second operating system has a copy of the second data, updating the first data to a cache unit of the second operating system based on the storage condition of the first operating system on the first data.
If the RTOS system caches a copy of the second data, the first data synchronized by the IVI system is written into a Cache line in the RTOS system, which stores the second data, and the second data cannot be lost. The first data can be updated to a Cache line in the RTOS system based on the storage condition of the IVI system to the first data.
Alternatively, the present embodiment may implement step S35 by the method shown in fig. 4. The method of this embodiment includes steps S41 and S42.
Step S41: and if the first operating system stores the copy of the first data and the copy of the first data is consistent with the data in the corresponding physical memory, directly writing the copy of the first data into a cache unit of the second operating system.
If the CPU in the IVI system finds a local copy and the state is S, directly brushing first data in the Cache line into the Cache line in the RTOS system, and changing the Cache line state corresponding to the RTOS system to S at the moment;
if the CPU in the IVI system finds the local copy and the state is E, directly brushing the first data in the Cache line into the Cache line in the RTOS system, and changing the Cache line states corresponding to the RTOS system and the IVI system into S.
Step S42: if the first operating system stores the copy of the first data and the copy of the first data is inconsistent with the data in the corresponding physical memory, the copy of the first data is written into the corresponding physical memory unit, and then the copy of the first data in the corresponding physical memory unit is written into a cache unit of the second operating system.
If the CPU in the IVI system finds a local copy and the state is M, the content in the Cache line is updated into a physical memory unit, at this time, the state of the Cache line in the IVI system is changed from M to S, and at this time, the RTOS system needs to acquire first data from the physical memory unit.
Step S22: and when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system.
In the prior art, the flag indicating that the write of the shared data is completed is the cache completion, but the present embodiment performs self-maintenance by using a cache coherency mechanism, so the flag indicating that the write of the shared data is completed is the write operation (for example, memcpy, memset, etc.) of the software.
When the first data write of the IVI system is completed, a sharing notification may be sent to the RTOS system by way of a Software Generated Interrupt (SGI).
Traditional heterogeneous systems need additional hardware to support interrupt control among different CPUs, and for a scheme of realizing virtualization under a homogeneous system, communication among operating systems is more complicated in software implementation. The embodiment is based on an inter-core communication mechanism, and realizes a message transmission mode among different operating systems. By taking the ARM as an example, interrupt notification among operating systems can be realized in an SGI mode, external docking hardware is not needed, and meanwhile, the communication mode is more convenient.
Step S23: and the second operating system receives the sharing notice and acquires the first data from the cache unit.
And the RTOS system receives the sharing notice and acquires the first data from the corresponding cache unit.
In the prior art, when an IVI system needs to share data to an RTOS system, the IVI system needs to write the data into a shared physical memory unit first; and after the data of the IVI system is written, reading the data in the shared physical memory unit by the RTOS system. In contrast to the conventional multisystem communication scheme in the industry, the operation flow is roughly shown in fig. 5, and the corresponding data flow is shown in fig. 6.
In the prior art, in order to eliminate the interference of the cache between the IVI system and the RTOS system and ensure the accuracy of data, there are two methods in the IVI system of the data sender: and if the corresponding data receiver RTOS system does not close the cache unit of the corresponding region, the cache of the RTOS system is emptied before trying to receive the data, and then the data is acquired from the shared physical memory unit. If the IVI system does not perform the Cache flushing operation, the problem of data inconsistency can occur: the IVI system finishes writing data, but part of the data still exists in a Cache line and is not written into the shared physical memory unit, and at the moment, the data directly acquired from the shared physical memory unit by the RTOS system is old; if the RTOS system does not do the operation of clearing the Cache, the problem of inconsistent data can also occur: the IVI system finishes writing data and completely brushes the data into the shared physical memory unit, at the moment, the RTOS system directly reads the data, because of the existence of the Cache, if the current RTOS system backups the data of the corresponding address in the Cache line (namely, CPU read operation), the RTOS system directly reads the old data from the Cache line of the RTOS system when reading again, and the new data can not be obtained from the shared physical memory unit again. Although the two problems are avoided, the overall transmission efficiency of data is undoubtedly affected, and the complexity and time delay of software are increased to some extent by the active refreshing and buffer clearing method.
In the present embodiment, when the IVI system needs to synchronize data to the RTOS system, the operation flow is as shown in fig. 7, and the corresponding data flow is as shown in fig. 8. The embodiment can solve the problems by utilizing a Cache consistency mechanism, does not need to actively operate a Cache unit when data synchronization operation is carried out, does not need to care about Cache flushing operation of a write operation party or Cache clearing operation of a read operation party, and improves the data transmission rate due to the existence of the Cache unit.
The present application further provides a communication method based on a multi-operating system with homogeneous multiple cores according to another embodiment, which is used for the above multi-operating system based on homogeneous multiple cores. 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 according to the present application. The embodiment specifically comprises the following steps:
step S91: and configuring a shared physical memory unit for the first operating system and the second operating system.
The method includes configuring a first exclusive physical memory unit for a first operating system, configuring a second exclusive physical memory unit for a second system, and configuring a shared physical memory unit for the first operating system and the second operating system.
The effect of the shared physical memory unit on cache consistency includes: as an intermediate bridge for address coincidence 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 (which facilitates that each operating system can independently access the shared physical memory unit in a non-cache consistency, i.e. non-communication state), and thus the virtual addresses are mapped to the shared physical memory unit respectively, and the two virtual addresses are consistent; in the case of cache coherency, the shared physical memory provides a real physical address as an intermediate mapping of addresses of the cache locations of the two operating systems. After the data of the cache unit is fully written, when the data is written, the existing data of the cache unit needs to be carried to the shared physical memory unit, and at this time, the shared physical memory unit is equivalent to a garbage can of the cache unit.
Step S92: 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 by MMU mapping.
The virtual addresses of a part of cache units of the first operating system are mapped to a first exclusive physical memory unit and the virtual addresses of a part of cache units of the second operating system are mapped to a second exclusive physical memory unit through MMU mapping, and the virtual addresses of the other part of cache units of the first operating system and the virtual addresses of the other part of cache units of the second operating system are mapped to a shared physical memory unit through MMU mapping.
The IVI system and the RTOS system realize cache consistency through a shared physical memory unit of the IVI system and the RTOS system.
Because the IVI system and the RTOS system are homogeneous systems, the two operating systems can access the exact same physical memory unit, i.e., share the physical memory unit. Therefore, in order to prevent the memory data from being affected by each other between the two operating systems, MMU mapping is additionally configured for memory isolation, that is, the virtual addresses of the partial cache unit of the IVI system are mapped to the first exclusive physical memory unit of the IVI system and the virtual addresses of the partial cache unit of the RTOS system are mapped to the second exclusive physical memory unit of the RTOS system and the same physical addresses of the multiple operating systems, that is, mapped to the physical memory unit, through the Stage2 mapping of the MMU mapping; in order to reduce the time for data transfer between the IVI system and the RTOS system, a segment of shared physical memory unit is required for data synchronization between multiple operating systems, and in case that both the IVI system and the RTOS system can access the segment, 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 are mapped to the shared physical memory unit by the Stage2 mapping mapped by the MMU.
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 the multiple operating systems, i.e. to the shared physical memory unit, by MMU mapping.
The data caching mode of the multiple operating systems comprises the following steps: VIVT, VIPT or PIPT.
In particular, the VIVT (Virtual Index Virtual tag) is a tag field that uses a Virtual address Index field and a Virtual address; VIPT (virtual Index Physical tag) is a tag that uses the Index field of a virtual address and a Physical address; PIPT (Physical Index Physical tag) is an Index field using a Physical address and a tag field using a Physical address.
Step S93: and setting different marks for the virtual address space of the first operating system and the virtual address space of the second operating system respectively in response to the VIVT.
In response to the VIVT, the same mapping relationship is configured for the Stage1 mapping of the MMU mapping of the first operating system and the second operating system to the shared physical memory unit, and different flags are set for the virtual address space of the first operating system and the virtual address space of the second operating system respectively.
When the data caching mode (i.e. the relationship between the cache unit and the memory unit) is VIPT and PIPT, the position in the cache is strongly correlated with the physical address, so that the cache consistency maintenance can be designed to be consistent based on the physical address, no additional requirement is required for the mapping mode of multiple operating systems, only the same physical address is used when data is shared, and the cache consistency is maintained by the SCU when two operating systems operate the virtual address corresponding to the same physical address.
When the data caching mode is VIVT, the first operating system and the second operating system need to configure the same mapping relationship for Stage1 mapping of the shared memory region, so that the cache consistency can be ensured.
Further, when the data caching method is VIVT, it may cause a problem of caching aliases, that is, multiple identical virtual addresses may be mapped to the same physical address; for example, inter-process communication, which results in the caches of virtual addresses pointing to the same physical address being stored separately, may create coherency problems, such as a cache line of a virtual address being changed, and the cache of a virtual address pointing to the same physical address not being changed, resulting in data inconsistencies. For this case, the present embodiment distinguishes different virtual address spaces by adding a tag (ASID) to each virtual address space.
Step S94: the first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism.
And monitoring the writing operation of the first data, and updating the first data into a cache unit of the second operating system by the first operating system through a cache consistency mechanism.
Step S95: and when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system.
Step S96: and the second operating system receives the sharing notice and acquires the data from the cache unit.
Steps S94 to S96 are similar to steps S11 to S13, and are not repeated here.
The present application further provides a communication method based on a multi-operating system with homogeneous multiple cores according to another embodiment, which is used for the above multi-operating system based on homogeneous multiple cores. 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 according to the present application.
The embodiment specifically comprises the following steps:
step S101: and when the first data writing operation is monitored, the first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism.
Step S102: and when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system.
Step S103: and the second operating system receives the sharing notice and acquires the data from the cache unit.
Steps S101 to S103 are similar to steps S11 to S13, and are not repeated here.
Step S104: monitoring that the first operating system and the second operating system commonly access the same shared physical memory unit, monitoring that the first operating system or the second operating system applies for spin lock, and creating a variable in the shared physical memory unit to store current data of the same shared physical memory unit.
Step S105: and locally monitoring the multiple operating systems, and writing the current data into the same shared physical memory unit after the exclusive ownership of the same shared physical memory unit is finished.
In this embodiment, when a resource (shared physical memory unit) in a multi-operating system is accessed by cores of multiple operating systems together, for example, during read-write operation, the multi-operating system needs to protect the resource; in this embodiment, the same spin lock driver is added in the first operating system and the second operating system, and the first operating system and the second operating system are required to apply for a lock through the spin lock driver when applying for protection of a shared resource, and addresses of shared physical memory units occupied by the applied spin lock are the same (based on implementation of VIPT and PIPT). In order to realize Exclusive access of the memory, the ARM processor provides an independent hardware module, namely an Exclusive Monitor (Exclusive Monitor), to support the function, and in the embodiment, a more convenient spin lock mechanism can be realized only by the local Monitor, and meanwhile, the monitoring of an external bus is saved, and the control transfer time is optimized.
To keep data synchronization in the case of multithreading, operations called Load-link (LL) and Store-conditional (sc) need to be introduced and variables are created in a shared physical memory unit, the LL operation stores the current data in the shared physical memory unit to be accessed in the variables and marks the shared physical memory unit as exclusive; and SC operation, after the accessed shared physical memory unit is occupied, writing the current data in the variable back to the shared physical memory unit, and canceling the exclusive mark. For the ARM platform, support for LL/SC is also provided at the hardware level, and in the case of Cortex-a53, LL operation is LDREX instruction and SC operation is STREX instruction.
Further, in other embodiments, the management and control of memory access may be monitored by adding hardware firewall, where the minimum unit that the hardware firewall can monitor needs to be provided to each core. Therefore, even if the MMU of the system has problems, the memory conflict of the system can be isolated from the hardware so as to ensure the independence of the system.
Further, due to the swap-out mechanism of the cache, the process optimization of the assembly level can be added to the part of the shared data, so as to reduce the high time delay caused by the data swap-in and swap-out.
Further, considering the above process based on the ARM-series CPU, there may be different cache coherence mechanisms and hardware modules for CPUs with other architectures, which require targeted implementation of relevant software.
The present application further provides a chip, where the chip runs a multi-operating system, the multi-operating system at least includes 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 a same processor, where the processor implements multi-communication system communication by using the communication method based on the multi-operating system with homogeneous multi-cores in the foregoing embodiment.
Different from the prior art, 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 positioned in different kernels of the same processor, the first operating system updates first data to a cache unit of the second operating system through a cache consistency mechanism, and after the first data writing operation is completed, the second operating system is informed to directly obtain the first data from the cache unit of the second operating system; therefore, when the first operating system synchronizes the first data to the second operating system, the first operating system does not need to store the first data in the cache unit of the first operating system in the physical memory, and the second operating system does not need to empty the data in the cache unit of the second operating system, but directly reads the first data from the cache unit of the second operating system after receiving the sharing notification of the first operating system, so that the efficiency of data synchronization between the operating systems can be improved.
Furthermore, based on a cache consistency mechanism, data transmission between cores of different operating systems is more freely synchronized without excessive participation of software; the memory isolation technology is added, the shared memory and the non-shared memory are definite, and the mutual influence among multiple operating systems is reduced; a plurality of operating systems adopt a unified spin lock drive, and a more convenient protection mechanism is provided for accessing critical resources among the operating systems.
The above description is only for the purpose of illustrating embodiments of the present application and is not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application or are directly or indirectly applied to other related technical fields, are also included in the scope of the present application.
Claims (10)
1. A communication method based on a multi-operating system with homogeneous multi-core is characterized in that the multi-operating system at least comprises 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 communication method comprises the following steps:
monitoring a first data writing operation, and updating the first data into a cache unit of the second operating system by the first operating system through a cache consistency mechanism;
when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to the second operating system;
and the second operating system receives the sharing notice and acquires the first data from the cache unit.
2. The communication method according to claim 1, wherein the first operating system updates the first data to 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;
and 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.
3. The communication method according to claim 1, wherein the first operating system updates the first data into the second operating system cache unit through a cache coherency mechanism, further comprising:
if the cache unit of the second operating system stores second data, modifying 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;
and if the second operating system has a copy of the second data, updating the data to a cache unit of the second operating system based on the storage condition of the first operating system on the first data.
4. The communication method according to claim 3, wherein the updating the data into the cache unit of the second operating system based on the storage condition of the first operating system for the first data comprises:
and if the first operating system stores the copy of the first data and the copy of the first data is consistent with the data in the corresponding physical memory unit, directly writing the copy of the first data into a cache unit of the second operating system.
5. The communication method according to claim 3, wherein the updating the first data into the cache unit of the second operating system based on the storage condition of the first operating system for the first data further comprises:
if the first operating system stores the copy of the first data and the copy of the first data is inconsistent with the data in the corresponding physical memory, writing 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 a cache unit of the second operating system.
6. 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;
mapping 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.
7. The communication method according to claim 6, wherein the data caching manner of the multiple operating systems comprises: a VIVT, VIPT, or PIPT, the communication method further comprising:
and setting different marks for the virtual address space of the first operating system and the virtual address space of the second operating system respectively in response to the data caching mode being the VIVT.
8. The communication method of claim 1, wherein monitoring that the data write operation is complete, the first operating system sending a sharing notification to the second operating system comprises:
and when the first data writing operation is monitored to be completed, the first operating system sends a sharing notice to a second operating system by using an inter-core interrupt mode.
9. A multi-operating system based on homogeneous multi-core is characterized by at least comprising: the first operating system monitors a first data write operation, and updates the first data to a cache unit of the second operating system through a cache consistency mechanism; when monitoring that the first data writing operation is completed, the first operating system sends a sharing notice to the second operating system; and the second operating system receives the sharing notice and acquires the first data from the cache unit.
10. A chip, wherein a multi-operating system based on homogeneous multi-core is run, 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 different cores of a same 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 to 8.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111476557.9A CN114416387A (en) | 2021-12-06 | 2021-12-06 | Multi-operating system based on isomorphic multi-core, communication method and chip |
| PCT/CN2022/133538 WO2023103767A1 (en) | 2021-12-06 | 2022-11-22 | Homogeneous multi-core-based multi-operating system, communication method, and chip |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111476557.9A CN114416387A (en) | 2021-12-06 | 2021-12-06 | Multi-operating system based on isomorphic multi-core, communication method and chip |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114416387A true CN114416387A (en) | 2022-04-29 |
Family
ID=81265791
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111476557.9A Pending CN114416387A (en) | 2021-12-06 | 2021-12-06 | Multi-operating system based on isomorphic multi-core, communication method and chip |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN114416387A (en) |
| WO (1) | WO2023103767A1 (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115840650A (en) * | 2023-02-20 | 2023-03-24 | 麒麟软件有限公司 | Method for realizing three-terminal system communication based on kvisor isolation real-time domain |
| CN115933494A (en) * | 2022-12-28 | 2023-04-07 | 睿尔曼智能科技（北京）有限公司 | Robot-oriented embedded isomorphic multi-core control system |
| CN116243995A (en) * | 2023-05-12 | 2023-06-09 | 苏州浪潮智能科技有限公司 | Communication method, communication device, computer readable storage medium, and electronic apparatus |
| WO2023103767A1 (en) * | 2021-12-06 | 2023-06-15 | 合肥杰发科技有限公司 | Homogeneous multi-core-based multi-operating system, communication method, and chip |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7475190B2 (en) * | 2004-10-08 | 2009-01-06 | International Business Machines Corporation | Direct access of cache lock set data without backing memory |
| CN101477511B (en) * | 2008-12-31 | 2010-08-25 | 杭州华三通信技术有限公司 | Method and apparatus for sharing memory medium between multiple operating systems |
| US20120110303A1 (en) * | 2010-10-28 | 2012-05-03 | International Business Machines Corporation | Method for Process Synchronization of Embedded Applications in Multi-Core Systems |
| CN105740164B (en) * | 2014-12-10 | 2020-03-17 | 阿里巴巴集团控股有限公司 | Multi-core processor supporting cache consistency, reading and writing method, device and equipment |
| US10860487B2 (en) * | 2019-04-17 | 2020-12-08 | Chengdu Haiguang Integrated Circuit Design Co. Ltd. | Multi-core processing device and method of transferring data between cores thereof |
| CN112416615A (en) * | 2020-11-05 | 2021-02-26 | 珠海格力电器股份有限公司 | Multi-core processor, method and device for realizing cache consistency of multi-core processor and storage medium |
| CN114416387A (en) * | 2021-12-06 | 2022-04-29 | 合肥杰发科技有限公司 | Multi-operating system based on isomorphic multi-core, communication method and chip |
-
2021
- 2021-12-06 CN CN202111476557.9A patent/CN114416387A/en active Pending
-
2022
- 2022-11-22 WO PCT/CN2022/133538 patent/WO2023103767A1/en unknown
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023103767A1 (en) * | 2021-12-06 | 2023-06-15 | 合肥杰发科技有限公司 | Homogeneous multi-core-based multi-operating system, communication method, and chip |
| CN115933494A (en) * | 2022-12-28 | 2023-04-07 | 睿尔曼智能科技（北京）有限公司 | Robot-oriented embedded isomorphic multi-core control system |
| CN115933494B (en) * | 2022-12-28 | 2023-11-07 | 睿尔曼智能科技（北京）有限公司 | Robot-oriented embedded isomorphic multi-core control system |
| CN115840650A (en) * | 2023-02-20 | 2023-03-24 | 麒麟软件有限公司 | Method for realizing three-terminal system communication based on kvisor isolation real-time domain |
| CN115840650B (en) * | 2023-02-20 | 2023-06-02 | 麒麟软件有限公司 | Method for realizing three-terminal system communication based on kvisor isolated real-time domain |
| CN116243995A (en) * | 2023-05-12 | 2023-06-09 | 苏州浪潮智能科技有限公司 | Communication method, communication device, computer readable storage medium, and electronic apparatus |
| CN116243995B (en) * | 2023-05-12 | 2023-08-04 | 苏州浪潮智能科技有限公司 | Communication method, communication device, computer readable storage medium, and electronic apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023103767A1 (en) | 2023-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11893653B2 (en) | Unified memory systems and methods | |
| CN114416387A (en) | Multi-operating system based on isomorphic multi-core, communication method and chip | |
| US10552337B2 (en) | Memory management and device | |
| JP5153172B2 (en) | Method and system for maintaining low cost cache coherency for accelerators | |
| JP4123621B2 (en) | Main memory shared multiprocessor system and shared area setting method thereof | |
| US7657710B2 (en) | Cache coherence protocol with write-only permission | |
| US20160077976A1 (en) | Address translation services for direct accessing of local memory over a network fabric | |
| CN102929832B (en) | Cache-coherence multi-core processor data transmission system based on no-write allocation | |
| JP3264319B2 (en) | Bus bridge | |
| US20070162641A1 (en) | Method and apparatus for utilizing platform support for direct memory access remapping by remote DMA ("RDMA")-capable devices | |
| US20200334153A1 (en) | Multi-Core Processing Device and Method of Transfering Data Between Cores Thereof | |
| JPH06243035A (en) | Generalized shared memory in cluster architecture for computer system | |
| US9208088B2 (en) | Shared virtual memory management apparatus for providing cache-coherence | |
| US20130227219A1 (en) | Processor, information processing apparatus, and arithmetic method | |
| JP2002157164A (en) | Data consistency memory management system and method and related multiprocessor network | |
| US20040128452A1 (en) | Allocating cache lines | |
| US8095617B2 (en) | Caching data in a cluster computing system which avoids false-sharing conflicts | |
| US20020013886A1 (en) | Multiprocessor system | |
| US20140006716A1 (en) | Data control using last accessor information | |
| KR101442643B1 (en) | The Cooperation System and the Method between CPU and GPU | |
| CN110737407A (en) | data buffer memory realizing method supporting mixed writing strategy | |
| US8627016B2 (en) | Maintaining data coherence by using data domains | |
| US20120151153A1 (en) | Programmable Controller | |
| CN112416259B (en) | Data access method and data access device | |
| WO2022246769A1 (en) | Data access method and apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |