Multi-operating system and communication method and chip based on homogeneous multi-core

Abstract

The application provides a multi-operation system based on an isomorphic multi-core, a communication method thereof and a chip. The multi-operation system comprises at least a first operation system and a second operation system, and the first operation system and the second operation system are located in different cores of the same processor. The communication method comprises the following steps: monitoring a first data write operation; updating the first data to a cache unit of the second operation system by the first operation system through a cache consistency mechanism; monitoring that the first data write operation is completed; sending a shared notification to the second operation system by the first operation system; and obtaining the first data from the cache unit by the second operation system after receiving the shared notification. In this way, the efficiency of data synchronization between operation systems can be improved.

Description

Technical Field

[0001] The present application relates to the field of multi-system communication technology, and in particular to a multi-operating system and communication method and chip based on homogeneous multi-core. Background Art

[0002] Currently, the "single-chip, multiple-system" solution is becoming increasingly popular in vehicle computers. Complex tasks often require the coordination and cooperation of multiple operating systems, and this inter-system cooperation requires a good data communication mechanism.

[0003] The current mainstream single-chip multi-system solutions in car computers include software virtualization solutions (Hypervisor) and hardware chip isolation solutions (in the case of heterogeneous multi-systems). Different operating systems are responsible for different tasks. For software virtualization solutions, its general implementation is to design a layer of software at the CPU EL2 (Exception Level), and the EL2 software is responsible for managing data sharing and synchronization. For heterogeneous multi-system solutions, hardware IPC combined with shared memory technology is usually used. However, the data synchronization efficiency between systems of these two solutions is low. Summary of the Invention

[0004] The main technical problem solved by this application is to provide a multi-operating system based on homogeneous multi-core and its data synchronization method and chip to improve the efficiency of data synchronization between operating systems.

[0005] To solve the above technical problems, the present application provides a communication method for multiple operating systems based on homogeneous multi-core. 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 being located in different cores of the same processor. The communication method includes: upon detecting a first data write operation, the first operating system updates the first data to the cache unit of the second operating system through a cache consistency mechanism; upon detecting completion of the first data write operation, the first operating system sends a sharing notification to the second operating system; and upon receiving the sharing notification, the second operating system retrieves the first data from the cache unit.

[0006] 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 homogeneous multi-core includes at least: 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 first operating system detects a first data write operation and updates the first data to the cache unit of the second operating system through a cache consistency mechanism; the first operating system detects the completion of the first data write operation and sends a sharing notification to the second operating system; the second operating system receives the sharing notification and retrieves the first data from the cache unit.

[0007] To solve the above technical problems, the application provides a chip. The chip runs multiple operating systems based on a homogeneous multi-core, and the multiple operating systems at least include 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 implements multiple communication systems by using the communication method based on the multiple operating systems of the homogeneous multi-core.

[0008] Compared with the prior art, the application has the beneficial effects that the multiple operating systems at least include the first operating system and the second operating system, and the first operating system and the second operating system are located in different cores of the same processor. The first operating system updates the first data to the cache unit of the second operating system through the cache consistency mechanism, and after the first data write operation is completed, the second operating system is notified to directly obtain the first data from the cache unit. 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 physical memory, and the second operating system does not need to clear the data in the cache unit, but directly reads the first data from the cache unit after receiving the sharing notification of the first operating system. Therefore, the efficiency of data synchronization between operating systems can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 FIG. 1 is a structural schematic diagram of an embodiment of the multiple operating systems based on the homogeneous multi-core of the application;

[0010] Figure 2 FIG. 2 is a flow schematic diagram of an embodiment of the communication method of the multiple operating systems based on the homogeneous multi-core of the application;

[0011] Figure 3 FIG. 3 is a flow schematic diagram of the data synchronization of the first operating system and the second operating system in the embodiment of the application; Figure 2 FIG. 4 is a specific flow schematic diagram of step S21 in the embodiment;

[0012] Figure 4 FIG. 5 is a specific flow schematic diagram of step S35 in the embodiment; Figure 2 FIG. 6 is a flow schematic diagram of the data synchronization of the prior art;

[0013] Figure 5 FIG. 7 is a flow schematic diagram of the data synchronization of the embodiment of the application;

[0014] Figure 6 FIG. 8 is a schematic diagram of the data flow of the embodiment of the application; Figure 5

[0015] FIG. 9 is a schematic diagram of the data flow of the embodiment of the application; Figure 7 Figure 2 FIG. 10 is a schematic diagram of the data synchronization of the embodiment of the application;

[0016] Figure 8 Figure 7 FIG. 11 is a schematic diagram of the data flow of the embodiment of the application;

[0017] ​​Figure 9 is a flowchart of an embodiment of a communication method of a multi-operating system based on a homogeneous multi-core according to the present application;

[0018] Figure 10 is a flowchart of an embodiment of a communication method of a multi-operating system based on a homogeneous multi-core according to the present application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0020] The single-chip multi-system solution is currently mainstream on the car machine, such as a software virtualization solution (Hypervisor) and a hardware chip isolation solution (heterogeneous multi-system solution). Different operating systems are responsible for different task contents. For the software virtualization solution, a layer of software is designed at the CPU EL2 (Exception Level), and the software at the EL2 is uniformly responsible for managing the sharing and synchronization of data. For the heterogeneous multi-system solution, the hardware IPC is usually combined with the shared memory technology to achieve the solution. However, the data synchronization efficiency between the systems of the two solutions is low.

[0021] The communication between the heterogeneous systems needs to increase external hardware to trigger an interrupt, while the homogeneous multi-cores between the homogeneous systems can trigger an interrupt faster. The cache between the heterogeneous systems is usually not shared, so consistency cannot be guaranteed, which leads to a long process of data transmission between the systems, that is, writing to the cache + flushing to the memory and emptying the cache + reading from the memory, which affects the data synchronization efficiency.

[0022] To solve the above problems, the present application first proposes a multi-operating system based on a homogeneous multi-core, such as Figure 1 as shown, Figure 1This is a structural diagram of an embodiment of a multi-operating system based on homogeneous multi-core of the present application. The multi-operating system based on homogeneous multi-core of this embodiment (not shown in the figure) 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. Among them, the first operating system 10 detects the first data write operation (the operation of writing to 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; the first operating system 10 detects the completion of the first data write operation 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.

[0023] 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 does not need to clear the data in its cache unit 21. Instead, the second operating system 20 directly reads the first data from its cache unit 21 after receiving the sharing notification from the first operating system 10. Therefore, the efficiency of data synchronization between operating systems can be improved.

[0024] The homogeneous multi-core multi-operating systems in this embodiment and the following embodiments are described using an ARM processor (quad-core CortexA53) as an example. The first operating system 10 is an IVI system for audio and video entertainment, and the second operating system is an RTOS system for instrumentation.

[0025] Using an ARM Cortex A53 (quad-core), the system manages both the RTOS and the IVI systems on the vehicle platform. When the IVI system attempts to transmit phone information, map information, music playlist information, and other information to the RTOS for display on the instrument panel, this embodiment enables efficient data synchronization.

[0026] Among them, the IVI system configuration uses three cores, Core 0-Core2, to run the Android system. The RTOS system tasks are relatively simple, so the configuration uses one core, Core3, 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 units. Therefore, in order to prevent the two operating systems from influencing each other on memory data, it is necessary to additionally configure MMU mapping to perform memory isolation, that is, to map the virtual addresses of some cache units 11 of the IVI system to the exclusive physical memory units of the IVI system and to map the virtual addresses of some cache units 21 of the RTOS system to the exclusive physical memory units of the RTOS system through the Stage2 mapping of the MMU mapping. In order to reduce the time for data transmission between the IVI system and the RTOS system, data synchronization between multiple operating systems requires a shared physical memory for situations where both the IVI system and the RTOS system can access it; and to map the virtual addresses of another part of the cache units of the IVI system and the virtual addresses of another part of the cache units of the RTOS system to the shared physical memory units through the Stage2 mapping of the MMU mapping.

[0027] The MMU mapping is controlled by the processor and is responsible for translating cache units' virtual addresses into physical addresses. This translation process is divided into two stages: Stage 1, which converts the input VA (virtual address) into a PA (physical address) or an IPA (corrected virtual address) output; and Stage 2, which converts the IPA into a PA. Alternatively, a combination of Stage 1 and Stage 2 can convert the input VA to IPA and then to PA.

[0028] The physical memory of multiple operating systems is divided into three parts, among which the IVI system occupies one physical memory exclusively and the RTOS system occupies another physical memory exclusively. This can reduce the exceptions caused by memory usage between systems. The VI system and the RTOS system use shared physical memory together.

[0029] Among them, the role of the physical memory unit in cache consistency includes: serving as an intermediate bridge to ensure the address consistency between 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; and after the data of the cache unit 11 is full, when writing data, the existing data in the cache unit 11 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 11.

[0030] This embodiment adds the same spinlock driver to the first operating system 10 and the second operating system 20, and requires the first operating system 10 and the second operating system 20 to apply for locks through the spinlock driver when applying for protection of shared resources. The addresses of the shared physical memory units occupied by the applied spinlocks are the same. To achieve exclusive access to memory, a separate hardware module "Exclusive Monitor" is provided to support this function. This embodiment only requires a local monitor to implement a more convenient spinlock mechanism, while eliminating the need for external bus monitoring and optimizing control transfer time.

[0031] Among them, the spin lock driver requires that the first operating system 10 and the second operating system 20 can be allocated on demand when used, and the same lock is used for mutual exclusive access between the first operating system 10 and the second operating system 20, which requires that the lock allocation also needs to be in a shared physical memory unit.

[0032] This application further proposes a communication method for a multi-operating system based on homogeneous multi-core, which is used for the multi-operating system based on homogeneous multi-core. Figure 2 As shown, Figure 2 This is a schematic diagram of an embodiment of a communication method for a multi-operating system based on a homogeneous multi-core system. This embodiment specifically includes the following steps:

[0033] Step S21: 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 consistency mechanism.

[0034] An operation of writing the first data into the cache unit of the first operating system is monitored, and 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 consistency mechanism.

[0035] The cache consistency mechanism is introduced using the MOESI protocol as an example:

[0036] This embodiment uses a cache consistency mechanism to manage data transmission between cores of different operating systems. Its core mechanism is to represent each cache unit (cache line) with a state:

[0037] M (Modify) bit: When M is 1, the data in the current cache line is inconsistent with the data in the physical memory unit. Furthermore, the data in this cache line is valid only in the cache line of this CPU (core) and not in the cache lines of other CPUs. The data in this cache line is the most recent copy of the data in the current operating system. When the CPU replaces this cache line, it inevitably triggers a write cycle on the system bus to synchronize the data in the cache line with the data in the memory.

[0038] E (Exclusive) bit: E is 1 indicates 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 line of other CPUs. The data in the Cache line is the latest data copy in the current operating system, and is consistent with the data in the physical memory unit.

[0039] S (Shared) bit: S is 1 indicates that the data contained in the Cache line is valid, and there is a copy in the current CPU and at least in another CPU. When a Cache line state is S, the data contained therein is not necessarily consistent with the physical memory unit. If there is no copy in the Cache of other CPUs with a state of O, the data in the Cache line is consistent with the memory; if there is a copy in the Cache line of other CPUs with a state of O, the data in the Cache line is inconsistent with the physical memory unit.

[0040] I (Invalid) bit: I is 1 indicates that there is no valid data in the current Cache line or the Cache line is not enabled. The MESI protocol will preferentially use the Cache line with I as 1 when replacing the Cache line.

[0041] O (Owned) bit: O is 1 indicates that the data contained in the current Cache line is the latest data copy in the current operating system, and there is a copy of the Cache line in other CPUs, and the Cache line state of other CPUs is S. If the data of the physical memory unit has a copy in the Cache line of multiple CPUs, only one CPU has a Cache line state of O, and the Cache line state of other CPUs can only be S. Unlike the S state in the MESI protocol, the data in the Cache line with a state of O is not consistent with the data in the physical memory unit.

[0042] The ARM processor monitors and maintains the cache consistency between the cores through the Snoop Control Unit (SCU), and also provides arbitrated access to the L2 Cache. Generally, each core in an SMP system has a register for controlling the switch of the cache consistency unit. Taking the Cortex A53 of ARM as an example, if the register CPUECTLR.smp bit is set, the SCU is started. The embodiment utilizes the SCU combined with the MOESI protocol to maintain the consistency of the data in the cache unit in a timely manner, and ensures the accuracy of the data obtained between the cores, and these operations do not require the participation of software, thereby improving the maintainability of the software.

[0043] When the cache unit in the system is filled, if a new cache unit needs to be filled, a cacheEvict operation needs to be performed, which is completed by hardware.

[0044] When the IVI system writes data to the cache, the SCU can monitor changes in the cache line status of the corresponding physical memory unit in the IVI system and can actively perform cache consistency maintenance.

[0045] Alternatively, one can Figure 3 The method shown implements step S21. The method of this embodiment includes steps S30 to S35.

[0046] Step S30: a first data write operation is detected.

[0047] An operation of writing first data into a cache unit of a first operating system is monitored.

[0048] Step S31: The first operating system writes the first data into the cache unit of the first operating system.

[0049] The first operating system writes the first data into a corresponding cache line in the first operating system.

[0050] 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.

[0051] The data in 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.

[0052] 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.

[0053] Step S33: If the cache unit of the second operating system stores the second data, the state of the cache unit of the second operating system is marked as invalid.

[0054] If the corresponding cache line in the RTOS system already stores the second data, the state of the corresponding cache line in the RTOS system is modified to I (Invalid).

[0055] Step S34: Determine whether the second operating system has a copy of the second data.

[0056] When the RTOS system starts to receive data, it does not need to clear the cache, 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 their own cache has a copy of the second data.

[0057] Step S35: If the second operating system has a copy of the second data, the first data is updated into the cache unit of the second operating system based on the storage of the first data in the first operating system.

[0058] If the copy of the second data is cached in the RTOS system, the first data synchronized from the IVI system is written into the Cache line in the RTOS system where the second data is stored, and the second data will not be lost. At this time, the first data can be updated into the Cache line in the RTOS system based on the storage of the first data in the IVI system.

[0059] Alternatively, the step S35 can be implemented by the method as shown in Figure 4 The method of the present embodiment includes steps S41 and S42.

[0060] 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, the copy of the first data is directly written into the cache unit of the second operating system.

[0061] If the CPU in the IVI system finds the local copy, and the state is S, the first data in the Cache line is directly flushed to the Cache line in the RTOS system, and at this time, the state of the corresponding Cache line in the RTOS system is changed to S.

[0062] If the CPU in the IVI system finds the local copy, and the state is E, the first data in the Cache line is directly flushed to the Cache line in the RTOS system, and at this time, the states of the corresponding Cache lines in the RTOS system and the IVI system are both changed to S.

[0063] 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, the copy of the first data is first written into the corresponding physical memory unit, and then the copy of the first data in the corresponding physical memory unit is written into the cache unit of the second operating system.

[0064] If the CPU in the IVI system finds the local copy, and the state is M, the content in the Cache line is first updated to the 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 obtain the first data from the physical memory unit.

[0065] Step S22: After the first data write operation is monitored to be completed, the first operating system sends a shared notification to the second operating system.

[0066] In the prior art, the flag of the shared data write completion is cache flush completion, and the embodiment utilizes the cache consistency mechanism to maintain itself, so the flag of the shared data write completion is the software write operation (for example, memcpy, memset, etc.).

[0067] When the first data write of the IVI system is completed, the shared notification can be sent to the RTOS system through the inter-core interrupt (Software Generate Interrupt, SGI) mode.

[0068] The traditional heterogeneous system needs additional hardware to support the interrupt control between different CPUs, and for the virtualization scheme under the homogeneous system, the communication between the operating systems is more complex in the software implementation. The embodiment realizes the message passing mode between different operating systems based on the inter-core communication mechanism. Taking ARM as an example, the interrupt notification between the operating systems can be realized through the SGI mode, without the need of external interfacing hardware, and the communication mode is more convenient.

[0069] Step S23: The second operating system receives the shared notification and obtains the first data from the cache unit.

[0070] The RTOS system receives the shared notification and obtains the first data from the corresponding cache unit.

[0071] 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 into the shared physical memory unit; after the data write of the IVI system is completed, the data in the shared physical memory unit is read by the RTOS system. Compared with the commonly used multi-system communication scheme in the industry, the operation process is roughly as shown in Figure 5 , and the corresponding data flow is as shown in Figure 6 .

[0072] In the prior art, in order to eliminate cache interference between the IVI system and the RTOS system and ensure data accuracy, the IVI system sending data usually has two methods: closing the cache unit of the corresponding area or actively refreshing the cache after each data write is completed. If the corresponding RTOS system receiving data does not close the cache unit of the corresponding area, it will first clear the RTOS system's cache before attempting to receive data and then obtain data from the shared physical memory unit. If the IVI system does not flush the cache, data inconsistency will occur: the IVI system writes the data, but some of the data still exists in the cache line and has not yet been written to the shared physical memory unit. At this time, the data directly obtained by the RTOS system from the shared physical memory unit is stale. If the RTOS system does not clear the cache, data inconsistency will also occur: the IVI system writes the data and completely flushes the data to the shared physical memory unit. At this time, the RTOS system directly reads the data. Because of the 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 when the RTOS system reads again, it will directly read the old data from its own cache line instead of re-obtaining new data from the shared physical memory unit. Although disabling the cache avoids the above two problems, it undoubtedly affects the overall data transmission efficiency. Actively refreshing and clearing the cache also increases the complexity and latency of the software to a certain extent.

[0073] In this embodiment, when the IVI system needs to synchronize data to the RTOS system, the operation process is as follows: Figure 7 As shown, the corresponding data flow is as follows Figure 8 This embodiment utilizes a cache consistency mechanism to solve the above problem. When performing data synchronization operations, there is no need to actively operate the cache unit. Neither the write operation side's cache flushing operation nor the read operation side's cache clearing operation needs to be taken into consideration. At the same time, the existence of the cache unit also improves the data transmission rate.

[0074] This application further proposes another embodiment of a communication method for a multi-operating system based on homogeneous multi-core, which is used for the multi-operating system based on homogeneous multi-core. Figure 9 As shown, Figure 9 This is a schematic diagram of an embodiment of a communication method for a multi-operating system based on a homogeneous multi-core system. This embodiment specifically includes the following steps:

[0075] Step S91: configuring a shared physical memory unit for the first operating system and the second operating system.

[0076] A first exclusive physical memory unit is configured for the first operating system, a second exclusive physical memory unit is configured for the second system, and a shared physical memory unit is configured for the first operating system and the second operating system.

[0077] Among them, the role of shared physical memory unit in cache consistency includes: serving as an intermediate bridge for the address consistency 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 the real physical address (convenient in non-cache consistency, that is, non-communication state, each operating system can access the shared physical memory unit separately), so they are mapped to the shared physical memory unit respectively, and the two virtual addresses are consistent; under the condition of cache consistency, the shared physical memory provides the real physical address as the intermediate mapping of the address of the cache unit 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 garbage can of the cache unit.

[0078] 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 a shared physical memory unit through MMU mapping.

[0079] Through MMU mapping, the virtual addresses of part of the cache units of the first operating system are mapped to the first exclusive physical memory unit and the virtual addresses of part of the cache units of the second operating system are mapped to the second exclusive physical memory unit. Through MMU mapping, the virtual addresses of another part of the cache units of the first operating system and the virtual addresses of another part of the cache units of the second operating system are mapped to the shared physical memory unit.

[0080] The IVI system and the RTOS system achieve cache consistency through their shared physical memory units.

[0081] Since the IVI system and the RTOS system are homogeneous systems, the two operating systems can access the same physical memory unit, i.e., share the physical memory unit. Therefore, in order to prevent mutual influence of memory data between the two operating systems, additional configuration of MMU mapping is required for memory isolation, i.e., mapping the virtual address of a part of the cache unit of the IVI system to the first exclusive physical memory unit of the IVI system and mapping the virtual address of a part of the cache unit of the RTOS system to the second exclusive physical memory unit of the RTOS system through the Stage2 mapping of the MMU mapping, i.e., mapping to the same physical address of the multi-operating system, i.e., mapping to the shared physical memory unit; in order to reduce the data transmission time between the IVI system and the RTOS system, a shared physical memory unit is required for data synchronization between the multi-operating systems, which is used for the case that the IVI system and the RTOS system can access, and 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 through the Stage2 mapping of the MMU mapping.

[0082] i.e., mapping 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 to the same physical address of the multi-operating system, i.e., mapping to the shared physical memory unit through the MMU mapping.

[0083] The data caching mode of the multi-operating system includes VIVT, VIPT, or PIPT.

[0084] Specifically, VIVT (Virtual Index Virtual Tag) uses a virtual address index domain and a virtual address tag domain; VIPT (Virtual Index Physical Tag) uses a virtual address index domain and a physical address tag; and PIPT (Physical Index Physical Tag) uses a physical address index domain and a physical address tag domain.

[0085] Step S93: in response to the data caching mode being VIVT, different tags are set for the virtual address space of the first operating system and the virtual address space of the second operating system, respectively.

[0086] In response to the data caching mode being VIVT, the same mapping relationship is configured for the Stage1 mapping of the MMU mapping of the shared physical memory unit of the first operating system and the second operating system, and different tags are set for the virtual address space of the first operating system and the virtual address space of the second operating system, respectively.

[0087] When the data cache mode (i.e. 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, and thus the cache consistency maintenance can be designed to be based on the physical address consistency. The mapping mode of the multiple operating systems does not need additional requirements, and only needs to use the same physical address when sharing data. When the two operating systems operate the same physical address corresponding to the virtual address, the cache consistency is maintained by the SCU.

[0088] When the data cache mode is VIVT, the Stage1 mapping of the shared memory region by the first operating system and the second operating system needs to be configured to be the same mapping relationship, so as to ensure the cache consistency.

[0089] Further, when the data cache mode is VIVT, it can cause the cache aliasing problem, that is, multiple same virtual addresses can be mapped to the same physical address; for example, inter-process communication, which can cause the cache of the virtual addresses pointing to the same physical address to be stored separately, and thus can cause the consistency problem, such as changing the cache line of a virtual address, and the cache of the virtual address pointing to the same physical address is not changed, resulting in inconsistent data. In view of this situation, the embodiment distinguishes different virtual address spaces by adding a mark (ASID) to each virtual address space.

[0090] Step S94: The first operating system updates the first data to the cache unit of the second operating system through the cache consistency mechanism.

[0091] The first operating system updates the first data to the cache unit of the second operating system through the cache consistency mechanism after monitoring the write operation of the first data.

[0092] Step S95: The first operating system sends a sharing notification to the second operating system after monitoring the completion of the write operation of the first data.

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

[0094] Steps S94 to S96 are similar to steps S11 to S13 described above, and thus are not described herein.

[0095] The application further proposes another embodiment of a communication method of a multiple operating system based on a homogeneous multi-core, which is used for the multiple operating system based on the homogeneous multi-core. Figure 10 As shown in Figure 10 is a structural schematic diagram of an embodiment of the communication method of the multiple operating system based on the homogeneous multi-core.

[0096] The embodiment specifically includes the following steps:

[0097] Step S101: a first data write operation is detected, and the first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism.

[0098] Step S102: After monitoring that the first data write operation is completed, the first operating system sends a sharing notification to the second operating system.

[0099] Step S103: The second operating system receives the sharing notification and obtains data from the cache unit.

[0100] Steps S101 to S103 are similar to the above-mentioned steps S11 to S13 and are not described in detail here.

[0101] Step S104: Detecting that the first operating system and the second operating system jointly access the same shared physical memory unit and detecting a spin lock request by the first operating system or the second operating system, creating a variable in the shared physical memory unit to store current data of the same shared physical memory unit.

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

[0103] In this embodiment, when a certain resource (shared physical memory unit) is accessed by multiple 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 adds the same spin lock driver in the first operating system and the second operating system, and requires the first operating system and the second operating system to apply for a lock through the spin lock driver when applying for protection of the shared resource. The address of the shared physical memory unit occupied by the applied spin lock is 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" to support this function, and this embodiment only requires a local monitor to implement a more convenient spin lock mechanism, while eliminating the need for external bus monitoring and optimizing control transfer time.

[0104] To maintain data synchronization in a multi-threaded environment, operations called Load-Link (LL) and Store-Conditional (SC) need to be introduced, and variables need to be created in shared physical memory units. The LL operation stores the current data in the shared physical memory unit being accessed in the variable and marks the shared physical memory unit as exclusive. The SC operation, after occupying the shared physical memory unit being accessed, writes the current data in the variable back to the shared physical memory unit and cancels the exclusive mark. For the ARM platform, support for LL / SC is also provided at the hardware level. Taking the Cortex-A53 as an example, the LL operation uses the LDREX instruction, and the SC operation uses the STREX instruction.

[0105] Furthermore, in other embodiments, memory access control can be enhanced by adding a hardware firewall for monitoring. The minimum unit that the hardware firewall can monitor is each core. This way, even if there is a problem with the system MMU configuration, the system memory conflict can be isolated from the hardware to ensure system independence.

[0106] Furthermore, since the cache has a swap-out mechanism, assembly-level process optimization can be added to the shared data portion to reduce the high latency caused by data swapping in and out.

[0107] Furthermore, the above process is based on the ARM series CPU. For CPUs of other architectures, there may be different cache consistency mechanisms and hardware modules, and relevant software needs to be implemented in a targeted manner.

[0108] The present application further proposes a chip. The chip of this embodiment runs multiple operating systems, and 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 of multiple operating systems based on homogeneous multi-core in the above embodiment to realize multi-communication system communication.

[0109] Different from the existing technology, 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 updates the first data to the cache unit of the second operating system through the cache consistency mechanism. After the first data write operation is completed, the second operating system is notified to directly obtain the first data from its cache unit; 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 its cache unit into the physical memory, and the second operating system does not need to clear the data in its cache unit. Instead, it can directly read the first data from its cache unit after receiving the sharing notification from the first operating system. Therefore, the efficiency of data synchronization between operating systems can be improved.

[0110] Further, based on the cache consistency mechanism, the transmission of data between the cores of different operating systems is more flexible, without the need for excessive participation of software; the memory isolation technology is increased, the shared memory and the non-shared memory are clearly defined, and the mutual influence between multiple operating systems is reduced; a unified spin lock driver is used for multiple operating systems, and a more convenient protection mechanism is provided for the access to critical resources between multiple operating systems.

[0111] The above is only the embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the specification and drawings of the present application, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A communication method for multiple operating systems based on homogeneous multi-core, characterized in that: 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, and the communication method includes: Upon detecting a first data write operation, the first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism; Upon detecting that the first data write 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 first operating system updates the first data to the cache unit of the second operating system through a cache consistency mechanism, further including: if the cache unit of the second operating system stores the second data, then the state of the cache unit of the second operating system is modified to invalid; determining whether the second operating system has a copy of the second data; if the second operating system has a copy of the second data, then 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, then directly write the copy of the first data into the cache unit of the second operating system; if the second operating system has a copy of the second data, and 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, then first write the copy of the first data into the corresponding physical memory unit, and then write the copy of the first data in the corresponding physical memory unit into the cache unit of the second operating system.

2. The communication method according to claim 1, wherein: The first operating system updates the first data to a cache unit of the second operating system through a cache consistency mechanism, including: 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.

3. The communication method according to claim 1, wherein: Further including: 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.

4. The communication method according to claim 3, wherein: The data caching mode of the multi-operating system includes: VIVT, VIPT or PIPT, and the communication method further includes: In response to the data cache mode being the VIVT, different tags are set for the virtual address space of the first operating system and the virtual address space of the second operating system respectively.

5. The communication method according to claim 1, wherein: Upon detecting that the data write operation is completed, the first operating system sends a sharing notification to the second operating system, including: When it is detected that the first data write operation is completed, the first operating system sends a sharing notification to the second operating system by using an inter-core interrupt.

6. A multi-operating system based on homogeneous multi-core, characterized in that: At least: 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, and the first operating system detects a first data write operation and updates the first data to a cache unit of the second operating system through a cache consistency 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 notification and obtains the first data from the cache unit; The first operating system updates the first data to the cache unit of the second operating system through a cache consistency mechanism, further including: if the cache unit of the second operating system stores the second data, then the state of the cache unit of the second operating system is modified to invalid; determining whether the second operating system has a copy of the second data; if the second operating system has a copy of the second data, then 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, then directly write the copy of the first data into the cache unit of the second operating system; if the second operating system has a copy of the second data, and 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, then first write the copy of the first data into the corresponding physical memory unit, and then write the copy of the first data in the corresponding physical memory unit into the cache unit of the second operating system.

7. A chip, characterized in that: Run a multi-operating system based on homogeneous multi-core, wherein 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 the same processor, wherein the processor adopts the communication method of a multi-operating system based on homogeneous multi-core according to any one of claims 1 to 5 to realize the communication of the multi-operating system.

Images