Methods for obtaining memory access permissions, electronic devices and storage media

Abstract

This application provides a method, electronic device, and storage medium for obtaining memory access permissions. The method includes: checking the management domain to which the transaction belongs and the physical address accessed based on permissions; performing a multi-level MTT cache parallel lookup operation to obtain the hit results of the multi-level MTT cache; and determining the memory access permissions based on the hit results of the multi-level MTT cache. The memory access permission acquisition method of this application first caches the multi-level page table results of IO-side device transactions under a specific management domain. In subsequent access permission checks, a multi-level page table cache parallel lookup strategy replaces the traditional serial page table process, allowing IO-side device transactions to simultaneously determine the hit results of the multi-level page table cache and obtain access permissions based on the hit results. This strategy not only significantly improves the speed of permission checks but also reduces the frequency of memory access and bandwidth consumption. Furthermore, it efficiently adapts to access scenarios of IO-side devices in different management domains, further improving the overall efficiency of permission checks.

Description

Technical Field

[0001] The embodiments of this application relate to, but are not limited to, the field of computer technology, and in particular to a method for obtaining memory access permissions, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] The Reduced Instruction Set Computing-V (RISC-V) privileged architecture supports host / privileged software hosting for multiple tenants (applications or virtual machines), with tenants relying on the hardware isolation mechanisms it manages to run. However, traditional host / privileged software (such as operating systems and hypervisors) can have unrestricted access to memory resources and hardware isolation mechanisms. Furthermore, in multi-tenant scenarios, host software, tenant workloads, and devices can all become sources of security threats, seriously threatening the confidentiality of memory data.

[0003] To enhance platform security, isolated Supervisor domains need to be established. Each domain is associated with a dedicated physical address region and isolated from other domains to achieve a differentiated trust model and ensure secure access to multi-tenant resources. The RISC-V SMMTT standard defines a page-granular permission check process based on the I / O Memory Tracking Table (IOMTT) module. Within a specific physical address space, it uses a three-level page table system (MTTL3, MTTL2, and MTTL1) with the Physical Page Number (PPN) as the base address and a fixed field of the physical address as the offset address for addressing, thus addressing the need for differentiated permissions across multiple Supervisor domains. However, this specification does not provide a fast lookup scheme for memory access permissions, leaving a technical gap. Summary of the Invention

[0004] This application provides a method for obtaining memory access permissions, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] The first aspect of this application provides a method for obtaining memory access permissions, the method comprising:

[0006] Based on permissions, check the management domain to which the transaction belongs and the physical address accessed, perform multi-level MTT cache parallel lookup operations, and obtain the multi-level MTT cache hit results;

[0007] Based on the hit results of the multi-level MTT cache, memory access permissions are determined.

[0008] A second aspect of this application provides an electronic device, comprising: at least one processor; at least one memory for storing at least one program; and, when at least one of the programs is executed by at least one of the processors, implementing the aforementioned memory access permission acquisition method.

[0009] A third aspect of this application provides a computer-readable storage medium storing computer-executable instructions for performing the aforementioned memory access permission acquisition method.

[0010] A fourth aspect of this application provides a computer program product including a computer program or computer executable instructions, the computer program or computer executable instructions being stored in a computer-readable storage medium, a processor of an electronic device reading the computer program or computer executable instructions from the computer-readable storage medium, and the processor executing the computer program or computer executable instructions to cause the electronic device to perform the memory access permission acquisition method described above.

[0011] This application has the following beneficial effects:

[0012] The memory access permission acquisition method in this application first caches the multi-level page table lookup results of IO-side device transactions under a specific management domain. During subsequent access permission checks, a parallel lookup strategy using multi-level page table caches replaces the traditional serial lookup process. This allows IO-side device transactions to simultaneously determine the hit results of multi-level page table caches and obtain access permissions based on these results. This strategy not only significantly improves the speed of permission checks but also reduces memory access frequency and bandwidth consumption. Furthermore, it efficiently adapts to access scenarios of IO-side devices in different management domains, further enhancing the overall efficiency of permission checks. Attached Figure Description

[0013] Figure 1 This application provides a schematic diagram of a three-level permission check table-running process in an embodiment of the present application.

[0014] Figure 2 This is a schematic diagram of a system architecture applicable to an embodiment of this application;

[0015] Figure 3 A flowchart illustrating a method for obtaining memory access permissions provided in an embodiment of this application;

[0016] Figure 4 A schematic diagram of an MTTL3 cache entry structure provided in an embodiment of this application;

[0017] Figure 5A schematic diagram of an MTTL2 cache entry structure provided in an embodiment of this application;

[0018] Figure 6 A schematic diagram of an MTTL1 cache entry structure provided in an embodiment of this application;

[0019] Figure 7 A schematic diagram of an MTTL2 / MTTL1 cache architecture provided for an embodiment of this application;

[0020] Figure 8 A schematic diagram of a three-level MTT cache parallel lookup architecture provided in an embodiment of this application;

[0021] Figure 9 A flowchart of a three-level MTT cache lookup provided in this application embodiment;

[0022] Figure 10 This application provides an architectural diagram of a permission-checking transaction processing system.

[0023] Figure 11 A schematic diagram illustrating an entry state flipping method provided in this application embodiment;

[0024] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical methods, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described may be performed in a different order than that shown in the flowchart. In the description of the specification, claims, and the foregoing drawings, "at least one" means one or more; "more than" means two or more; "greater than," "less than," and "exceeding" are understood to exclude the stated number; "above," "below," and "within" are understood to include the stated number. The use of terms such as "first," "second," etc., is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly specifying the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0027] In this embodiment, "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: the existence of a alone, the existence of b alone, the existence of c alone, the simultaneous existence of a and b, the simultaneous existence of a and c, the simultaneous existence of b and c, or the simultaneous existence of a, b, and c, where a, b, and c can be single or multiple.

[0028] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0029] To facilitate a better understanding and explanation of the solutions in the embodiments of this application, some concepts involved in the embodiments of this application will be explained below.

[0030] The RISC-V privileged architecture defines Supervisor privilege levels, allowing software running at these levels to optionally enable host / privileged software (such as an operating system or hypervisor) to host virtual machines. In RISC-V processor platforms, there are deployment scenarios that host multiple tenants (including applications or virtual machines), and each tenant relies on hardware isolation mechanisms managed by host / privileged software to ensure operational independence. However, traditional host / privileged software possesses unrestricted access to memory resources and hardware isolation mechanisms; in typical multi-tenant scenarios, host software, tenant workloads, and devices can all become sources of security threats, severely compromising the confidentiality of memory data. Therefore, to improve the operational security of the RISC-V processor platform, isolated Supervisor domains need to be established, each associated with a set of physical address regions. These physical address regions are isolated from other Supervisor domains on the same platform, thereby implementing a differentiated trust model and ensuring the security of multi-tenant access to platform resources.

[0031] To achieve the aforementioned isolation requirements, the RISC-V SMMTT standard specification defines the page-level permission check process in detail. Specifically, this process uses the IOMTT module and a three-level page table lookup (three-level page lookup) mechanism to complete the permission verification of physical addresses. The following example uses a 48-bit wide physical address space (subsequent examples are based on this configuration): Address permission checks for memory access transactions are implemented through a three-level page table lookup, with all three page tables (MTTL3, MTTL2, MTTL1) stored in memory. Each page table lookup requires initiating a page lookup request to read the corresponding page table entry from memory; the lookup logic is as follows: using the Physical Page Number (PPN) as the base address, the fixed field in the physical address is used as the offset address to address the corresponding entry in the page table (where pn [*] represents the fixed field used for offset addressing in the physical address during each level of page lookup).

[0032] The specific table lookup process is as follows: the lookup base address (PPN) for the MTTL3 page table is obtained through software configuration registers; the lookup base addresses (PPNs) for the MTTL2 and MTTL1 page tables are extracted from the lookup results of the parent page table (i.e., the contents of the corresponding page table entries). Access permissions for physical addresses can be obtained in two ways: one is by reading directly from the MTTL1 table entry, and the other is by reading from the MTTL2 table entry.

[0033] Please see Figure 1 This is a schematic diagram of a three-level permission check table-running process provided in an embodiment of this application. Figure 1 As shown, in the three-level access control process, the 48-bit physical address (PA) is first segmented: the entire address is split into four fields, namely 2-bit pn [3] (corresponding to address bits 47-46), 21-bit pn [2] (corresponding to address bits 45-25), 9-bit pn [1] (corresponding to address bits 24-16), and 4-bit pn [0] (corresponding to address bits 15-12). These fields provide offset addresses for page table lookups at different levels.

[0034] The first level of the three-level page table is the MTTL3 page table, whose base address is provided by the software-configured register (i.e., mttp in the figure), and the offset address corresponds to the pn field in the physical address [3]. This page table contains 4 entries, with a table size of 32B and a corresponding address space of 64TB. After accessing the MTTL3 entry by combining the base address and the offset address, the physical page number (PPN) corresponding to the MTTL2 page table can be obtained, providing the page table base address for the next level page table lookup.

[0035] Next is the second-level MTTL2 page table, whose base address comes from the result of the MTTL3 page table entry, and the offset address is the pn field in the physical address [2]. This page table contains 2M entries, with a table size of 16MB, corresponding to a 32MB address space; after accessing the MTTL2 entry, there are two possible results: one is to obtain the physical page number (base address) of the MTTL1 page table, and the other is to directly obtain the access permission of the physical address from this entry. If the MTTL2 table access result is the physical page number of the MTTL1 page table, then the physical page number is used to access the next level of the table; if the MTTL2 table access result is the access permission of the physical address, then there is no need to access the next level of the table.

[0036] Finally, there is the third-level MTTL1 page table, whose base address is provided by the result of the MTTL2 page table entry. The offset address corresponds to the pn [1] field in the physical address. This page table contains 512 entries and has a size of 4KB, corresponding to a 4KB address space. Accessing the MTTL1 entry grants access to the physical address.

[0037] Please see Figure 2 This is a schematic diagram of a system architecture applicable to an embodiment of this application. Figure 2As shown, the system architecture works as follows: After a device sends a request carrying an I / O Virtual Address (IOVA), the I / O bridge schedules the request to the I / O Memory Management Unit (IOMMU). The IOMMU translates the IOVA into a System Physical Address (SPA). This translation process involves implicit memory access requests that require page table lookups. Both the IOMMU's page table lookup request and the final translated SPA request must undergo permission checks by the I / O Memory Trace Table Checker (IOMTT Checker). The IOMTT Checker consists of a Supervisor Domain Classifier (SDCL) and an MTT Checker (MTTCHK). The Supervisor Domain Classifier (SDCL) in the IOMTT Checker is mainly responsible for mapping the device-side identifier (ID) to the corresponding Supervisor domain identifier (SDID), and extracting the attribute fields required for access under that domain, providing basic information for subsequent permission check logic processing within the domain. The MTT Checker (MTTCHK) verifies the address of the device memory access transaction based on the permission rules stored in the MTT page table, thereby determining whether the current access address is allowed. Together, the two complete the core link of IOMTT's permission check for device memory access.

[0038] The execution entity of the memory access permission acquisition method in this application embodiment can be Figure 2 The IOMTT Checker maps the device-side identifier (ID) to the corresponding Supervisor domain identifier (SDID) via SDCL. Then, it uses MTTCHK to check the management domain (Supervisor domain) to which the transaction belongs and the physical address accessed based on permissions. It performs multi-level MTT cache parallel lookup operations to obtain the multi-level MTT cache hit results, and then determines the memory access permissions based on the multi-level MTT cache hit results.

[0039] Please see Figure 3 This is a flowchart illustrating a method for obtaining memory access permissions provided in an embodiment of this application. Figure 3 As shown, the method includes the following steps:

[0040] Step S101: Check the management domain to which the transaction belongs and the physical address accessed according to the permissions, perform a multi-level MTT cache parallel lookup operation, and obtain the multi-level MTT cache hit result;

[0041] Step S102: Determine memory access permissions based on the hit results of the multi-level MTT cache.

[0042] The memory access permission acquisition method in this application first caches the multi-level page table lookup results of IO-side device transactions under a specific management domain. During subsequent access permission checks, a parallel lookup strategy using multi-level page table caches replaces the traditional serial lookup process. This allows IO-side device transactions to simultaneously determine the hit results of multi-level page table caches and obtain access permissions based on these results. This strategy not only significantly improves the speed of permission checks but also reduces memory access frequency and bandwidth consumption. Furthermore, it efficiently adapts to access scenarios of IO-side devices in different management domains, further enhancing the overall efficiency of permission checks.

[0043] The multi-level MTT cache involved in this application embodiment may specifically include: MTTL3 cache, MTTL2 cache, and MTTL1 cache. Each cache level stores the corresponding level's memory page table content; that is, the MTTL3 cache stores MTTL3 page table content, the MTTL2 cache stores MTTL2 page table content, and the MTTL1 cache stores MTTL1 page table content. Specifically, the page table content of each cache level is generated by performing a table-following operation during permission checks on the access address of a specific Supervisor domain device, and writing the table-following result into the cache. This cache content can be used for subsequent permission check transactions on the same Supervisor domain device. Furthermore, the number of MTT cache levels can be increased or decreased according to actual needs; this application embodiment does not impose any limitations on this.

[0044] The MTTL3 cache, MTTL2 cache and MTTL1 cache involved in the embodiments of this application will be described below.

[0045] For example, the MTTL3 cache involved in the embodiments of this application can be implemented using registers. The MTTL3 cache includes multiple cache entries, each cache entry including: a validity flag, used to identify whether the cache entry is valid; a management domain flag, used to identify the management domain; a memory page table entry, used to store the valid content of the MTTL3 table entry in memory; and a parity bit.

[0046] Please see Figure 4 This is a schematic diagram of an MTTL3 cache entry structure provided in an embodiment of this application. Figure 4 As shown, the length of an MTTL3 cache entry is 49 bits, and it includes the following fields:

[0047] Valid flag (valid): occupies 1 bit, located in [0], and is used to identify whether the cache entry is valid. For example, when the value of valid is 1, it means that the current cache entry is valid; when the value of valid is 0, it means that the current cache entry is invalid.

[0048] Management domain identifier (sdid): occupies 2 bits, located in the [2:1] position, and is used to identify the management domain (e.g., the Supervisor domain).

[0049] Memory page table entry (mpte): occupies 45 bits, located in bits [47:3], and is used to store the valid content of the MTTL3 table entry in memory, such as the base address (physical page number PPN) of the next level page table (i.e., the MTTL2 page table).

[0050] Parity bit: occupies 1 bit, located in

[48] , and is used to detect whether a single bit error occurs in the cached data.

[0051] In practice, given the relatively small number of entries in the MTTL3 page table, and considering factors such as performance and area, the MTTL3 cache can be implemented using a register set.

[0052] For example, the MTTL2 cache involved in the embodiments of this application can be implemented using a cache. The MTTL2 cache includes multiple cache entries, and each cache entry includes:

[0053] A tag is used to store the second bit segment of the physical address, which is used to match the physical address of the permission check transaction;

[0054] A memory page table entry is used to store the valid content of an MTTL2 table entry in memory.

[0055] Tag check bit; memory page table entry check bit.

[0056] Please see Figure 5 This is a schematic diagram of an MTTL2 cache entry structure provided in an embodiment of this application. Figure 5 As shown, the MTTL2 cache entry is 72 bits long and includes the following fields:

[0057] Tag: Occupies 23 bits, located in bits [22:0], used to store the second bit segment of the physical address (in this example, bits [47:25] of physical address PA), used to match the physical address of the permission check transaction;

[0058] Memory page table entry (mpte): occupies 47 bits, located in bits [69:23], and is used to store the valid content of the MTTL2 table entry in memory. The valid content of the MTTL2 cache can be the base address (physical page number PPN) of the next level page table (i.e., the MTTL1 page table), or it can be permission information.

[0059] Tag parity bit: occupies 1 bit, located in

[70] , used to detect whether there is a single bit error in the tag field, specifically it can be the odd parity bit of the tag field;

[0060] Page table entry parity bit: occupies 1 bit, located at bit

[71] , used to detect whether a single bit error occurs in the mpte field, specifically the odd parity bit of the mpte field.

[0061] For example, the MTTL1 cache involved in the embodiments of this application can be implemented using a cache. The MTTL1 cache includes multiple cache entries, each cache entry including: a tag, used to store the first bit segment of the physical address for matching the physical address of the permission check transaction; a memory page table entry, used to store the valid content of the MTTL1 table entry in memory; a tag check bit; and a memory page table entry check bit.

[0062] In some embodiments of this application, both the MTTL2 cache and the MTTL1 cache have corresponding valid flags, and the valid flags corresponding to the MTTL2 cache and the MTTL1 cache are stored in separate RAM or register groups.

[0063] In some embodiments of this application, one of the following operations is performed on any level of the multi-level MTT cache: setting the valid flags corresponding to all cache entries to invalid values; or setting the valid flags corresponding to all cache entries corresponding to one or more management domains to invalid values.

[0064] Please see Figure 6 This is a schematic diagram of an MTTL1 cache entry structure provided in an embodiment of this application. Figure 6 As shown, the length of this MTTL1 cache entry is 66 bits, and it specifically includes the following fields:

[0065] Tag: Occupies 32 bits, located in bits [31:0], used to store the first bit segment of the physical address (in this example, bits [47:16] of physical address PA), used to match the physical address of the permission check transaction;

[0066] Memory page table entry (mpte): occupies 32 bits, located in bits [63:32], and is used to store the valid content of the MTTL1 table entry in memory. The valid content of the MTTL1 cache is the permission information.

[0067] Tag parity bit: occupies 1 bit, located in

[64] , used to detect whether there is a single bit error in the tag field, specifically it can be the odd parity bit of the tag field;

[0068] Page table entry parity bit: occupies 1 bit, located at

[65] , used to detect whether a single bit error occurs in the mpte field, specifically the odd parity bit of the mpte field.

[0069] Please see Figure 7 This diagram illustrates an MTTL2 / MTTL1 caching architecture provided in an embodiment of this application. Given the large size of page table entries for MTTL2 and MTTL1, to store more page table data, the corresponding MTTL2 and MTTL1 page table data can be cached using MTTL2Cache and MTTL1Cache respectively.

[0070] like Figure 7 As shown, both MTTL2 Cache and MTTL1 Cache can adopt a 256-set × 4-way design, where each set contains 4 cache lines, each cache line corresponds to one way, and each cache line is used to store one cache entry.

[0071] In a specific implementation, the MTTL2 cache can be implemented using 4 rows = 256 and 72 columns of random access memory (RAM), with a capacity of approximately 9KB; the MTTL1 cache can be implemented using 4 rows = 256 and 66 columns of RAM, with a capacity of approximately 8KB. Therefore, the total RAM capacity required for the IOMTT in this embodiment is approximately 17KB.

[0072] In some possible embodiments, the validity flags of each cacheline in the MTTL2 and MTTL1 caches can be maintained through separate RAM. For example, if the MTTL2 and MTTL1 caches each contain 256×4 cachelines, then the validity flag information of each of the 256×4 cachelines in the MTTL2 and MTTL1 caches can be maintained separately in RAM.

[0073] In some possible implementations, to accelerate the invalidation efficiency of MTTL2 and MTTL1 caches, a register set of the same size (256 x 4) as the cache can be constructed to maintain valid flag information. This approach can effectively reduce the time required for invalidation.

[0074] In this embodiment of the application, memory access permissions are determined based on the hit results of the multi-level MTT cache, including the following cases:

[0075] If an MTTL1 cache hit occurs, memory access permissions are obtained from the memory page table entry in the MTTL1 cache.

[0076] If the MTTL1 cache misses and the MTTL2 cache hits, one of the following two scenarios will be executed based on the contents of the memory page table entries in the MTTL2 cache: one is to obtain memory access permissions from the memory page table entries in the MTTL2 cache; the other is to obtain the base address of the MTTL1 page table from the memory page table entries in the MTTL2 cache, and perform a table lookup operation on the MTTL1 page table based on the base address of the MTTL1 page table and the first offset address (pn[1]) in the physical address to obtain memory access permissions.

[0077] If neither MTTL1 cache nor MTTL2 cache is hit, but MTTL3 cache is hit, the base address of MTTL2 page table is obtained from the memory page table entry of MTTL3 cache, and the MTTL2 page table is accessed based on the base address of MTTL2 page table and the second offset address (pn[2]) in the physical address to obtain memory access permission;

[0078] If the MTTL1 cache, MTTL2 cache, and MTTL3 cache are all missed, at least two levels of page table lookup operations are performed based on the physical address and the MTTL3 page table base address to obtain memory access permissions. The at least two levels of page table lookup operations include either MTTL3 and MTTL2 page table lookup operations or MTTL3, MTTL2, and MTTL1 page table lookup operations.

[0079] To obtain memory access permissions, the MTTL2 page table is accessed by performing a table-running operation based on the base address and the second offset address (pn[2]) of the physical address of the MTTL2 page table, including one of the following: performing a table-running operation based on the base address and the second offset address of the physical address of the MTTL2 page table to obtain memory access permissions from the MTTL2 page table; or, performing a table-running operation based on the base address and the second offset address of the physical address of the MTTL2 page table to obtain the base address of the MTTL1 page table, and performing a table-running operation based on the base address and the first offset address of the physical address of the MTTL1 page table to obtain memory access permissions from the MTTL1 page table.

[0080] Specifically, since the content of the memory page table entries in the MTTL2 cache may be memory access permissions or the base address of the MTTL1 page table, different follow-up processing is performed for different situations. If the content of the memory page table entries in the MTTL2 cache is memory access permissions, then there is no need to run the table and the memory access permission information is directly output; if the content of the memory page table entries in the MTTL2 cache is the base address of the MTTL1 page table, then it is necessary to use the base address of the MTTL1 page table and the corresponding offset address pn[1] in the physical address to construct the table running address and perform the table running operation on the MTTL1 page table to obtain memory access permissions.

[0081] In some embodiments of this application, when page lookup operations are required, the memory page table entries obtained from each level of page lookup are also written into the corresponding level's cache entries. The memory page table entries are either the base address of the next level page table or memory access permissions. This way, when searching for access permissions for the same physical address next time, the information can be directly obtained through a cache lookup, reducing page lookup operations.

[0082] The conditions for MTTL1 cache, MTTL2 cache and MTTL3 cache hit are explained below.

[0083] In this embodiment of the application, the multi-level MTT cache parallel lookup operation includes an MTTL3 cache lookup operation; the MTTL3 cache lookup operation includes:

[0084] Index the target cache entry in the MTTL3 cache based on the third bit segment of the physical address;

[0085] If the target cache entry meets the first condition, the MTTL3 cache is considered to have hit;

[0086] The first condition includes:

[0087] A valid flag in the target cache entry indicates that the cache entry is valid;

[0088] The permission check matches the management domain to which the transaction belongs with the management domain flag in the target cache entry.

[0089] In this embodiment of the application, the multi-level MTT cache parallel lookup operation includes an MTTL2 cache lookup operation; the MTTL2 cache lookup operation includes:

[0090] Index the target cache entry in the MTTL2 cache based on the fourth bit segment of the physical address;

[0091] If the target cache entry meets the second condition, the MTTL2 cache is considered to have hit;

[0092] The second condition includes:

[0093] The valid flag corresponding to the target cache entry indicates that the cache entry is valid;

[0094] The second bit segment of the physical address matches the tag in the target cache entry;

[0095] The permission check ensures that the management domain to which the transaction belongs matches the management domain flag corresponding to the target cache entry;

[0096] Tag verification bit matching successful;

[0097] The memory page table entry checksum comparison was successful.

[0098] For example, the MTTL2 cache includes multiple entry groups, each entry group includes multiple entries; indexing the target cache entry in the MTTL2 cache according to the fourth bit segment of the physical address includes: performing an XOR calculation based on the fourth bit segment of the physical address to obtain the group index; indexing the target entry group in the MTTL2 cache according to the group index; and searching for the target cache entry in the multiple entries corresponding to the target entry group.

[0099] In this embodiment of the application, the multi-level MTT cache parallel lookup operation includes an MTTL1 cache lookup operation; the MTTL1 cache lookup operation includes:

[0100] Index the target cache entry in the MTTL1 cache based on the fifth bit segment of the physical address;

[0101] If the target cache entry meets the third condition, the MTTL1 cache is considered to have hit;

[0102] The third condition includes:

[0103] The valid flag corresponding to the target cache entry indicates that the cache entry is valid;

[0104] The first bit segment of the physical address matches the tag in the target cache entry;

[0105] The permission check ensures that the management domain to which the transaction belongs matches the management domain flag corresponding to the target cache entry;

[0106] Tag verification bit matching successful;

[0107] The memory page table entry checksum comparison was successful.

[0108] For example, the MTTL1 cache includes multiple entry groups, each entry group including multiplexed entries; the target cache entry is indexed in the MTTL1 cache based on the fifth bit segment of the physical address, including:

[0109] The group index is determined based on the fifth bit segment of the physical address;

[0110] The target entry group is indexed in the MTTL1 cache based on the group index, and the target cache entry is searched in the multiway entry corresponding to the target entry group.

[0111] Please see Figure 8 This is a schematic diagram of a three-level MTT cache parallel lookup architecture provided in an embodiment of this application. Figure 8 As shown, the architecture includes an MTT cache module (MTT cache block) and a Cache interface module (CacheIF). The MTT cache module comprises three levels of cache sub-modules: mttl3_cache, mttl2_cache, and mttl1_cache. The Cache interface module comprises three lookup logic sub-modules: mttl3_lookup logic, mttl2_lookup logic, and mttl1_lookup logic. Additionally, the architecture includes three processing logic sub-modules: mttl3_proc logic, mttl2_proc logic, and mttl1_proc logic.

[0112] The following is combined Figure 8 The three-level MTT cache parallel lookup architecture shown provides an illustrative explanation of the parallel lookup process of the three-level MTT cache.

[0113] When a permission check transaction request (trans_req) is received from the I / O side device, Figure 8 The three lookup logic submodules (mttl3_lookup logic, mttl2_lookup logic, and mttl1_lookup logic) in the illustrated architecture execute MTT cache lookup operations at their respective levels in parallel. Specifically, the trans_req carries the physical address and Supervisor domain identifier (sdid). Based on this trans_req, mttl3_lookup logic, mttl2_lookup logic, and mttl1_lookuplogic will respectively execute MTTL3 cache lookup, MTTL2 cache lookup, and MTTL1 cache lookup operations.

[0114] The working logic of the mttl3_lookup logic module is as follows: The [47:46] bits of the physical address PA (i.e., the pn [3] value) are used as the index basis. The value range of pn [3] is 0 to 3, and each value corresponds to an index of a register entry. The mttl3_lookup logic reads the corresponding MTTL3 cache entry from the mttl3_cache (register group) using the pn [3] value. The mttl3_cache returns the read data (rdata) to the mttl3_lookup logic. The rdata is the MTTL3 cache entry that matches the pn [3]. Subsequently, the mttl3_lookup logic performs three verification operations on the MTTL3 cache entry: determine whether the valid flag (valid) value is 1; verify whether the entry management field flag (sdid) value is consistent with the sdid carried in trans_req; check whether the parity bit (parity) is correct; if all three verifications are satisfied (i.e., the valid value is 1, the sdid value matches and the parity bit is checked correctly), then the MTTL3 cache is determined to be hit, and the memory page table entry (mpte) field in the cache entry is extracted to provide data support for subsequent table processing.

[0115] The working logic of the mttl2_lookup logic module is as follows: Based on the pn[2] value in the physical address PA[45:25], perform an XOR operation in groups of 8 bits to obtain the set value of the accessed cache. The specific calculation formula is: set = {3'b000, PA[45:41]} ^ PA[40:33] ^ PA[32:25]. The cacheline content corresponding to the 4 ways can be obtained through this set value; then, using the physical address PA[47:25] as the tag value, it is matched with the tag content stored in the cacheline of each way in turn. If the match is consistent, it is determined that the cacheline has been initially hit. Two further verification operations are performed: determine whether the Supervisor field accessed by the current physical address is consistent with the Supervisor field corresponding to the cacheline (i.e., compare whether the sdid value matches); check whether the cacheline is valid (i.e., whether the valid value is 1). If the above tag matching and both checks are satisfied, and the odd check of the mpte field and tag field in the cacheline passes, then the physical address is determined to have hit the MTTL2 Cache; if either the odd check of the mpte field or the tag field fails, then the cacheline is not determined to have hit.

[0116] In this example, the cache set value is generated by performing an XOR operation on the key field of the physical address. This address mapping method can distribute the address more evenly across different sets, effectively reducing the probability of address conflicts, thereby improving the cacheline hit efficiency and ensuring that the MTTL2 Cache plays a more stable caching role during data access.

[0117] The working logic of the mttl1_lookup logic module is as follows: Based on the pn [1] value in the physical address PA [24:16], its lower 8 bits are extracted as the set value for accessing the cache. The specific calculation formula is: set = PA [23:16]. The cacheline content corresponding to the 4 ways can be obtained through this set value; then, using the physical address PA [47:16] as the tag value, it is matched with the tag content stored in the cacheline of each way in turn. If the match is consistent, it is determined that the cacheline has been initially hit. Two further verification operations are performed: it is determined whether the Supervisor field accessed by the current physical address is consistent with the Supervisor field corresponding to the cacheline (i.e., whether the sdid value matches); and it is checked whether the cacheline is valid (i.e., whether the valid value is 1). If the above tag matching and both checks are satisfied, and the odd parity checks of the mpte field and tag field in the cacheline are both passed, then the physical address is determined to have hit the MTTL1 Cache; if either the odd parity check of the mpte field or the tag field fails, then the cacheline is not determined to have hit.

[0118] Please see Figure 9 This is a flowchart illustrating a three-level MTT cache lookup process provided in an embodiment of this application. Figure 9 As shown, the permission check transaction request (trans_req) is first sent to the Cache interface module (cacheif). Based on the trans_req, mttl3_lookuplogic, mttl2_lookup logic, and mttl1_lookup logic will send read requests (rd) to the corresponding mttl3_cache, mttl2_cache, and mttl1_cache in parallel, and receive the read data (rdata) returned by the corresponding mttl3_cache, mttl2_cache, and mttl1_cache in parallel, and then perform cache hit judgment.

[0119] The process of determining a L3 cache hit is as follows:

[0120] First, determine if the MTTL1 Cache is hit. If it is, extract the mpte content from the hit MTTL1 Cache entry and output the mpte content to the hit path of the mttl1_proc logic module; otherwise, continue to determine.

[0121] Next, determine whether the MTTL2 Cache is hit. If it is, extract the mpte content from the hit MTTL2 Cache entry and output the mpte content to the hit path of the mttl2_proc logic module; otherwise, continue to determine.

[0122] Finally, determine whether an MTTL3 cache hit occurs. If so, extract the mpte content from the hit MTTL3 cache entry and output the mpte content to the hit path of the mttl3_proc logic module. If not, consider it a cache miss and output the transaction to the cache_miss path of the mttl3_proc logic module.

[0123] It should be noted that the entire judgment process described above is processed in parallel and completed within one clock cycle.

[0124] Please see Figure 10 This is a schematic diagram of the architecture of a permission checking transaction processing system provided in an embodiment of this application. Figure 10 As shown, the system architecture includes an entry group, an MTT cache module (cache block), a cache interface module (cacheif), three-level processing logic sub-modules (mttl3_proc_logic, mttl2_proc_logic, mttl1_proc_logic), and an arbitration module (arbiter).

[0125] In some embodiments of this application, before performing a multi-level MTT cache parallel lookup operation based on the management domain to which the permission check transaction belongs and the physical address accessed, in response to receiving the permission check transaction, a management entry and a unique entry number are assigned to the permission check transaction. The management entry is used to store the permission check transaction and the transaction status of the permission check transaction. There are multiple management entries, and each management entry corresponds to one permission check transaction.

[0126] In some embodiments of this application, memory access permissions are determined based on the hit results of the multi-level MTT cache, including:

[0127] If the hit result is one of the following, then perform at least one level of lookup table operation to obtain memory access:

[0128] The MTTL1 cache was not hit, while the MTTL2 cache hit the MTTL1 page table base address;

[0129] Alternatively, if both MTTL1 and MTTL2 caches are not hit, but MTTL3 cache hits the MTTL2 page table base address;

[0130] Alternatively, all three caches (MTTL1, MTTL2, and MTTL3) were not hit.

[0131] For example, the transaction state of the entry storage can be one of the following: idle state; cache lookup state; MTTL3 table read state; MTTL2 table read state; MTTL1 table read state.

[0132] For example, the process of table lookup operations includes:

[0133] A table-running request is initiated through the table-running module, which can be an MTTL3 table-running module, an MTTL2 table-running module, or an MTTL1 table-running module. The table-running request carries the unique entry number of the transaction and the page table base address for permission checks.

[0134] Based on the unique entry number, obtain permissions from the management entry to check the transaction status;

[0135] Determine the level based on the transaction status;

[0136] Based on the offset address in the page table base address and physical address, perform the table walk operation corresponding to the level, and update the transaction status of the transaction by checking permissions.

[0137] Return the table walkthrough response, which carries the unique entry number of the permission-checked transaction and the table walkthrough result.

[0138] In some embodiments of this application, the level corresponding to the table-running result is determined based on the unique entry number in the table-running response; according to the level, the table-running result is routed to the table-running processing module of the corresponding level, so that the table-running processing module of the corresponding level outputs memory access permissions or initiates a table-running request for the next level table-running operation based on the table-running result.

[0139] In some embodiments of this application, when there is a conflict between multiple permission check transaction table-running requests, the multiple table-running requests are arbitrated to determine the priority of each table-running request; and the table-running operations of each permission check transaction are processed according to the priority.

[0140] In some embodiments of this application, if there is a conflict between the response messages of the permission check transactions output by the MTTL2 and MTTL1 transaction processing modules, the response messages output by the MTTL2 and MTTL1 transaction processing modules are arbitrated to determine the priority of each response message; and the response message is output according to the priority.

[0141] In some embodiments of this application, after determining memory access permissions, the unique entry number corresponding to the permission check transaction is released, and the management entry is flipped to an invalid state.

[0142] In some embodiments of this application, the reception of new permission check transactions is blocked when all management entries are occupied by permission check transactions.

[0143] like Figure 10 As shown, the entry group includes 256 management entries (ety0~ety255). Each management entry corresponds to a permission check transaction and is used to store the transaction itself and the permission check processing status (i.e., transaction status). This example can achieve parallel management of a total of 256 transactions through this design.

[0144] After receiving a permission check transaction request (trans_req), the system will allocate a free entry and a unique number to the transaction to manage the state generated by the transaction in subsequent processing; the allocated transaction will use the entry number as the unique ID for subsequent processing (ety0~ety255). After a transaction completes entry allocation, the corresponding entry is flipped to a valid state, and the transaction state within the entry is synchronously updated to the idle state (IDLE). After one cycle, the transaction's request (trans_req) is read into the cacheif module to perform a three-level MTT cache parallel lookup. The transaction state then flips to the cache lookup state (CACHE_LKP) to indicate that the transaction is currently in the cache lookup phase. The three-level cache sub-modules (mttl3_lookup logic, mttl2_lookup logic, and mttl1_lookup logic) in the cacheif module send read requests in parallel to the corresponding mttl3_cache, mttl2_cache, and mttl1_cache, and receive the read data returned by the corresponding mttl3_cache, mttl2_cache, and mttl1_cache in parallel, and then perform a cache hit determination. There are four possible cache hit results from the cacheif module:

[0145] The first scenario is a cache miss, in which the transaction request is output to mttl3_proc_logic via the miss channel;

[0146] The second method is an MTTL3 cache hit, where the valid content found in the MTTL3 cache is output to mttl3_proc_logic through the hit channel;

[0147] The third method is an MTTL2 cache hit, where the valid content found in the MTTL2 cache is output to mttl2_proc_logic through the hit channel;

[0148] The fourth type is an MTTL1 cache hit, where the valid content found in the MTTL1 cache is output to mttl1_proc_logic via the hit channel.

[0149] The following examples illustrate the follow-up processing for different hit results.

[0150] Example 1:

[0151] When none of the `mttl3_lookup`, `mttl2_lookup`, and `mttl1_lookup` logics hit their respective caches (`mttl3_cache`, `mttl2_cache`, and `mttl1_cache`, respectively), the transaction request will be output to `mttl3_proc_logic` via the miss channel. Upon receiving the transaction request, `mttl3_proc_logic` issues a table lookup request (`ptw_req`) and simultaneously flips the transaction status in the entry to the MTTL3 lookup status (`L3_PTW_SEND`). The system responds to the table lookup request from `mttl3_proc_logic` by executing the first-level table lookup (i.e., the MTTL3 lookup). The MTTL3 lookup process accesses the MTTL3 table entries based on the MTTL3 base address and offset address (pn[3] in the physical address) and finally obtains the PPN corresponding to the MTTL2 page table. The PPN will be returned to mttl3_proc_logic through the lookup response (ptw_rsp). After receiving it, mttl3_proc_logic generates an MTTL2 lookup request (l2_lookup_req) and sends it to mttl2_proc_logic.

[0152] Next, mttl2_proc_logic responds to the MTTL2 lookup request (l2_lookup_req) from mttl3_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL2 lookup state (L2_PTW_SEND); the system responds to the lookup request (ptw_req) from mttl2_proc_logic and executes the second-level lookup (i.e., the MTTL2 lookup). During the MTTL2 table lookup process, the result (PPN) obtained from the MTTL3 table lookup is used as the base address, and the pn[2] value in the physical address is used as the offset address to access the MTTL2 table entry and finally obtain the MTTL2 table lookup result. This table lookup result will be returned to mttl2_proc_logic through the table lookup response (ptw_rsp). After receiving it, mttl2_proc_logic will determine that the result is the physical page number (PPN) corresponding to the MTTL1 page table. Therefore, the table lookup is required again, and an MTTL1 table lookup request (l1_lookup_req) will be generated and sent to mttl1_proc_logic.

[0153] Subsequently, mttl1_proc_logic responds to the MTTL1 lookup request (l1_lookup_req) from mttl2_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL1 lookup state (L1_PTW_SEND); the system responds to the lookup request (ptw_req) from mttl1_proc_logic and executes the third-level lookup (i.e., MTTL1 lookup). During the MTTL1 lookup process, the result (PPN) obtained from the MTTL2 lookup is used as the base address, and the pn[1] value in the physical address is used as the offset address to access the MTTL1 table entry, and finally obtain the MTTL1 lookup result, which is the access permission of the physical address.

[0154] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0155] It should be noted that each level of the table request (ptw_req) carries a transaction ID. The system can retrieve the transaction status from the entry based on the transaction ID, and thus determine the table level that the transaction needs to execute. Similarly, each level of the table response (ptw_rsp) carries a transaction ID. The system can retrieve the transaction status from the entry based on the transaction ID, determine the corresponding table level for the response, and thus pass the ptw_rsp through... Figure 10The ptw_rsp_route channel in the middle routes to the corresponding level of logic processing submodule (mttl3_proc_logic, mttl2_proc_logic or mttl1_proc_logic).

[0156] In addition, the results obtained from the MTTL3 table are written to the corresponding mttl3_cache, the results obtained from the MTTL2 table are written to the corresponding mttl2_cache, and the results obtained from the MTTL1 table are written to the corresponding mttl1_cache.

[0157] Example 2:

[0158] When none of the `mttl3_lookup`, `mttl2_lookup`, and `mttl1_lookup` logics hit their respective caches (`mttl3_cache`, `mttl2_cache`, and `mttl1_cache`, respectively), the transaction request will be output to `mttl3_proc_logic` via the miss channel. Upon receiving the transaction request, `mttl3_proc_logic` issues a table lookup request (`ptw_req`) and simultaneously flips the transaction status in the entry to the MTTL3 lookup status (`L3_PTW_SEND`). The system responds to the table lookup request from `mttl3_proc_logic` by executing the first-level table lookup (i.e., the MTTL3 lookup). The MTTL3 lookup process accesses the MTTL3 table entries based on the MTTL3 base address and offset address (pn[3] in the physical address) and finally obtains the PPN corresponding to the MTTL2 page table. The PPN will be returned to mttl3_proc_logic through the lookup response (ptw_rsp). After receiving it, mttl3_proc_logic generates an MTTL2 lookup request (l2_lookup_req) and sends it to mttl2_proc_logic.

[0159] Next, mttl2_proc_logic responds to the MTTL2 lookup request (l2_lookup_req) from mttl3_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL2 lookup state (L2_PTW_SEND); the system responds to the lookup request (ptw_req) from mttl2_proc_logic and executes the second-level lookup (i.e., MTTL2 lookup). During the MTTL2 lookup process, the result (PPN) obtained from the MTTL3 lookup is used as the base address, and the pn[2] value in the physical address is used as the offset address to access the MTTL2 table entry, and finally obtain the MTTL2 lookup result. This lookup result will be returned to mttl2_proc_logic through the lookup response (ptw_rsp). After receiving it, mttl2_proc_logic determines that the result is the access permission of the physical address, so no further lookup is needed.

[0160] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0161] In addition, the results obtained from the MTTL3 walkthrough are written to the corresponding mttl3_cache, and the results obtained from the MTTL2 walkthrough are written to the corresponding mttl2_cache.

[0162] Example 3:

[0163] When the mttl3_lookup logic hits the corresponding cache mttl3_cache, but the other two levels of cache do not, the mttl3_lookup logic extracts the valid content from the mpte field of the hit entry. This valid content carries the PPN corresponding to the MTTL2 page table. The mttl3_proc_logic generates an MTTL2 lookup request (l2_lookup_req) based on the PPN and sends it to the mttl2_proc_logic.

[0164] Next, mttl2_proc_logic responds to the MTTL2 lookup request (l2_lookup_req) from mttl3_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL2 lookup state (L2_PTW_SEND); the system responds to the lookup request from mttl2_proc_logic and executes the second-level lookup (i.e., MTTL2 lookup). During the MTTL2 table lookup process, the result (PPN) obtained from the MTTL3 table lookup is used as the base address, and the pn[2] value in the physical address is used as the offset address to access the MTTL2 table entry and finally obtain the MTTL2 table lookup result. This table lookup result will be returned to mttl2_proc_logic through the table lookup response (ptw_rsp). After receiving it, mttl2_proc_logic will determine that the result is the physical page number (PPN) corresponding to the MTTL1 page table. Therefore, the table lookup is required again, and an MTTL1 table lookup request (l1_lookup_req) will be generated and sent to mttl1_proc_logic.

[0165] Subsequently, mttl1_proc_logic responds to the MTTL1 lookup request (l1_lookup_req) from mttl2_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL1 lookup state (L1_PTW_SEND); the system responds to the lookup request from mttl1_proc_logic and executes the third-level lookup (i.e., MTTL1 lookup). During the MTTL1 lookup process, the result (PPN) obtained from the MTTL2 lookup is used as the base address, and the pn[1] value in the physical address is used as the offset address to access the MTTL1 table entry, and finally obtain the MTTL1 lookup result, which is the access permission of the physical address.

[0166] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0167] In addition, the results obtained from the MTTL2 table will be written to the corresponding mttl2_cache, and the results obtained from the MTTL1 table will be written to the corresponding mttl1_cache.

[0168] Example 4:

[0169] When the mttl3_lookup logic hits the corresponding cache mttl3_cache, but the other two levels of cache do not, the mttl3_lookup logic extracts the valid content from the mpte field of the hit entry. This valid content carries the PPN corresponding to the MTTL2 page table. The mttl3_proc_logic generates an MTTL2 lookup request (l2_lookup_req) based on the PPN and sends it to the mttl2_proc_logic.

[0170] Next, mttl2_proc_logic responds to the MTTL2 lookup request (l2_lookup_req) from mttl3_proc_logic, and simultaneously flips the transaction state in the entry to the MTTL2 lookup state (L2_PTW_SEND), and issues a lookup request (ptw_req); the system responds to the lookup request from mttl2_proc_logic and executes the second-level lookup (i.e., MTTL2 lookup). During the MTTL2 lookup process, the result (PPN) obtained from the MTTL3 lookup is used as the base address, and the pn[2] value in the physical address is used as the offset address to access the MTTL2 table entry, and finally obtain the MTTL2 lookup result. This lookup result will be returned to mttl2_proc_logic through the lookup response (ptw_rsp). After receiving it, mttl2_proc_logic judges and confirms that the result is the access permission of the physical address, so no further lookup is needed.

[0171] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0172] In addition, the results obtained from the MTTL2 lookup table above will be written to the corresponding mttl2_cache.

[0173] Example 5:

[0174] When the mttl2_lookup logic hits the corresponding cache mttl2_cache, but the mttl1_lookup logic does not hit mttl1_cache, the mttl2_lookup logic extracts the valid content from the mpte field of the hit entry. After judgment, it is confirmed that the valid content is the PPN corresponding to the MTTL1 page table. The mttl2_proc_logic generates an MTTL1 table lookup request (l1_lookup_req) based on the PPN and sends it to the mttl1_proc_logic.

[0175] Next, mttl1_proc_logic responds to the MTTL1 lookup request (l1_lookup_req) from mttl2_proc_logic, issues a lookup request (ptw_req), and simultaneously flips the transaction state in the entry to the MTTL1 lookup state (L1_PTW_SEND); the system responds to the lookup request from mttl1_proc_logic and executes the third-level lookup (i.e., MTTL1 lookup). During the MTTL1 lookup process, the result (PPN) obtained from the MTTL2 lookup is used as the base address, and the pn[1] value in the physical address is used as the offset address to access the MTTL1 table entry, and finally obtain the MTTL1 lookup result, which is the access permission of the physical address.

[0176] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0177] In addition, the results obtained from the MTTL1 lookup table will be written to the corresponding mttl1_cache.

[0178] Example 6:

[0179] When the mttl2_lookup logic hits the corresponding cache mttl2_cache, but the mttl1_lookup logic does not hit mttl1_cache, the mttl2_lookup logic extracts the valid content from the mpte field of the hit entry, and after judgment, confirms that the valid content is the access permission of the physical address, so there is no need to follow up with the table.

[0180] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0181] Example 7:

[0182] When the mttl1_lookup logic hits the corresponding cache mttl1_cache, it extracts the valid content from the mpte field of the hit entry. This valid content is the access permission of the physical address.

[0183] Access permissions for physical addresses are checked through the transaction response (trans_rsp) channel output and the unique ID number corresponding to the transaction is released, and the entry is flipped to invalid.

[0184] In the example shown in Figure 10, the system implements parallel management of multiple transactions through entry groups. Since each transaction may be at a different level in the table-running process, table-running requests (ptw_req) may be issued simultaneously from mttl3_proc_logic, mttl2_proc_logic, and mttl1_proc_logic. Therefore, an arbitration module (arbiter) is needed to arbitrate the table-running requests (ptw_req) from multiple transactions. After a table-running request (ptw_req) is issued, the system internally refreshes the transaction status (L1_PTW_SEND, L2_PTW_SEND, L3_PTW_SEND) of the corresponding entry to indicate which level of table-running process the transaction is currently in. This process uses unique ID numbers for matching.

[0185] exist Figure 10 In the example, the access permissions for the physical address may be output from either the mttl2_lookup logic or the mttl1_lookup logic. The access permissions are carried in the response message (trans_rsp) of the permission check transaction. If response messages (trans_rsp) of different transactions are output from both the mttl2_lookup logic and the mttl1_lookup logic at the same time, for example, the response message (trans_rsp) of transaction A is output from the mttl2_lookup logic, while the response message (trans_rsp) of transaction B is output from the mttl1_lookup logic, the arbiter module needs to arbitrate the response messages (trans_rsp) of multiple permission check transactions before outputting them.

[0186] Specifically, after receiving a `ptw_rsp` response carrying a unique ID and the result of the table lookup, the system matches the entry based on the unique ID, determines the page table level of the lookup result based on the entry status, and routes the `ptw_rsp` to `ptw_rsp_route`, which then transmits it to the corresponding `mttl3_proc_logic`, `mttl2_proc_logic`, or `mttl1_proc_logic` for processing. In `mttl3_proc_logic` and `mttl2_proc_logic`, the page table content might indicate that further lookup is needed. For example, `mttl3_proc_logic` might send an `l2_lookup_req` request to `mttl2_proc_logic`, and `mttl2_proc_logic` might send an `l1_lookup_req` request to `mttl1_proc_logic`. For page tables capable of determining transaction permissions, there are three scenarios: 1GB, 2MB, and 4KB pages. These are handled in `mttl2_proc_logic` and `mttl1_proc_logic` respectively, with the final arbitration output to `trans_rsp`. After `trans_rsp` completes its output, the transaction status information within the entry corresponding to the unique ID number is flipped to IDLE, and the entry is invalidated.

[0187] In this embodiment of the application, the arbitration module (arbiter) can use a polling method to arbitrate the above-mentioned multi-transaction table walk request (ptw_req) and permission check transaction response (trans_rsp) respectively.

[0188] Please see Figure 11 This is a schematic diagram illustrating an entry state flipping method provided in an embodiment of this application. Figure 11 As shown, when a table request (ptw_req) is initiated, the system will internally flip the transaction status of the corresponding entry (marked as L1_PTW_SEND, L2_PTW_SEND, and L3_PTW_SEND respectively) to identify the table level of the current transaction. The above status matching is achieved through a unique identifier (ID).

[0189] When the system receives the table routing response (ptw_rsp), it matches the corresponding entry using a unique ID, determines the page table level corresponding to the routing result based on the transaction status recorded in the entry, and routes ptw_rsp to the table routing response routing module (ptw_rsp_route), which then distributes it to the mttl3_proc_logic, mttl2_proc_logic, and mttl1_proc_logic modules for subsequent processing. Within the mttl3_proc_logic and mttl2_proc_logic modules, if the page table parsing result determines that the table routing process needs to continue, the mttl3_proc_logic module will initiate a second-level lookup request (l2_lookup_req) to the mttl2_proc_logic module, and the mttl2_proc_logic module will initiate a first-level lookup request (l1_lookup_req) to the mttl1_proc_logic module.

[0190] For page tables that support transaction permission determination, the system supports three page size configurations: 1G, 2M, and 4K. The permission determination and table access process are completed in the mttl2_proc_logic module (corresponding to 1G / 2M pages) and the mttl1_proc_logic module (corresponding to 4K pages), respectively, and finally output to the transaction response (trans_rsp) after arbitration. After trans_rsp completes its output, the system sets the transaction status of the corresponding unique ID entry to IDLE and invalidates the entry.

[0191] Throughout the transaction processing flow, the transmission between transactions adopts a serial pipeline mechanism, thereby improving transaction processing efficiency. Without considering internal blocking scenarios (such as cache updates, downstream backpressure, etc.), the minimum processing cycle within a single transaction is 6 clock cycles, specifically allocated as follows: entry allocation and reading occupy 2 clock cycles, cache lookup and determination occupy 2 clock cycles, and processing and transmission after a permission page table hit occupy 2 clock cycles. The maximum processing cycle within a single transaction is (10 + 3T) clock cycles: if a cache miss occurs, in addition to the above 4 clock cycles, the time for constructing and responding to the page table requests at each of the 3 levels must be added (2 clock cycles for each level); simultaneously, the transmission time of each level of page table on the System-on-Chip (SoC) path is represented by "T", which is the number of clock cycles required from the issuance of a single-level page table request to the return of the page table response.

[0192] This application's embodiments are based on the RISC-V SMMTT standard specification, which primarily addresses the issues of the inability to implement differentiated trust models across multiple supervisor domains and the difficulty in distinguishing access permissions for physical content across different supervisor domains under the RISC-V architecture. Therefore, while hardware-izing the standard content, and considering performance, maintenance, and testing design requirements, the method and system proposed in this application's embodiments can achieve granular permission isolation for secure access to device memory pages based on the RISC-V architecture, specifically including the following two aspects:

[0193] Firstly, a three-level page table cache parallel lookup design is adopted: In the SMMTT standard specification, access initiated by devices in different Supervisor domains on the IO side needs to search for page tables in memory according to a three-level table lookup pattern (the page table contains information such as the base address of the next-level page table and memory access permissions). To accelerate this process, this application embodiment designs a three-level page table parallel caching strategy. The IO side device transaction will simultaneously determine whether it hits the cache of the three-level page table, and then perform subsequent processing based on the hit result.

[0194] Secondly, a combined serial and parallel permission check transaction flow processing design is adopted: To improve the processing performance of permission check transaction flows, this application's embodiment adopts a design scheme of serial pipelined transaction processing and parallel arbitration. Each transaction is equipped with an independent state transition storage entry, which is responsible for managing the entire lifecycle of the transaction. Through this design, the system can support the lifecycle management of permission check transactions initiated by up to 256 IO-side devices; a single transaction can complete the permission check process in as little as 6 clock cycles, and in the slowest case, it requires 10+3T clock cycles (where "T" is the number of clock cycles from the issuance of a single-level table request to the return of the page table response).

[0195] Please see Figure 12 This application also provides an electronic device 1000, which includes: at least one processor 1010; at least one memory 1020 for storing at least one program; the at least one program is executed by at least one processor 1010 to implement the memory access permission acquisition method of any of the foregoing embodiments.

[0196] The processor 1010 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0197] The memory 1020 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 1020 described in this application embodiment is intended to include any suitable type of memory. The memory 1020 may optionally include one or more storage devices physically located away from the processor 1010.

[0198] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the memory access permission acquisition method described above in this application.

[0199] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs. When the computer-executable instructions or computer programs are executed by a processor, the processor will execute the memory access permission acquisition method provided in this application.

[0200] In some embodiments of this application, the computer-readable storage medium may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic surface memory, optical disk, or CD-ROM, etc.; or it may be various devices including one or any combination of the above-mentioned memories.

[0201] In some embodiments of this application, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0202] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0203] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0204] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A memory access permission acquisition method characterized by comprising: The method includes: In response to receiving an access control transaction, a management entry and a unique entry number are assigned to the access control transaction. The management entry is used to store the access control transaction and its transaction status. The access control transaction includes a management domain identifier and the physical address accessed. The management domain flag and the physical address are input into multiple lookup logic sub-modules. The multiple lookup logic sub-modules execute the corresponding level of MTT cache lookup operation in parallel and output the corresponding level of MTT cache hit result in parallel. The physical address memory access permission is obtained directly based on the MTT cache hit results at all levels, or at least one level of table lookup operation is performed to obtain the memory access permission. The process of the table-running operation includes: Send a table-running request to the corresponding level table-running module. The table-running request carries the unique entry number and page table base address of the permission-checked transaction. The table-running module performs a table-running operation based on the unique entry number and page table base address of the permission-checked transaction, thereby updating the transaction status of the permission-checked transaction. Return the table walkthrough response, which carries the unique entry number of the permission check transaction and the table walkthrough result; Based on the unique entry number in the table routing response, the level corresponding to the table routing result is determined, and the table routing result is routed to the corresponding level of the table routing processing module, so that the corresponding level of the table routing processing module outputs memory access permissions or initiates a table routing request for the next level of table routing operation based on the table routing result.

2. The method of claim 1, wherein, The method of directly obtaining memory access permissions for physical addresses based on MTT cache hit results at all levels, or performing at least one level of lookup table operations to obtain the memory access permissions, includes: If an MTTL1 cache hit occurs, memory access permissions are obtained from the memory page table entry in the MTTL1 cache.

3. The method of claim 1, wherein, The method of directly obtaining memory access permissions for physical addresses based on MTT cache hit results at all levels, or performing at least one level of lookup table operations to obtain the memory access permissions, includes: If there is a cache miss in MTTL1 but a cache hit in MTTL2, one of the following actions is performed based on the memory page table entry in the MTTL2 cache: Obtain memory access permissions from the memory page table entries in the MTTL2 cache; Alternatively, the base address of the MTTL1 page table can be obtained from the memory page table entry in the MTTL2 cache, and a table lookup operation can be performed on the MTTL1 page table based on the base address of the MTTL1 page table and the first offset address in the physical address to obtain memory access permissions.

4. The method according to claim 1, characterized in that, The method of directly obtaining memory access permissions for physical addresses based on MTT cache hit results at all levels, or performing at least one level of lookup table operations to obtain the memory access permissions, includes: If neither MTTL1 nor MTTL2 cache is hit, but MTTL3 cache is hit, the base address of the MTTL2 page table is obtained from the memory page table entry in the MTTL3 cache. Based on the base address of the MTTL2 page table and the second offset address in the physical address, a table lookup operation is performed on the MTTL2 page table to obtain memory access permissions.

5. The method according to claim 4, characterized in that, Based on the MTTL2 page table base address and the second offset address in the physical address, a table lookup operation is performed on the MTTL2 page table to obtain memory access permissions, including one of the following: Based on the MTTL2 page table base address and the second offset address in the physical address, perform a table lookup operation on the MTTL2 page table to obtain memory access permissions from the MTTL2 page table; or, Based on the MTTL2 page table base address and the second offset address in the physical address, a table lookup operation is performed on the MTTL2 page table to obtain the MTTL1 page table base address. Based on the MTTL1 page table base address and the first offset address in the physical address, a table lookup operation is performed on the MTTL1 page table to obtain memory access permissions from the MTTL1 page table.

6. The method according to claim 1, characterized in that, The method of directly obtaining memory access permissions for physical addresses based on MTT cache hit results at all levels, or performing at least one level of lookup table operations to obtain the memory access permissions, includes: If there is no cache miss in MTTL1, MTTL2, and MTTL3, at least two levels of cache lookup operations are performed based on the physical address and the MTTL3 page table base address to obtain memory access permissions.

7. The method according to claim 6, characterized in that, Also includes: The memory page table entries obtained from each level of page table lookup operation are written into the corresponding level of cache entries. The memory page table entries are the base address of the next level page table or memory access permissions.

8. The method according to claim 1, characterized in that, The MTT cache includes an MTTL3 cache, which comprises multiple cache entries, each including: A validity flag is used to identify whether a cached entry is valid; Management domain identifier, used to identify the management domain; A memory page table entry is used to store the valid content of an MTTL3 entry in memory. Parity check bit.

9. The method according to claim 8, characterized in that, The MTTL3 cache is implemented using registers.

10. The method according to claim 1, characterized in that, The MTT cache lookup operation includes an MTTL3 cache lookup operation; the MTTL3 cache lookup operation includes: Index the target cache entry in the MTTL3 cache based on the third bit segment of the physical address; If the target cache entry satisfies the first condition, the MTTL3 cache is considered to have been hit; The first condition includes: The valid flag in the target cache entry indicates that the cache entry is valid; The permission check determines whether the management domain to which the transaction belongs matches the management domain flag in the target cache entry.

11. The method according to claim 1, characterized in that, The MTT cache includes an MTTL2 cache, which comprises multiple cache entries, each including: A tag is used to store the second bit segment of the physical address, which is used to match the physical address of the permission check transaction; A memory page table entry is used to store the valid content of an MTTL2 table entry in memory. Tag verification bit; Memory page table entry check bits.

12. The method according to claim 1, characterized in that, The MTT cache lookup operation includes an MTTL2 cache lookup operation; the MTTL2 cache lookup operation includes: Index the target cache entry in the MTTL2 cache based on the fourth bit segment of the physical address; If the target cache entry satisfies the second condition, the MTTL2 cache is considered to have hit; The second condition includes: The valid flag corresponding to the target cache entry indicates that the cache entry is valid; The second bit segment of the physical address matches the tag in the target cache entry; The permission check ensures that the management domain to which the transaction belongs matches the management domain flag corresponding to the target cache entry; Tag verification bit matching successful; The memory page table entry checksum comparison was successful.

13. The method according to claim 12, characterized in that, The MTTL2 cache includes multiple entry groups, and each entry group includes multi-way entries; Based on the fourth bit segment of the physical address, the target cache entry is indexed in the MTTL2 cache, including: The group index is obtained by performing an XOR operation on the fourth bit segment of the physical address; The target entry group is indexed in the MTTL2 cache according to the group index, and the target cache entry is searched in the multi-way entry corresponding to the target entry group.

14. The method according to claim 1, characterized in that, The MTT cache includes an MTTL1 cache, which comprises multiple cache entries, each including: A tag is used to store the first bit segment of the physical address, which is used to match the physical address of the permission check transaction; A memory page table entry is used to store the valid content of an MTTL1 entry in memory. Tag verification bit; Memory page table entry check bits.

15. The method according to claim 1, characterized in that, The MTT cache lookup operation includes an MTTL1 cache lookup operation; the MTTL1 cache lookup operation includes: Index the target cache entry in the MTTL1 cache based on the fifth bit segment of the physical address; If the target cache entry satisfies the third condition, the MTTL1 cache is considered to have been hit; The third condition includes: The valid flag corresponding to the target cache entry indicates that the cache entry is valid; The first bit segment of the physical address matches the tag in the target cache entry; The permission check ensures that the management domain to which the transaction belongs matches the management domain flag corresponding to the target cache entry; Tag verification bit matching successful; The memory page table entry checksum comparison was successful.

16. The method according to claim 15, characterized in that, The MTTL1 cache includes multiple entry groups, and each entry group includes multi-way entries; Based on the fifth bit segment of the physical address, the target cache entry is indexed in the MTTL1 cache, including: The group index is determined based on the fifth bit segment of the physical address; The target entry group is indexed in the MTTL1 cache according to the group index, and the target cache entry is searched in the multi-way entry corresponding to the target entry group.

17. The method according to claim 1, characterized in that, The method also includes performing one of the following operations on any level of MTT cache: Set all valid flags corresponding to cache entries to invalid values; or, Set the valid flags corresponding to all cache entries associated with one or more of the management domains to invalid values.

18. The method according to claim 1, characterized in that, The MTT cache includes an MTTL2 cache and an MTTL1 cache. Both the MTTL2 cache and the MTTL1 cache have corresponding valid flags, which are stored in separate RAM or register groups.

19. The method according to claim 1, characterized in that, The number of management entries is multiple, and each management entry corresponds to one permission check transaction.

20. The method according to claim 19, characterized in that, If the hit result is one of the following, then perform at least one level of lookup table operation to obtain memory access: The MTTL1 cache was not hit, while the MTTL2 cache hit the MTTL1 page table base address; Alternatively, if both MTTL1 and MTTL2 caches are not hit, but MTTL3 cache hits the MTTL2 page table base address; Alternatively, all three caches (MTTL1, MTTL2, and MTTL3) were not hit.

21. The method according to claim 20, characterized in that, The transaction state is one of the following: idle state; cache lookup state; MTTL3 table-running state; MTTL2 table-running state; MTTL1 table-running state.

22. The method according to claim 21, characterized in that, The table processing module includes an MTTL3 table processing module, an MTTL2 table processing module, or an MTTL1 table processing module. Before sending the timetable request to the corresponding timetable processing module, the following steps are also included: Based on the unique entry number, obtain the permission from the management entry to check the transaction status of the transaction; The level of the table processing module that receives the table request is determined based on the transaction status.

23. The method according to claim 22, characterized in that, The method further includes: In the event of a conflict between multiple table-running requests for the permission check transactions, the multiple table-running requests are arbitrated to determine the priority of each table-running request. The table-running operations for each of the permission check transactions are processed according to the stated priority.

24. The method according to claim 22, characterized in that, The method further includes: In the event of a conflict between the permission check transaction response messages output by the MTTL2 and MTTL1 transaction processing modules, arbitration is performed on the response messages output by the MTTL2 and MTTL1 transaction processing modules respectively to determine the priority of each response message. The response message is output according to the priority.

25. The method according to claim 19, characterized in that, After determining memory access permissions, the method further includes: Release the permission to check the unique entry number corresponding to the transaction, and flip the management entry to an invalid state.

26. The method according to claim 19, characterized in that, The method further includes: If all of the management entries are occupied by the permission check transaction, block the reception of new permission check transactions.

27. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; The memory access permission acquisition method of any one of claims 1 to 26 is implemented when at least one of the programs is executed by at least one of the processors.

28. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the memory access permission acquisition method according to any one of claims 1 to 26.

29. A computer program product comprising a computer program or computer-executable instructions, characterized in that, The computer program or the computer-executable instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer program or the computer-executable instructions from the computer-readable storage medium. The processor executes the computer program or the computer-executable instructions, causing the electronic device to perform the memory access permission acquisition method according to any one of claims 1 to 26.

Images