A memory partition protection method in AMP mode of Sparc V8 multi-core processor

Abstract

The present invention provides a memory partition protection method in the AMP mode of a Sparc V8 multi-core processor. The method partitions the entire memory space of the processor, allocates a memory area to each processor core, and the memory areas do not overlap with each other. A page table is set for each processor core. The effective space accessible to each processor core in the processor may be the same or different. An unexpected jump or forced access to an address inaccessible space will cause the processor to generate an exception. The processor's exception handling mechanism will capture the exception and handle it, preventing unauthorized access from affecting normal data. When a page table error causes a processor core to malfunction, other processor cores can continue to work using their corresponding page tables, thereby achieving partition protection.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded multi-core computer systems, and in particular to a memory partition protection method in a Sparc V8 multi-core processor AMP mode. Background Art

[0002] The Sparc V8 multi-core processor typically operates in either SMP or AMP mode. In SMP mode, a single operating system or application manages all processor cores, creating a unified memory space. In AMP mode, each core has its own independent memory space and runs an independent operating system or application, with minimal information exchange between cores. In AMP mode, each core can run the same or different operating systems or applications, meaning that each core's functional behavior can be identical or distinct.

[0003] The main function of the memory management unit (MMU) in the processor is to map virtual memory addresses to physical memory addresses. For processors without MMU, or processors with MMU but without enabling its mechanism, the mapping of virtual memory addresses to physical memory addresses is one-to-one. In this case, programming for multiple threads or multiple cores requires software designers to plan in advance and manually divide their respective operating spaces during programming. This approach is relatively cumbersome to design, and if you are not careful, it will cause the program space and stack space to be misaligned, and the program spaces of different cores to overlap, resulting in runtime errors. In addition, this approach cannot protect the memory space, that is, it cannot prevent a thread or a processor core from reading and writing the prohibited area or the memory space of other processor cores without permission. In certain circumstances, such an unprotected state will cause data confusion and lead to runtime errors. For example, due to some external factors, program A of processor core 0 generates an incorrect address. It should read data a from address a, but it mistakenly jumps to address b of processor core 1 and reads data b1. Because there is no protection memory partition mechanism, such an operation will not cause the processor to have an exception, but it will cause subsequent processing of program A to fail. If program A writes to address b2, it will also cause subsequent processing of the program of processor core 1 that needs to read data b1 to fail.

[0004] like Figure 1As shown, for MMU-enabled processors, the MMU hardware mechanism, combined with the page tables stored in the memory space, can map virtual memory addresses to physical memory addresses. This allows the processor to run applications larger than the actual physical memory and also to set access permissions for different memory spaces to protect specific memory spaces. Conventional virtual-to-physical address mapping is based on a set of page tables, so all threads or processor cores see the same memory layout and mapping. This approach is relatively simple and suitable for single-core or multi-core SMP modes. However, in multi-core AMP mode, since each core may have different functions, each core or thread may see different valid memory partitions and the overall memory landscape. Therefore, using only a single page table is insufficient to describe the diverse memory partition protection requirements of AMP multi-core mode. Moreover, if external factors cause this page table to be corrupted or inaccessible, tasks on all processor cores cannot execute normally. Therefore, conventional partition protection methods are not suitable for memory partition protection in AMP mode. Summary of the Invention

[0005] In order to overcome the shortcomings and deficiencies of the existing technology, the present invention provides a memory partition protection method in the AMP mode of a Sparc V8 multi-core processor. Different page tables are designed for different processor cores in the Sparc V8 multi-core processor, and the partition protection of the memory space is realized in combination with the processor's MMU.

[0006] The present invention provides a memory partition protection method in the AMP mode of a Sparc V8 multi-core processor, comprising:

[0007] The processor cores of the Sparc V8 multi-core processor are numbered 0, 1, 2, ... n-1, where n is the number of processor cores and the processor core numbered i is referred to as core i;

[0008] A three-level page table is used for memory partition protection, as follows:

[0009] (1) Memory space partitioning

[0010] In the processor's memory space S memory In the example, a suitable program execution space is allocated to each processor core. From the perspective of core i, the spatial distribution of the entire system is:

[0011] A={S memory , S io , S share}={s i , S io , S share}, where A is the entire address space of the processor, S memory is the memory space in A, Smemory [i] is the effective memory address space that core i can see, s i is the program execution space allocated to core i, S io is the system's IO space, S share A shared space for storing global parameters required for processor startup and page tables used for partition protection;

[0012] (2) Create a page table for each single core

[0013] Assume that the size of the level 1 page table is 256 entries. The level 1 page table covers the 4GB space of the Sparc V8 multi-core processor. Each entry of the level 1 page table represents a 16MB subspace.

[0014] Assume that the size of the level 2 page table is 64 entries, the level 2 page table covers a 16MB subspace, and each entry of the level 2 page table represents a 256KB subspace;

[0015] Assume that the size of the level 3 page table is 64 entries, the level 3 page table covers a 256KB subspace, and each entry of the level 3 page table represents a 4KB subspace;

[0016] (3) Setting up the page table

[0017] Level 1 page table processing

[0018] According to the size of the space divided previously, the addresses divided from 0x00000000 to 0xffffffff are processed one by one and inserted into the level 1 page table. The offset in the level 1 page table is determined by the 8 bits [31:24] of the 32-bit virtual address:

[0019] a) If the virtual address space represented by the i-th item in the level 1 page table is free and unused, set the item to all 0s, that is, 0x00000000.

[0020] b) If the virtual address represented by the i-th entry in the level 1 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the i-th entry;

[0021] c) If the virtual address space represented by the i-th item in the level 1 page table cannot be directly mapped to the physical address space, then the starting address of the level 2 page table is ORed with the subsequent mapping code, and the resulting value is written into the i-th item;

[0022] Level 2 page table processing

[0023] The offset in the level 2 page table is determined by bits [23:18] of the 32-bit virtual address:

[0024] a) If the virtual address space represented by the jth item in the level 2 page table is free and unused, set the item to all 0s, that is, 0x00000000;

[0025] b) If the virtual address represented by the jth entry in the level 2 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the jth entry;

[0026] c) If the virtual address space represented by the jth item in the level 2 page table cannot be directly mapped to the physical address space, then the starting address of the level 3 page table is ORed with the subsequent mapping code, and the resulting value is written into the jth item;

[0027] Level 3 page table processing

[0028] The offset in the 3-level page table is determined by 6 bits [17:12] of the 32-bit virtual address, and the 12 bits [11:0] of the virtual address represent the offset within the physical page:

[0029] a) If the virtual address space represented by the kth item in the level 3 page table is free and unused, set the item to all 0s, that is, 0x00000000;

[0030] b) If the virtual address represented by the kth entry in the level 3 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the kth entry;

[0031] (4) Startup page table

[0032] After setting all page tables, set the content of the memory management unit page table pointer register to the starting address of the level 1 page table, flush the level 1 data cache and address cache, flush the page table cache content, and set the last bit of the memory management unit control register to 0x1 to enable the memory management unit;

[0033] (5) Protection takes effect

[0034] After setting up the page table and enabling the memory management unit, the processor core accesses the corresponding physical address by looking up the page table and takes corresponding actions based on the set access rights. When the access exceeds the permission, an exception is generated, and the processor exception handling mechanism will capture and handle it.

[0035] After adopting the above technical solution, the present invention has at least the following beneficial effects:

[0036] 1. Protect memory partitions through page table settings to avoid unauthorized access caused by external factors, which may lead to abnormalities or malfunctions.

[0037] 2. Each processor core has its own page table system to prevent all processor core tasks from being unable to execute due to damage to a single global page table.

[0038] 3. Through the cooperation of multiple page tables, a variety of memory partition protection combinations can be formed in a flexible manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0040] Figure 1 A schematic diagram of address mapping implemented by multiple cores through MMU;

[0041] Figure 2 It is a schematic diagram of the system space;

[0042] Figure 3 Schematic diagram of the space seen by processor core i;

[0043] Figure 4 Schematic diagram of page table cascade mapping relationship;

[0044] Figure 5 This is the accessible space seen by each core without MMU enabled;

[0045] Figure 6 The accessible space seen by each core in Case 1 and Case 2 after MMU is enabled;

[0046] Figure 7 The accessible space seen by each core in case 3 after MMU is enabled;

[0047] Figure 8 The accessible space seen by each core in case 4 after enabling MMU;

[0048] Figure 9 This is the accessible space seen by each core in case 5 after MMU is enabled;

[0049] Figure 10 This is the accessible space seen by each core in case 6 after the MMU is enabled. DETAILED DESCRIPTION

[0050] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0051] This embodiment provides a memory partition protection method in AMP mode of a Sparc V8 multi-core processor, including:

[0052] The processor cores of the Sparc V8 multi-core processor are numbered 0, 1, 2, ... n-1, where n is the number of processor cores and the processor core numbered i is referred to as core i;

[0053] like Figure 2 As shown, let A be the entire address space of the processor, S memory is the memory space in A, S memory [i] is the effective memory address space that core i can see, s i is the program execution space allocated to core i, S io is the system's IO space, S share This is a shared space for storing global parameters required for processor startup and page tables used for partition protection. The following relationship exists between them:

[0054] A={S memory , S io , S share}, where S memory , S io , S share do not overlap with each other;

[0055] S memory ={s0, s1, ...s i ,...s n-1}, where s0, s1, ...s i ,...s n-1 do not overlap with each other;

[0056] s i 、S io It can also be further divided into several subspaces as needed, namely:

[0057] s i ={s i [0], s i [1], ...s i [j], ...}, where s i [0], s i [1], ...s i[j], ... do not overlap with each other;

[0058] S io ={s io [0], s io [1], ...s io [m], ...}, where s io [0], s io [1], ...s io [m], ...phase

[0059] do not overlap;

[0060] In order to further subdivide which subspaces are accessible and which subspaces are not accessible.

[0061] Due to the existence of subspaces, partition protection schemes can form various combinations. Taking a 32-bit multi-core processor as an example, each processor core can only access the system shared space, system IO space, and the program running space of its own core. A three-level page table is used for memory partition protection, as follows:

[0062] (1) Memory space partitioning

[0063] In the processor's memory space S memory In , a suitable program execution space is allocated to each processor core. Because each core is restricted to access only the program execution space of its own core, the memory space that processor core i can see is: S memory ={s i}, the program execution space of other cores in the system memory space is inaccessible to core i, or does not exist, such as Figure 3 As shown, a suitable program execution space is allocated to each processor core. From the perspective of core i, the spatial distribution of the entire system is:

[0064] A={S memory , S io , S share}={s i , S io , S share};

[0065] (2) Create a page table for each single core

[0066] The page table implements the mapping rules from virtual address to physical address, and the MMU implements the mapping process by querying the page table. A 32-bit processor can access 4GB of space. Using a single-level page table to map will occupy a large amount of memory space. Generally, a multi-level page table cascade is used, such as a 3-level page table. A page is the smallest memory unit that can be accessed after the page table is established and the MMU is enabled. Usually, the processor limits the minimum accessible page size to 4KB, that is, S memory 、si The size is a multiple of 4KB.

[0067] Assume that the size of the level 1 page table is 256 entries. The level 1 page table covers the 4GB space of the Sparc V8 multi-core processor. Each entry of the level 1 page table represents a 16MB subspace.

[0068] Assume that the size of the level 2 page table is 64 entries, the level 2 page table covers a 16MB subspace, and each entry of the level 2 page table represents a 256KB subspace;

[0069] Assume that the size of the level 3 page table is 64 entries, the level 3 page table covers a 256KB subspace, and each entry in the level 3 page table represents a 4KB subspace.

[0070] (3) Setting up the page table

[0071] 1) Level 1 page table processing

[0072] According to the size of the space divided previously, the addresses divided from 0x00000000 to 0xffffffff are processed one by one and inserted into the level 1 page table. The offset in the level 1 page table is determined by the 8 bits [31:24] of the 32-bit virtual address:

[0073] a) If the virtual address space represented by the i-th item in the level 1 page table is free and unused, set the item to all 0s, that is, 0x00000000;

[0074] b) If the virtual address represented by the i-th item in the level 1 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code (0x1100) or the readable and writable code (0x0100) or the readable executable code (0x1000) or the readable code (0x0000), and then OR it with the direct mapping code (0x10) (indicating that this is a direct mapping and no subsequent page table search is required), and the resulting value is written into the i-th item;

[0075] c) If the virtual address space represented by the i-th item in the level 1 page table cannot be directly mapped to the physical address space, the starting address of the level 2 page table is ORed with the subsequent mapping code (0x01) (indicating that subsequent page table mapping is required), and the resulting value is written into the i-th item;

[0076] 2) Level 2 page table processing

[0077] The offset in the level 2 page table is determined by bits [23:18] of the 32-bit virtual address:

[0078] a) If the virtual address space represented by the jth item in the level 2 page table is free and unused, set the item to all 0s, that is, 0x00000000;

[0079] b) If the virtual address represented by the jth item in the level 2 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code (0x1100) or the readable and writable code (0x0100) or the readable executable code (0x1000) or the readable code (0x0000), and then OR it with the direct mapping code (0x10) (indicating that this is a direct mapping and no subsequent page table search is required), and the resulting value is written to the jth item;

[0080] c) If the virtual address space represented by the jth item in the level 2 page table cannot be directly mapped to the physical address space, the starting address of the level 3 page table is ORed with the subsequent mapping code (0x01) (indicating that subsequent page table mapping is required), and the resulting value is written into the jth item;

[0081] 3) Level 3 page table processing

[0082] The offset in the 3-level page table is determined by 6 bits [17:12] of the 32-bit virtual address, and the 12 bits [11:0] of the virtual address represent the offset within the physical page:

[0083] a) If the virtual address space represented by the kth item in the level 3 page table is free and unused, set the item to all 0s, that is, 0x00000000;

[0084] b) If the virtual address represented by the kth item in the level 3 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, and OR it with the readable and writable executable code (0x1100) or the readable and writable code (0x0100) or the readable executable code (0x1000) or the readable code (0x0000), and then OR it with the direct mapping code (0x10) (indicating that this is a direct mapping and no subsequent page table search is required), and the resulting value is written to the kth item;

[0085] (4) Startup page table

[0086] After setting all page tables, set the content of the memory management unit page table pointer register to the starting address of the level 1 page table, flush the level 1 data cache and address cache, flush the page table cache content, and set the last bit of the memory management unit control register to 0x1 to enable the memory management unit;

[0087] (5) Protection takes effect

[0088] After setting up the page table and enabling the MMU, the processor core will find the corresponding physical page in the physical memory by searching the page table when accessing the system address space, and access the corresponding physical address through the method of (physical page + offset address within the physical page), and take corresponding actions according to the set access rights, such as read-write-execute, read-write, read-execute, read-only, etc. When the access exceeds the permission, an exception will be generated, and the processor exception handling mechanism will capture and handle it.

[0089] The following specific examples are provided in conjunction with the above embodiments. It can be understood that the following specific examples are merely illustrative of the specific implementation of the above embodiments, and are not intended to limit the technical solutions of the above embodiments.

[0090] Taking the Sparc V8 series Leon3 as an example, the specific implementation and effect of memory partition protection in the AMP mode of the Sparc V8 series multi-core processor are explained in two cases: without enabling the MMU and with enabling the MMU.

[0091] Assume that the processor has 4 cores and shared space S share and IO space S io All cores can access it, and S memory Make an allocation. memory The actual effective range is 1GB (0x4000 0000-0x7fff ffff). For simplicity, S memory The valid range is 16MB (0x4000 0000-0x40ff ffff).

[0092] Allocate memory space to multiple cores as follows:

[0093] Total memory space (16MB)——0x4000 0000-0x40ff ffff

[0094] Shared space (1MB) - 0x4000 0000-0x400f ffff

[0095] Core 0 (1MB) - 0x4050 0000-0x405f ffff

[0096] Core 1 (1MB) - 0x4060 0000-0x406f ffff

[0097] Core 2 (1MB) - 0x4070 0000-0x407f ffff

[0098] Core 3 (1MB) - 0x4080 0000-0x408f ffff

[0099] Each core page table area:

[0100] Core 0 - 0x4090 0000 - 0x4090 1fff

[0101] Core 1 - 0x4090 2000-0x4090 3fff

[0102] Core 2 - 0x4090 4000-0x4090 5fff

[0103] Core 3 - 0x4090 6000-0x4090 7fff

[0104] The rest of the memory space is set as free space. Following the steps described above, set up the page table for each processor core and enable their respective MMUs.

[0105] 1. Without enabling the MMU, examine two scenarios: multi-core reading and writing its own memory space and the memory space of other cores.

[0106] Since MMU is not enabled, there is no memory partition protection mechanism. Although the processor cores are partitioned, the accessible space seen by each core is actually the same, covering the entire storage space. Figure 5 shown.

[0107] (1) Each core reads and writes its own memory space

[0108] After completing the initialization of each core, each core continuously writes 16 bytes of data from the starting address of its own memory space. The content changes before and after reading and writing are compared, as shown in Table 1 and Table 2.

[0109] Table 1 Memory space contents after power-on initialization and before read and write operations

[0110]

[0111]

[0112] Table 2 Memory space contents after read and write operations on each core

[0113]

[0114]

[0115] (2) Cross-core reading and writing

[0116] After completing the initialization of each core, core 0 and core 1 read and write each other's memory space, and core 2 and core 3 read and write each other's memory space. Each core writes 16 bytes of data continuously from the starting address. The content changes before and after reading and writing are compared, as shown in Tables 3 and 4.

[0117] Table 3 Memory space contents after power-on initialization and before read and write operations

[0118]

[0119] Table 4 Memory space contents after cross-read and write operations

[0120]

[0121]

[0122] It can be seen that when MMU is not enabled, although each core is partitioned, the lack of a partition protection mechanism cannot prevent each core from accessing different partition spaces.

[0123] 2. When MMU is enabled, six situations are examined:

[0124] (1) Each core is set to have access only to its own memory space. Each core reads and writes to its own memory space, and the expected results are correct.

[0125] (2) Each core is set to access only its own memory space. After each core has finished reading and writing its own space, core 0 is allowed to access the memory space address (0x4060 0000) of core 1. The expected result is abnormal.

[0126] (3) Each core is set to access only its own memory space. However, in the page table of core 0, the access restriction to the space range (0x40600000-0x4063 ffff) of core 1 (size 256KB) is released. After each core has finished reading and writing its own space, core 0 attempts to read the content of 0x4060 0000 first and then write 0xaaaa5555. Then, it attempts to read the content of 0x4064 0000 first and then write 0xbbbb 5555. It is expected that the former operation will succeed, but the latter operation will fail.

[0127] (4) Modify the settings in (3) above and further split the 256KB (0x4060 0000-0x4063 ffff) into 64 4KB subspaces. Set (0x4060 0000-0x4060 0fff) to be accessible to core 0, and the rest to be inaccessible. Let core 0 try to read the content of 0x4060 0000 first and then write 0xaaaa 5555, and then try to read the content of 0x4060 1000 first and then write 0xaaaa 5555. It is expected that the former operation will succeed, but the latter operation will fail.

[0128] (5) Based on (4), release the access restriction of core 1 to the 4KB space (0x405c 0000-0x405c 0fff) of core 0, and let core 1 try to read the content of 0x405c 0000 first, and then write 0xbbbb 5555; then let core 1 try to read the content of 0x405c 1000 and then write 0xbbbb5555. It is expected that the first operation will succeed, and the last operation will fail.

[0129] (6) Mixed mode: set cores 0 and 1 to have page table control, and cores 2 and 3 to have no page table control; core 0 first writes 16 bytes continuously from the starting address of its own memory space, and then writes 0xaaaa 5555 to 0x4060 0000; core 1 first writes 16 bytes continuously from its own memory space, and then writes 0xbbbb 5555 to 0x405c0000; core 2 writes 0xccccccc3 to 0x405f 000c of core 0, overwriting 0xaaaa aaa3 written by core 0; core 3 writes 0xdddd ddd3 to 0x407f 000c of core 2. The expected result is normal.

[0130] (1) Each core reads and writes its own memory space

[0131] The accessible space seen by each core is as follows Figure 6 The access results are shown in Table 5, and the results are all normal.

[0132] Table 5 Execution results are normal

[0133]

[0134] (2) Core 0 is not authorized to access the space of Core 1

[0135] The accessible space seen by each core is the same Figure 6 .

[0136] Core 0 accesses address 0x4060 0000, which is not within its accessible range. The access results are shown in Table 6. When core 0 reads the address, a "data access exception" trap 0x09 is generated. The processor's trap handling mechanism captures the exception and terminates the program.

[0137] Table 6: Unauthorized access to core 0 generates an exception

[0138]

[0139]

[0140] (3) After releasing a section of core 1 space, core 0 accesses the result

[0141] In the page table of core 0, after releasing the access restriction to the space range (0x4060 0000-0x4063 ffff) of core 1 (size is 256KB), the accessible space seen by each core is as follows Figure 7 The running results are shown in Table 7.

[0142] Core 0 attempts to read the contents of 0x4060 0000 first, and then write 0xaaaa 5555. The operation is successful.

[0143] Then it tries to read the content of 0x4064 0000 and then write it to 0xbbbb 5555. Since 0x40640000 is beyond the accessible space range of core 0, the operation fails and trap 0x09 is generated.

[0144] Table 7 Operation results

[0145]

[0146] (4) Further split and reduce the space where core 0 is free from restrictions

[0147] In core 0, the 256KB (0x4060 0000-0x4063 ffff) is further split into 64 4KB subspaces, and (0x4060 0000-0x4060 0fff) is set to be accessible to core 0, and the rest are inaccessible. At this time, the accessible space seen by each core is as follows Figure 8 The running results are shown in Table 8.

[0148] Core 0 attempts to read the contents of 0x4060 0000 first, and then write 0xaaaa 5555. The operation is successful.

[0149] Then try to read the content of 0x4060 1000 and then write it to 0xbbbb 5555. Because 0x40601000 is beyond the space accessible to core 0, the operation is abnormal and trap 0x09 is generated.

[0150] Table 8 Operation results

[0151]

[0152]

[0153] (5) Cross-access between core 0 and core 1

[0154] Based on the setting in (4), the access restriction of core 1 to the 4KB space (0x405c 0000-0x405c 0fff) of core 0 is released. The accessible space seen by each core is as follows: Figure 9 The running results are shown in Table 9.

[0155] Core 0 attempts to read the contents of 0x4060 0000 first, and then write 0xaaaa 5555. The operation is successful.

[0156] Core 1 attempts to read the contents of 0x405c 0000 first, and then write 0xbbbb 5555. The operation is successful.

[0157] Then let core 1 try to read the content of 0x405c 1000 and write it to 0xbbbb 5555. Because 0x405c 1000 is beyond the accessible range of core 1, the operation is abnormal and trap 0x09 is generated.

[0158] As can be seen from the running results in Table 9, due to the exception of core 1, the processor's exception handling mechanism forces core 0 to enter debug mode (although core 0 does not have an exception), and all programs terminate.

[0159] Table 9 Operation results

[0160]

[0161]

[0162] (6) Hybrid method

[0163] Set core 0 and core 1 to have page table control and the same configuration as above, and core 2 and core 3 to have no page table control. The accessible space seen by each core is as follows: Figure 10 shown.

[0164] Core 0, core 1, core 2, and core 3 first write 16 bytes continuously from the starting address of the allocated memory space;

[0165] Core 2 writes 0xcccc ccc3 to 0x405f 000c of core 0, overwriting 0xaaaa aaa3 written by core 0;

[0166] Core 3 writes 0xdddd ddd3 to 0x407f 000c of core 2, overwriting 0xcccc ccc3 written by core 2;

[0167] Core 0 then writes 0xaaaa 5555 to 0x4060 0000 of core 1;

[0168] Core 1 then writes 0xbbbb 5555 to 0x405c 0000 of core 0;

[0169] The running results are shown in Table 10.

[0170] Table 10 Operation results

[0171]

[0172]

[0173] Although the present invention has been disclosed above by way of embodiments, they are not intended to limit the present invention. Any person skilled in the art may make slight changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A memory partition protection method in AMP mode of a Sparc V8 multi-core processor, characterized in that: include: The processor cores of the Sparc V8 multi-core processor are numbered 0, 1, 2, ... n-1, where n is the number of processor cores and the processor core numbered i is referred to as core i; A three-level page table is used for memory partition protection, as follows: (1) Memory space partitioning In the processor's memory space S memory In the example, a suitable program execution space is allocated to each processor core. From the perspective of core i, the spatial distribution of the entire system is: A={S memory , S io , S share }={s i , S io , S share }, where A is the entire address space of the processor, S memory is the memory space in A, S memory [i] is the effective memory address space that core i can see, s i is the program execution space allocated to core i, S io is the system's IO space, S share A shared space for storing global parameters required for processor startup and page tables used for partition protection; (2) Create a page table for each single core Assume that the size of the level 1 page table is 256 entries. The level 1 page table covers the 4GB space of the Sparc V8 multi-core processor. Each entry of the level 1 page table represents a 16MB subspace. Assume that the size of the level 2 page table is 64 entries, the level 2 page table covers a 16MB subspace, and each entry of the level 2 page table represents a 256KB subspace; Assume that the size of the level 3 page table is 64 entries, the level 3 page table covers a 256KB subspace, and each entry of the level 3 page table represents a 4KB subspace; (3) Setting up the page table Level 1 page table processing According to the size of the space divided previously, the addresses divided from 0x00000000 to 0xffffffff are processed one by one and inserted into the level 1 page table. The offset in the level 1 page table is determined by the 8 bits [31:24] of the 32-bit virtual address: a) If the virtual address space represented by the i-th item in the level 1 page table is free and unused, set the item to all 0s, that is, 0x00000000; b) If the virtual address represented by the i-th entry in the level 1 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the i-th entry; c) If the virtual address space represented by the i-th item in the level 1 page table cannot be directly mapped to the physical address space, then the starting address of the level 2 page table is ORed with the subsequent mapping code, and the resulting value is written into the i-th item; Level 2 page table processing The offset in the level 2 page table is determined by bits [23:18] of the 32-bit virtual address: a) If the virtual address space represented by the jth item in the level 2 page table is free and unused, set the item to all 0s, that is, 0x00000000; b) If the virtual address represented by the jth entry in the level 2 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the jth entry; c) If the virtual address space represented by the jth item in the level 2 page table cannot be directly mapped to the physical address space, then the starting address of the level 3 page table is ORed with the subsequent mapping code, and the resulting value is written into the jth item; Level 3 page table processing The offset in the 3-level page table is determined by 6 bits [17:12] of the 32-bit virtual address, and the 12 bits [11:0] of the virtual address represent the offset within the physical page: a) If the virtual address space represented by the kth item in the level 3 page table is free and unused, set the item to all 0s, that is, 0x00000000; b) If the virtual address represented by the kth entry in the level 3 page table is directly mapped to a physical page in the physical address space, shift the starting address of the virtual address space right by 4 bits, OR it with the readable and writable executable code or the readable and writable code or the readable executable code or the readable code, and then OR it with the direct mapping code, and write the resulting value into the kth entry; (4) Startup page table After setting all page tables, set the content of the memory management unit page table pointer register to the starting address of the level 1 page table, flush the level 1 data cache and address cache, flush the page table cache content, and set the last bit of the memory management unit control register to 0x1 to enable the memory management unit; (5) Protection takes effect After setting up the page table and enabling the memory management unit, the processor core accesses the corresponding physical address by looking up the page table and takes corresponding actions based on the set access rights. When the access exceeds the permission, an exception is generated, and the processor exception handling mechanism will capture and handle it.

Images