Apparatus and method for controlling access to a memory system

Abstract

An apparatus (2) has memory management circuitry (16, 20) for controlling access to a memory system based on access control information defined in table entries of a table structure comprising at least two levels of access control tables. Table access circuitry (17), (23) accesses the table structure to obtain the access control information corresponding to a target address. For a given access control table at a given level of the table structure other than a start level, the table access circuitry (17, 23) selects a selected table entry of the given access control table corresponding to the target address based on an offset portion of the target address. A size of the offset portion is selected based on a variable nesting control parameter (190) specified in a table entry of a higher level access control table at a higher level of the table structure than the given access control table.

Description

Background Technology

[0001] This technology relates to the field of data processing. More specifically, this technology relates to memory management.

[0002] The data processing system may have a memory management circuitry system that controls access to the memory system based on access control information defined in table entries of the table structure.

[0003] At least some examples provide an apparatus comprising: a memory management circuitry system configured to control access to a memory system based on access control information defined in table entries of a table structure comprising multiple levels of access control tables; and a table access circuitry system configured to access the table structure to obtain the access control information corresponding to a target address; wherein: for a given access control table at a given level of the table structure other than the starting level: the table access circuitry system is configured to select a selected table entry of the given access control table corresponding to the target address based on an offset portion of the target address, the selected table entry providing a pointer to an access control table at the next lowest level of the table structure or the access control information corresponding to the target address; and the table access circuitry system is configured to determine the size of the offset portion of the target address based on variable nesting control parameters specified in table entries of a higher-level access control table at a higher level than the given access control table in the table structure.

[0004] At least some examples provide a method comprising: controlling access to a memory system based on access control information defined in table entries of a table structure comprising multiple levels of access control tables; and accessing the table structure to obtain the access control information corresponding to a target address; wherein: for a given access control table at a given level of the table structure other than the starting level: selecting a selected table entry of the given access control table corresponding to the target address based on an offset portion of the target address, the selected table entry providing a pointer to an access control table at the next lowest level of the table structure or the access control information corresponding to the target address; and determining the size of the offset portion of the target address based on variable nesting control parameters specified in table entries of a higher-level access control table at a higher level than the given access control table in the table structure.

[0005] At least some examples provide a computer program comprising instructions that, when executed on a host data processing device, control the host data processing device to provide an instruction execution environment for executing target code; the computer program comprising: memory management program logic for controlling access to simulated memory based on access control information defined in table entries of a table structure comprising multiple levels of access control tables; and table access program logic for accessing the table structure to obtain the access control information corresponding to an address of the target simulated memory; wherein: for a given access control table at a given level of the table structure other than the starting level: the table access program logic is configured to select a selected table entry of the given access control table corresponding to the address of the target simulated memory based on an offset portion of the address of the target simulated memory, the selected table entry providing a pointer to an access control table at the next lowest level of the table structure or the access control information corresponding to the address of the target simulated memory; and the table access program logic is configured to determine the size of the offset portion of the address of the target simulated memory based on variable nesting control parameters specified in table entries of a higher-level access control table at a higher level than the given access control table in the table structure.

[0006] At least some examples provide a computer-readable storage medium that stores the aforementioned computer program. This storage medium may be a non-transitory storage medium. Attached Figure Description

[0007] Further aspects, features, and advantages of this technology will become apparent from the following description of an example read in conjunction with the accompanying drawings, in which:

[0008] Figure 1 An example of a data processing device is shown;

[0009] Figure 2 Multiple domains in which the processing circuitry system can operate are shown;

[0010] Figure 3 An example of a processing system that supports particle protection lookup is shown;

[0011] Figure 4 This schematically illustrates multiple physical address spaces as aliases on the system physical address space that identify locations within the memory system;

[0012] Figure 5 An example is shown of partitioning the effective hardware physical address space so that different architecture physical address spaces have access to the corresponding portions of the system physical address space;

[0013] Figure 6This is a flowchart illustrating a method for determining the current operating domain of a processing circuit system;

[0014] Figure 7 An example of the page table entry format used to translate virtual addresses into physical addresses is shown;

[0015] Figure 8 An example of a fixed-nested multi-level page table structure with page tables is shown;

[0016] Figure 9 This is a flowchart illustrating a method for selecting the physical address space to be accessed by a given memory access request;

[0017] Figure 10 This is a flowchart illustrating a method for filtering memory access requests based on whether the selected physical address space associated with the request is defined as the allowed physical address space in the particle protection information corresponding to the target physical address defined in the particle protection table structure.

[0018] Figure 11 An example of a table entry for a particle protection table, including table descriptor entries and block descriptor entries, is shown;

[0019] Figure 12 An example of a conceptual layout for a multi-stage particle-protected cable is shown, illustrating an example with variable nesting based on nested control parameters defined in higher-level table entries;

[0020] Figure 13 This is a flowchart illustrating a method for obtaining access control information for a specific target address by accessing a granular protection table based on variable nested control parameters;

[0021] Figure 14 An example is shown that uses a shared access control information set to represent access control information for adjacent blocks of adjacent granules for addresses; and

[0022] Figure 15 An example simulator is shown. Detailed Implementation

[0023] The data processing system may have a memory management circuitry and a table access circuitry. The memory management circuitry controls access to the memory system based on access control information defined in table entries within a table structure having two or more levels of access control tables. The table access circuitry accesses the access control information corresponding to a target address. The access control information can be any information used to control how a given address region is accessed or to control whether access to those regions is fully permitted. While such linearly indexed access control information based on target addresses can be defined in a single-level access control table, this linearly indexed table may be inefficient in terms of memory usage of the table data itself when the address space to be defined by the access control information becomes larger. Therefore, it is necessary to reserve a single adjacency region of memory for the table, the size of which is proportional to the size of the address range to be protected by the table.

[0024] To utilize address space more efficiently (reducing the amount of memory allocated to tables), multi-level access control tables are known to be defined. In each level, a portion of the offset bits extracted from the target address selects the entry for the table at that level. If the current level is not the last level, the entry at that level provides a pointer to the access control table at the next lowest level of the table structure. This process continues until the final level of the table is reached after traversing all levels of the table structure. The entry selected based on the offset portion of the target address at that level provides the access control information corresponding to the target address. Compared to the method described above using a single, linearly indexed planar table, this method allows access control information for a number of address regions distributed across a wider range of address space to be protected to be implemented using a smaller memory footprint of the table data itself. However, multi-level tables can degrade performance because obtaining access control information for a specific target address may require multiple memory accesses to traverse the various levels of the table structure to obtain several pointers to the access control table at the next level before finally identifying the access control information.

[0025] Typically, for multi-level access control lists, the nesting of tables at different levels in the control list structure is fixed by design, such that the maximum number of levels to be traversed to reach the entry that provides the actual access control information, the size of the table at each level, and the size of the offset portion used to index the target address at each level are all fixed.

[0026] In contrast, in the example described below, variable nesting control parameters can be specified in the table entries of higher-level access control tables, providing variable control over how the lower-level offset portions of the table structure are formed. Therefore, for a given access control table at a given level of the table structure other than the starting level: the table access circuitry selects a chosen table entry for the given access control table corresponding to the target address based on the offset portion of the target address (the chosen table entry provides a pointer to the access control table at the next lowest level of the table structure or access control information corresponding to the target address), and the table access circuitry determines the size of the offset portion of the target address based on the variable nesting control parameters specified in the table entries of higher-level access control tables that are higher than the given access control table in the table structure.

[0027] This approach provides flexibility in balancing table memory footprint and performance when accessing a table by allowing the size of the offset portion used to select an entry from a given level of access control table to dynamically change based on parameters specified in higher-level table entries (which will be accessed earlier in the path taken to traverse the table structure to reach the given access control table). Therefore, the offset size also depends on the parameters read from earlier access control tables, rather than using a fixed-size offset that depends only on the level of the table structure. Thus, if performance is more important than memory efficiency, nesting can be adjusted to use a larger offset portion for a given level of the table structure, causing the bits of the target address to be consumed in fewer levels, thereby allowing the access control information for the target address to reside in fewer memory accesses. On the other hand, if the priority is to provide a more efficient memory footprint for the table, nesting control parameters can be defined in higher-level access control tables to control the table access circuitry to select a smaller offset for a given level of the table, causing a larger number of levels of the table structure to be traversed to reach the access control information for the target address, thereby allowing for a more segmented allocation of memory for table data with a smaller overall table footprint in memory.

[0028] Variable nested control parameters can be specified individually in the corresponding entries of higher-level access control tables. This means that different entries in higher-level access control tables can specify different values ​​for the variable nested control parameters. Therefore, when different entries in higher-level access control tables exist that specify different values ​​for the variable nested control parameters, the table access circuitry system can use different sized offset portions for different access control tables at the same level of the table structure when selecting an entry from the access control table at a given level of the table structure. This is particularly useful because different regions of the address space may have different requirements regarding performance or memory footprint. Some parts of the address space may require the fastest possible access, while others may have more relaxed performance requirements, thus providing an opportunity to save table area. This trade-off is made more flexible by allowing the size of the offset portion used to select an entry from the access control table to be determined based on parameters extracted from earlier entries at higher levels of the table structure.

[0029] The table structure can be viewed as a tree structure, where the initial level table at the starting level forms the root of the tree, and each node of the tree branches into a separate path based on the corresponding pointer in the table's entry, ultimately reaching a leaf node that provides access control information. The offset portion of each level extracted from the target address can be seen as the specific path taken to select the appropriate leaf node through the tree structure to reach the target address.

[0030] Based on variable nesting control parameters, different parts of the tree structure can have different numbers of levels and different characteristics, rather than the uniform nested access control tables that are common throughout the table structure. Various characteristics of the table structure can be controlled based on variable nesting control parameters.

[0031] For example, the maximum number of levels in a table structure to be traversed to reach a table entry providing access control information for a target address can vary depending on variable nesting control parameters. This can be controlled based on the size of the offset portion selected at each level of the table—by dividing a given set of offset bits into fewer, larger portions, the maximum number of levels in the table structure can be less than if the set of offset bits were divided into a larger number of smaller portions. Similarly, since different higher-level table entries can specify different values ​​for the variable nesting control parameters, the maximum number of levels in the table structure can be different for different subtrees within the overall tree structure represented by the table structure. Note that although variable nesting control parameters can define the maximum number of levels in a table structure to be traversed, this does not necessarily mean that the table access circuitry will always need to traverse the specified maximum number of levels to reach the access control information. Entries at levels other than the last level corresponding to the specified maximum number of levels can be defined as block descriptor entries, which provide access control information for address blocks that can have a larger size than the address block for which the block descriptor table entry at the last level of the table structure originally defined the access control information.

[0032] Furthermore, the table size occupied by the table data of a given access control table at a given level of the table structure can be variable, depending on the variable nesting control parameters obtained from higher-level access control tables. Similarly, the table size depends on the size of the offset portion of the target address. The table size corresponds to the product of the size of a table entry and a power of 2, where the power of 2 corresponds to the number of bits used for the offset portion selected for a given level based on the variable nesting control parameters. When the device executes the software, the software will need to allocate an address range corresponding to the table size to store the table data of the corresponding table entry for a given access control table. Note that when a given access control table has a specific table size, this does not necessarily mean that a valid table entry has been allocated for each entry within the portion of memory allocated for that specific table size. However, the memory region of the defined table size will need to be reserved for the access control table because if any other data is stored within that range, that other data could potentially be read while the table access circuitry is traversing the table structure to identify access control information for a specific target address, potentially leading to incorrect processing of memory access requests in cases where data stored at the entry is misinterpreted as access control information. By using variable nesting control, the size of the table can be traded off at a given portion of the table structure. For memory regions where relatively large blocks of memory can be allocated in adjacent blocks, a given access control table in that portion of the table tree can be made larger to improve performance by allowing fewer hops between levels. In other portions of the memory space where memory is more segmented and there is not much space to allocate a single large table (or where the granularity of addresses that need to define access control information is too small to justify allocating a large table in memory), the variable nesting control parameters can be adjusted to provide smaller tables, which would require a larger number of levels to traverse.

[0033] For a given access control table at a given level of a table structure, each entry in that given access control table can define information applicable to an address range of a given address range size. That is, the given address range size refers to the size of a given range of target addresses, which is accessed against when traversing the table structure to find access control information for any target address within that given address range. The given address range size can also vary depending on variable nested control parameters specified in entries of higher-level access control tables. In other words, for a given level of a table structure, the size of the address range to which a single entry in that access control table applies can vary depending on parameters read from higher-level access control tables. This is unconventional because typically each level of a table defines a single, fixed address range size applicable to each level. Similarly, using variable nested control, an access control table at a given level of a table structure can define entries, each applicable to a given address range size, that differs from the given address range size of each entry in another access control table at the same given level of the table structure.

[0034] In some examples, variable nesting control parameters can be specified at any level of the table structure except the last level, allowing access control lists at levels other than the beginning level of the table structure to change how subsequent levels of the access control list are nested.

[0035] However, in other examples, the setting of the variable nesting control parameter can be limited to the initial level of the table structure. Therefore, the variable nesting control parameter can be specified in the table entry of the initial-level access control table at the initial level of the table structure, and this parameter can define how tables in the subtree under that particular initial-level table entry are nested for all subsequent levels. There may be no other parameters in the subsequent levels of the table structure that would differentiate the nesting from the nesting defined at the initial level. This approach may be more efficient for the control hardware logic circuitry implementing the table access circuitry system because the choice of the size and location of the offset portion for a given level can depend on fewer parameters (no need to combine nesting control parameters read from multiple levels of the table).

[0036] Table entries in a table structure can be categorized as block descriptor table entries that provide access control information to the corresponding target address block, or as table descriptor entries that provide pointers to access control tables at the next level of the table structure. As mentioned above, block descriptor table entries can be defined at any level of the table structure. If a block descriptor table entry is at a level different from the maximum allowed level defined by variable nesting control parameters, this means that the shared definition of access control information is shared by a larger memory address block compared to the case where the block descriptor table entry is at the last level corresponding to the maximum number of levels indicated based on variable nesting control parameters.

[0037] In one example, a block descriptor table entry may include multiple access control information fields, each indicating access control information for a different address granularity. Therefore, when a block descriptor table entry for a specific target address is reached, access control information for that specific target address can be extracted from a specific access control information field among two or more access control information fields within the block descriptor table entry. This approach can be useful if the amount of access control information that needs to be defined for each granularity is relatively small, allowing multiple sets of access control information to be packaged within a single memory location addressable in a single memory access translation. By packaging multiple access control information entries for different granularities into a single block descriptor table entry, the overall size of the table structure can be reduced.

[0038] In one example, the table format can support the ability to specify adjacency indications in block descriptor table entries. When a block descriptor table entry specifies an adjacency indication, the table access circuitry system can determine that access control information for two or more distinct address granules corresponding to the requested target address is represented by a shared set of access control information shared between the two or more distinct granules. This can be useful because if the shared set of access control information can represent information for more than one granule, then if the system supports caching table entries in a translation back buffer or other type of cache (e.g., a granule protection information cache described further below), it may mean that the cache does not have to store separate cache entries for different granules. Instead, a single cache entry can indicate a shared set of access control information to be used for a larger number of granules. This allows for more efficient use of cached storage capacity, effectively allowing the cache to store information for a larger number of granules than would be expected given the actual hardware storage provided.

[0039] Based on the adjacency size parameter specified in the block descriptor table entry, the number of granularities of a shared access control information set can be variable when an adjacency indication is specified. This provides flexibility in changing the size of adjacent block addresses that can be "merged" to share the same access control information set.

[0040] Adjacency indications can be represented in different ways. In some cases, a dedicated adjacency indication field can be provided separately from the field used to indicate the access control information itself. However, in the example above where a block descriptor table entry has multiple separate access control information fields defining access control information for multiple granularities, the valid encoding of the adjacency indication can be a predetermined encoding that defines an access control information field that cannot be used to indicate any valid option for access control information, and the predetermined encoding of the access control information field is interpreted as indicating the adjacency indication. In this case, when a predetermined access control information field in the access control information fields of the block descriptor table entry has a predetermined encoding, it means that the table access circuitry determines that the shared set of access control information is indicated by one or more access control information fields among the other access control information fields within the block descriptor table entry, or the shared set of access control information can even be represented in a block descriptor table entry that is completely different from the block descriptor table entry corresponding to the target address. By using an additional invalid code for the access control information field as an adjacency indicator and utilizing other parts of the same block of descriptor table entries to represent the fact that shared access control information can be represented, the need to allocate a separate field for the adjacency indicator is avoided, thus providing a more efficient storage format for table data.

[0041] The techniques discussed above can be used for different types of table structures by memory management circuitry systems to control access to memory.

[0042] The technique of using variable nested control parameters can be particularly useful for table structures indexed by physical addresses rather than virtual addresses. When a table structure is indexed by physical addresses, this means that the target address used to look up the table structure (from which the offset is extracted to index into the corresponding level of the table) will be a physical address. The use of variable nested control parameters is particularly useful for access control table structures that are physically indexed because the physical address space tends to exhibit greater memory linearity than the virtual address space. That is, since physical addresses correspond more closely to hardware-implemented physical memory regions than virtual addresses, relatively large adjacent physical address blocks will be more likely to have similar requirements in terms of performance / memory footprint efficiency than adjacent virtual address blocks of the same size. In contrast, fairly large adjacent virtual address blocks will be more likely to be segmented across various different physical memory units or peripherals with different requirements for performance / memory footprint tradeoffs. Table structures indexed by physical addresses rather than virtual addresses can also be referred to as reverse page tables, and the techniques discussed in this application are particularly useful for such reverse page tables, which provide information on the corresponding granular definitions for physical addresses.

[0043] A specific example of a physical index table structure could be a table used to separate corresponding physical address spaces. For example, a memory management circuitry system could include: an address translation circuitry system for translating a target virtual address specified by a memory access request into a target physical address associated with a selected physical address space chosen from a plurality of physical address spaces; and a filtering circuitry system for determining whether the memory access request should be allowed to access the target physical address based on whether access control information obtained from the table structure indicates that the selected physical address space is a permitted physical address space for the target physical address.

[0044] The data processing system can support the use of virtual memory, providing address translation circuitry to translate the virtual address specified by a memory access request into a physical address associated with the location in the memory system to be accessed. The mapping between virtual and physical addresses can be defined in one or more page table structures. Page table entries within the page table structure can also define access permission information that controls whether a given software procedure executing on the processing circuitry is allowed to access a specific virtual address.

[0045] In some processing systems, address translation circuitry maps all virtual addresses to a single physical address space, which the memory system uses to identify locations in memory to be accessed. In such systems, control over whether a particular address is accessible to a specific software process is based solely on the page table structure used to provide the virtual-to-physical address translation mapping. However, this page table structure is typically defined by the operating system and / or hypervisor. If the operating system or hypervisor is compromised, this can introduce security vulnerabilities, allowing attackers to access sensitive information.

[0046] Therefore, for systems that require certain processes to be executed securely in isolation from other processes, the system can support multiple distinct physical address spaces. For at least some components of the memory system, memory access requests whose virtual addresses are translated into physical addresses in different physical address spaces are treated as completely separate addresses accessing memory, even if physical addresses in the corresponding physical address spaces actually correspond to the same location in memory. By isolating accesses from different operational domains of the processing circuitry system into corresponding distinct physical address spaces as perceived by some memory system components, this provides stronger security guarantees independent of page table permission information set by the operating system or hypervisor.

[0047] In systems where the virtual address of a memory access request can be mapped to a physical address in one of two or more different physical address spaces, granular protection information can be used to restrict which physical addresses can be accessed within a specific physical address space. This is useful for ensuring that certain physical memory locations implemented in on-chip or off-chip hardware can be restricted to access within a specific physical address space or a specific subset of physical address spaces when needed.

[0048] Therefore, the technique of changing the size of the offset portion of the target address based on variable nested control parameters defined in a higher-level table can be applied to tables that define particle protection information for restricting which physical addresses are accessible within a specific physical address space selected for a given memory access. Thus, the aforementioned access control information can be particle protection information that defines which physical address spaces are the allowed physical address spaces of the corresponding particles of a physical address.

[0049] However, the aforementioned variable nesting technique can also be used for table structures indexed by virtual addresses, such as page tables, which provide address translation mappings used by address translation circuitry to translate target virtual addresses into target physical addresses.

[0050] While virtual memory allocation tends to be more segmented, making it more likely that using a fixed, larger number of table levels can more effectively reduce the table footprint in memory, there may be regions where a larger table footprint can be tolerated to improve the performance of certain areas storing performance-critical data that needs to be accessed quickly. Therefore, the techniques discussed above can be used to trade off table memory footprint for performance when traversing tables in those regions where there is sufficient linearity in the virtual address space for the number of levels to be reduced. Thus, defining variable-sized offset portions for a given level based on variable nesting control parameters in higher-level access control tables can also be applied to page tables or any other access control table structure indexed by virtual addresses. The access control information discussed above can include addressing mapping information from page tables used for address translation, and may also include other access permission information defined in the page tables, such as information defining whether a region of a virtual address is readable / writable or should be read-only, or information restricting which permission / abnormal levels are allowed to access said region.

[0051] The above-described techniques can be implemented in a hardware device having hardware circuitry logic for implementing the aforementioned functions. Therefore, the memory management circuitry and table access circuitry can include hardware circuitry logic. However, in other examples, a computer program for controlling a host data processing device to provide an instruction execution environment for executing object code can be equipped with memory management logic and table access logic that perform equivalent functions in software to the memory management circuitry and table access circuitry discussed above. This is useful, for example, for enabling object code written for a specific instruction set architecture to execute on a host computer that may not support that instruction set architecture.

[0052] Therefore, simulation software can be used to emulate the functionality expected by an instruction set architecture not provided by the host computer. This simulation software provides the target code with an equivalent instruction execution environment as expected when executing the target code on a hardware device that actually supports the instruction set architecture. Thus, the computer program providing the simulation can include: memory management logic that controls access to simulated memory based on access control information defined in table entries of a table structure; and table access logic for accessing a table structure (which is stored in the host data processing device's memory but accessed by accessing an address in specified simulated memory, which simulates the memory that a real target processing device supporting the simulated instruction set architecture would have). As in a hardware device, the nesting of the table structure can be controlled based on variable nesting control parameters to change the size of the offset used at a given level of the table structure. For methods of providing architecture simulation, the physical addresses generated by any address translation and indexing into any physical index table structure can be physical addresses within the simulated physical address space, because they do not actually correspond to the physical address space identified by the host computer's hardware components, but rather are addresses that will be mapped into the host's virtual address space.

[0053] Providing such simulation is useful for a variety of purposes, such as enabling legacy code written for one instruction set architecture to execute on different platforms that support different instruction set architectures, or assisting software development for new software to execute on a new version of the instruction set architecture when hardware devices supporting the new version of the instruction set architecture are not yet available (this allows the software for the new version of the architecture to begin development in parallel with the development of hardware devices that support the new version of the architecture).

[0054] Figure 1An example of a data processing system 2 having at least one requester device 4 and at least one completer device 6 is schematically illustrated. Interconnection 8 provides communication between the requester device 4 and the completer device 6. The requester device is capable of issuing a memory access request for memory access to a specific addressable memory system location. The completer device 6 is the device responsible for servicing memory access requests directed to it. Although... Figure 1 Not shown, but some devices may be able to act as both requester and completer devices. Requester device 4 may include, for example, processing elements such as a central processing unit (CPU) or a graphics processing unit (GPU), or other host devices such as a bus master, network interface controller, display controller, etc. Completer devices may include memory controllers responsible for controlling access to corresponding memory storage units, peripheral controllers for controlling access to peripheral devices, etc. Figure 1 An exemplary configuration of one of the requester devices 4 is shown in more detail, but it should be understood that other requester devices 4 may have similar configurations. Alternatively, other requester devices may have the same... Figure 1 The left side shows different configurations of the requester device 4.

[0055] The requester device 4 has a processing circuitry 10 for performing data processing in response to instructions, referencing data stored in register 12. Register 12 may include a general-purpose register for storing operands and the results of processed instructions, and a control register for storing control data to configure how the processing circuitry 10 performs processing. For example, the control data may include a current domain indicator 14 for selecting which operation domain is the current domain, and a current exception level indicator 15 for indicating which exception level is the current exception level that the processing circuitry 10 is operating at.

[0056] Processing circuitry 10 may issue memory access requests specifying a virtual address (VA) identifying the addressable location to be accessed and a domain identifier (domain ID or "security state") identifying the current domain. Address translation circuitry 16 (e.g., a memory management unit (MMU)) translates the virtual address into a physical address (PA) through one or more stages of address translation based on page table data defined in a page table structure stored in the memory system. Page table walk circuitry 17 controls the issuance of page table walk memory access requests for page table entries from the memory system, including generating the address of the page table entry based on a table base address defined in a base address register or provided by a pointer from a higher-level table entry and an offset portion extracted from the target address to be translated. Translation lookup buffer (TLB) 18 acts as a lookup cache to cache some information in the page table information, thereby enabling faster access than if the page table information had to be retrieved from memory every time an address translation was required. In this example, in addition to generating the physical address, the address translation circuitry 16 also selects one of several physical address spaces associated with the physical address and outputs a Physical Address Space (PAS) identifier that identifies the selected physical address space. The selection of the PAS will be discussed in more detail below.

[0057] PAS filter 20 acts as a requester-side filtering circuit system to check whether access to the physical address within the specified physical address space identified by the PAS identifier is permitted based on the translated physical address and the PAS identifier. This lookup is based on the particle protection information stored in the particle protection table structure stored within the memory system. Particle Protection Table (GPT) walk circuit system 23 controls access to entries in the particle protection table structure in memory. Similar to page table walk circuit system 17, GPT walk circuit system 23 controls the issuance of GPT walk memory access requests for GPT entries from the memory system, including generating the address of the GPT entry based on the table base address defined in the base address register or provided by a pointer from a higher-level table entry and an offset portion extracted from the target address to be translated. Similar to the caching of page table data in TLB 18, particle protection information can be cached within particle protection information cache 22. Although particle protection information cache 22 is in Figure 1In the example shown, it is a separate structure from TLB 18, but in other examples, these types of lookup caches can be combined into a single lookup cache structure so that a single lookup of an entry in the combined structure provides both page table information and granular protection information. Granular protection information defines information that restricts access to the physical address space of a given physical address, and based on this lookup, PAS filter 20 determines whether to allow memory access requests to continue being issued to one or more caches 24 and / or interconnects 8. If the specified PAS access to the specified physical address is not permitted for the memory access request, PAS filter 20 blocks the transaction and may signal a fault.

[0058] Address translation circuit system 16 and PAS filter 20 are examples of memory management circuit systems. Page table walk circuit system 17 and GPT walk circuit system 23 are examples of table access circuit systems.

[0059] Although Figure 1 An example of a system including multiple requester devices 4 is shown, but for... Figure 1 The feature shown by a requester device on the left-hand side can also be included in systems where only one requester device exists (such as a single-core processor).

[0060] Although Figure 1 An example is shown where the address translation circuitry 16 performs the selection of a PAS for a given request. However, in other examples, the address translation circuitry 16 may output information for determining which PAS to select, along with the PA, to the PAS filter 20, and the PAS filter 20 may select the PAS and check whether access to the PA is permitted within the selected PAS.

[0061] The provision of PAS filter 20 helps support systems that can operate in multiple operational domains, each associated with its own isolated physical address space. This means that, for at least a portion of the memory system (e.g., for some cache or coherence implementation such as a snooping filter), even if addresses within these address spaces actually relate to the same physical location in the memory system, each individual physical address space is treated as a completely separate set of addresses that identify the individual memory system location. This can be useful for security purposes.

[0062] Figure 2 Examples of different operating states and domains in which the processing circuit system 10 can operate are shown, as well as examples of the types of software that can be executed in different exception levels and domains (of course, it should be understood that the specific software installed on the system is selected by the parties managing the system and is therefore not a fundamental feature of the hardware architecture).

[0063] The processing circuitry system 10 can operate at multiple different exception levels 80 (in this example, four exception levels labeled EL0, EL1, EL2, and EL3), where EL3 refers to the exception level with the highest privilege level, and EL0 refers to the exception level with the lowest privilege level. It should be understood that other architectures may choose the reverse numbering so that the exception level with the highest number can be considered to have the lowest privilege. In this example, the lowest privilege exception level EL0 is used for application-level code, the next highest privilege exception level EL1 is used for operating system-level code, the next highest privilege exception level EL2 is used for hypervisor-level code managing switching between multiple virtualized operating systems, and the highest privilege exception level EL3 is used for monitoring code managing switching between corresponding domains and the allocation of physical addresses to the physical address space, as described later.

[0064] When an exception occurs while the processing software is at a specific exception level, for some types of exceptions, an exception of a higher (higher privilege) level is generated, where the specific exception level to generate the exception is selected based on the attributes of the specific exception that occurred. However, in some cases, it is possible for other types of exceptions to be generated at the same exception level as the exception level associated with the code that was processed when the exception occurred. When an exception occurs, information characterizing the state of the processor at the time the exception occurred can be saved, including, for example, the current exception level at the time the exception occurred. Therefore, once an exception handler has been processed to handle the exception, processing can return to the previous processing, and the saved information can be used to identify the exception level to which the processing should return.

[0065] In addition to different exception levels, the processing circuitry system supports multiple operating domains, including a root domain 82, a secure (S) domain 84, a less secure domain 86, and a domain 88. For ease of reference, the less secure domain will be described hereinafter as an “unsecure” (NS) domain, but it should be understood that this is not intended to imply any particular level of security (or lack thereof). Rather, “unsecure” simply indicates that the unsecure domain is intended for code that is not as secure as code operating in a secure domain. The root domain 82 is selected when the processing circuitry system 10 is at the highest exception level EL3. When the processing circuitry system is at one of the other exception levels EL0 through EL2, the current domain is selected based on the current domain indicator 14, which indicates which of the other domains 84, 86, and 88 is active. For each of the other domains 84, 86, and 88, the processing circuitry system can be at any exception level of EL0, EL1, or EL2.

[0066] At boot time, multiple fragments of boot code (e.g., BL1, BL2, OEM boot) may be executed, for example, within a higher privilege exception level EL3 or EL2. Boot code BL1 and BL2 may be associated with, for example, a root domain, and the OEM boot code may operate within a security domain. However, once the system is booted, during runtime, the processing circuitry system 10 can be considered to operate at one time within one of domains 82, 84, 86, and 88. Each of domains 82 through 88 is associated with its own associated physical address space (PAS), which achieves the isolation of data from different domains within at least a portion of the memory system. This will be described in more detail below.

[0067] Non-security domain 86 can be used for regular application-level processing and for operating system and hypervisor activities to manage such applications. Thus, within non-security domain 86, there can be application code 30 operating at EL0, operating system (OS) code 32 operating at EL1, and hypervisor code 34 operating at EL2.

[0068] Security domain 84 enables the isolation of certain on-chip security, media, or system services into a separate physical address space from the physical address space used for non-secure processing. Non-secure domain code cannot access resources associated with security domain 84, while secure domain code can access both secure and non-secure resources; in this sense, secure and non-secure domains are not equivalent. An example of a system supporting this partitioning of security domain 84 and non-secure domain 86 is based on Arm... ® TrustZone provided by Limited ® The system architecture includes a trusted application 36 at EL0, a trusted operating system 38 at EL1, and optionally a secure partition manager 40 at EL2. If secure partitioning is supported, the secure partition manager uses stage 2 page tables to support isolation between different trusted operating systems 38 running in the secure domain 84, in a manner similar to how the hypervisor 34 manages isolation between virtual machines or guest operating systems 32 running in the non-secure domain 86.

[0069] Extending this system to support security domain 84 has become common in recent years because it enables a single hardware processor to support isolated secure processing, thus avoiding the need to execute that processing on a separate hardware processor. However, with the increasing prevalence of security domains, many real-world systems with such security domains now support relatively complex hybrid service environments offered by a wide variety of different software vendors within the security domain. For example, code operating in security domain 84 may include different pieces of software provided by, among other things: silicon wafer providers that manufacture integrated circuits; original equipment manufacturers (OEMs) that assemble the integrated circuits provided by the silicon wafer providers into electronic devices such as mobile phones; operating system vendors (OSVs) that provide the operating system 32 for such devices; and / or cloud platform providers that manage cloud servers that support services for multiple different clients via the cloud.

[0070] However, there is a growing desire to provide secure computing environments for parties providing user-level code (which may typically be expected to execute as application 30 within a non-secure domain 86), environments that can be trusted not to leak information to other parties operating the code on the same physical platform. It may be desirable for such secure computing environments to be dynamically allocated at runtime and to be certified and provable, allowing users to verify adequate security guarantees on the physical platform before trusting the device to process potentially sensitive code or data. Users of such software may not want to trust a party providing a rich operating system 32 or hypervisor 34 that may typically operate in a non-secure domain 86 (or even if these providers are trusted, users may want to protect themselves from attackers who could compromise the operating system 32 or hypervisor 34). Furthermore, while a secure domain 84 can be used for such user-provided applications requiring secure processing, this can actually create problems for both users providing code that requires a secure computing environment and providers of existing code operating within a secure domain 84. For providers of existing code operating within security domain 84, adding arbitrary user-supplied code within the security domain would increase the attack surface of their code, which is likely undesirable. Therefore, it is strongly recommended that users not be allowed to add code to security domain 84. On the other hand, users providing code that requires a secure computing environment may be reluctant to trust that all providers of different fragments of code operating within security domain 84 have access to their data or code. If authentication or certification of code operating within a specific domain is required as a prerequisite for user-supplied code to perform its processing, it may be difficult to audit and authenticate all different fragments of code operating within security domain 84 provided by different software providers. This could limit opportunities for third parties to provide more secure services.

[0071] Therefore, as Figure 2As shown, an additional domain 88 (referred to as a domain domain) is provided, which can be used by code introduced by such users to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in security domain 24. Within a domain domain, the software executed may include multiple domains, each of which can be isolated from other domains by a Domain Management Module (RMM) 46 operating at exception level EL2. The RMM 46 can control the isolation between corresponding domains 42, 44 executing domain domain 88, for example, by defining access permissions and address mappings in a page table structure, in a manner similar to how the hypervisor 34 manages the isolation between different components operating in non-security domain 86. In this example, the domains include an application-level domain 42 executing at EL0 and a packaged application / operating system domain 44 executing across exception levels EL0 and EL1. It should be understood that it is not necessary to support both EL0 and EL0 / EL1 type domains simultaneously, and multiple domains of the same type can be created by the RMM 46.

[0072] Similar to security domain 84, domain 88 has its own physical address space allocated to it. However, while domain 88 and security domain 84 can each access the non-secure PAS associated with non-secure domain 86, they cannot access each other's physical address spaces. In this sense, the domain is orthogonal to security domain 84. This means that the code executing in domain 88 and security domain 84 is independent of each other. The code in the domain only needs to trust the switching code between the hardware RMM 46 and the management domain operating in root domain 82, which makes proof and authentication more feasible. Proof enables a given piece of software to request verification that the code installed on the device matches certain expected characteristics. This can be achieved by checking whether the hash of the program code installed on the device matches an expected value signed by a trusted party using a cryptographic protocol. RMM 46 and monitoring code 29 can be verified, for example, by checking whether the hash of the software matches the expected value signed by a trusted party, such as a silicon supplier that manufactures the integrated circuits including processing system 2 or an architecture supplier that designs processor architectures that support domain-based memory access control. This allows the user-provided codes 42 and 44 to verify whether the integrity of the domain-based architecture can be trusted before performing any security or sensitive functions.

[0073] Thus, it can be seen that the code associated with domains 42 and 44 (which was previously executed in non-secure domain 86, as shown by the dashed lines indicating gaps in the non-secure domain where these processes were previously executed) can now be moved to the domain domain, where they can have stronger security guarantees because their data and code will not be accessed by other code operating in non-secure domain 86. However, the fact that domain domain 88 and secure domain 84 are orthogonal and therefore cannot see each other's physical address spaces means that the provider of the code in the domain domain does not need to trust the provider of the code in the secure domain, and vice versa. The code in the domain domain can simply trust the trusted firmware that provides monitoring code 29 for root domain 82 and the RMM 46 provided by the silicon provider or the provider of the instruction set architecture supported by the processor (which may already be inherently needed to be trusted when the code executes on its device), so that a secure computing environment can be provided to users without further trust relationships with other operating system vendors, OEMs, or cloud hosts.

[0074] This can be used in a range of applications and use cases, including, for example, mobile wallets and payment applications, game anti-cheating and anti-piracy mechanisms, operating system platform security enhancements, secure virtual machine hosting, confidential computing, and gateway processing for networked or IoT devices. It should be understood that users can find many other applications with useful support for this domain.

[0075] To support security assurances provided to the domain, the processing system may support a proof reporting function, in which firmware images and configurations (e.g., monitoring code images and configurations or RMM code images and configurations) are measured at boot time or runtime, and domain content and configurations are measured at runtime, so that the domain owner can trace back the relevant proof reports to known implementations and certifications, thereby making a trust decision on whether to operate on the system.

[0076] like Figure 2As shown, a separate root domain 82 is provided for managing domain switching, and this root domain has its own isolated root physical address space. Even for systems with only non-secure domains 86 and secure domains 84 but no domain 88, the creation of the root domain and the isolation of its resources from the secure domains allows for a more robust implementation, but it can also be used in implementations that do not support domain 88. Root domain 82 can be implemented using monitoring software 29 provided (or certified) by the silicon provider or architect, and can be used to provide secure boot functionality, trusted boot measurement, on-chip system configuration, debug control, and management of firmware updates for firmware components provided by other parties (such as OEMs). Root domain code can be developed, certified, and deployed by the silicon provider or architect without relying on the final device. In contrast, secure domain 84 can be managed by the OEM to implement certain platform and security services. The management of non-secure domain 86 can be controlled by operating system 32 to provide operating system services, while domain 88 allows for the development of new forms of trusted execution environments that can be dedicated to user or third-party applications while being isolated from the existing security software environment in secure domain 84.

[0077] Figure 3 Another example of a processing system 2 used to support these technologies is schematically shown. (Using the same reference numerals, it is shown alongside...) Figure 1 The same components. Figure 3 The address translation circuitry 16 is shown in more detail, comprising a Stage 1 memory management unit 50 and a Stage 2 memory management unit 52. Stage 1 MMU 50 is responsible for translating virtual addresses to physical addresses (when the translation is triggered by EL2 or EL3 code) or to intermediate addresses (when the translation is triggered by EL0 or EL1 code in a certain operating state, in which further Stage 2 translation by Stage 2 MMU 52 is required). Stage 2 MMU translates intermediate addresses to physical addresses. Stage 1 MMU may be based on a page table controlled by the operating system for translations initiated from EL0 or EL1, a page table controlled by the hypervisor for translations from EL2, or a page table controlled by monitor code 29 for translations from EL3. On the other hand, Stage 2 MMU 52 may be based on a page table structure defined by hypervisor 34, RMM 46, or security partition manager 14, depending on which domain is used. Dividing these translations into two phases in this way allows the operating system to manage address translation for itself and applications (assuming they are the only operating system running on the system), while RMM 46, Hypervisor 34, or SPM40 can manage isolation between different operating systems running in the same domain.

[0078] like Figure 3As shown, the address translation process using address translation circuitry system 16 can return a security attribute 54, which, combined with the current exception level 15 and the current domain 14 (or security state), allows access to a specific physical address space (identified by the PAS identifier or "PAS TAG") in response to a given memory access request. The physical address and PAS identifier can be looked up in the granular protection table 56, which provides the previously described granular protection information. In this example, PAS filter 20 is shown as a granular memory protection unit (GMPU) that verifies whether the physical address of the selected PAS access request is allowed; if so, the transaction is allowed to proceed to any cache 24 or interconnect 8 that is part of the system architecture of the memory system.

[0079] The GMPU 20 allows memory to be allocated to separate address spaces while providing strong hardware-based isolation guarantees and offering spatial and temporal flexibility as well as efficient sharing schemes in terms of how physical memory is allocated to these address spaces. As previously described, execution units in the system are logically partitioned into virtual execution states (domains or "worlds"), with one execution state (root world) located at the highest exception level (EL3), which is called the "root world" and manages the allocation of physical memory to these worlds.

[0080] A single system physical address space is virtualized into multiple "logical" or "architectural" physical address spaces (PASs), each of which is an orthogonal address space with independent consistency properties. The system physical address is mapped to a single "logical" physical address space by extending the system physical address with a PAS label.

[0081] Allowing a subset of the logical-physical address space to be accessed in a given world. This is implemented by hardware filter 20, which can be attached to the output of memory management unit 16.

[0082] The world uses fields in the translation table descriptor of the page table used for address translation to define the security attributes (PAS tags) for that access. Hardware filter 20 has access rights to a table (granular protection table 56 or GPT) that defines granular protection information (GPI) for each page in the system's physical address space, which indicates the associated PAS tag and (optionally) other granular protection attributes.

[0083] Hardware filter 20 checks the world ID and security attributes against the particle's GPI and determines whether access can be granted, thereby forming a particle-shaped memory protection unit (GMPU).

[0084] For example, GPT 56 can reside in on-chip SRAM or off-chip DRAM. If stored off-chip, GPT 56 can be protected for integrity by an on-chip memory protection engine that uses encryption, integrity, and freshness mechanisms to maintain the security of GPT 56.

[0085] Positioning GMPU 20 on the requester side of the system (e.g., on the MMU output) instead of the completer side allows for page-level access permission allocation, while allowing interconnect 8 to continue hashing / stripping the page across multiple DRAM ports.

[0086] Transactions remain tagged with the PAS tag because they propagate throughout the system architecture 24,8 until they reach a location defined as a physical alias point 60. This allows filters to be positioned on the master side without compromising security guarantees compared to slave-side filtering. Because the transaction propagates throughout the system, the PAS tag can be used as a security-in-depth mechanism for address isolation: for example, a cache can add a PAS tag to an address label in the cache, preventing accesses to the same PA with an incorrect PAS tag from hitting the cache and thus improving resistance to side-channel attacks. The PAS tag can also be used as a context selector for a protection engine attached to the memory controller, which encrypts data before writing it to external DRAM.

[0087] A Physical Alias ​​Point (PoPA) is the location in the system where the PAS tag is stripped and the address is translated from a logical physical address back to a system physical address. The PoPA can be located on the system's completer side below the cache, where physical DRAM is accessed using the cryptographic context resolved via the PASTAG. Alternatively, it can be located above the cache to simplify system implementation at the cost of reduced security.

[0088] At any point in time, the world can request a page to be transitioned from one PAS to another. This request is made to monitoring code 29 at EL3, which checks the current state of the GPI. EL3 may allow only specific groups of transitions to occur (e.g., from a non-secure PAS to a secure PAS, but not from a domain PAS to a secure PAS). To provide a clean transition, the system supports a new instruction – “Data Cleanup and Invalidate to Physical Alias ​​Point” – which EL3 can submit before transitioning a page to a new PAS. This ensures that any residual state associated with the previous PAS is flushed from any cache upstream of PoPA 60 (closer to the requester side than PoPA 60).

[0089] Another feature achievable by attaching the GMPU 20 to the host side is efficient memory sharing between worlds. It might be desirable to grant shared access to a physical particle to a subset of N worlds, while preventing other worlds from accessing that physical particle. This can be achieved by adding "restricted sharing" semantics to the particle's protection information, while forcing it to use a specific PAS tag. As an example, the GPI could indicate that a physical particle can only be accessed by "Domain World" 88 and "Secure World" 84, while being tagged with the PAS tag of "Secure PAS" 84.

[0090] An example of the aforementioned characteristics is the ability to rapidly change the visibility properties of specific physical particles. Consider the case where each world is allocated a dedicated PAS that is only accessible to that world. For a specific particle, that world can request to make it visible to the insecure world at any point in time by changing its GPI from "exclusive" to "restricted sharing with the insecure world," without altering the PAS association. This increases the particle's visibility without requiring costly cache maintenance or data copying operations.

[0091] Figure 4 The concept of aliases on physical memory provided to the hardware by the corresponding physical address space is illustrated. As previously described, each of the domains 82, 84, 86, and 88 has its own corresponding physical address space 61.

[0092] At the point in time that the address translation circuitry 16 generates the physical address, the physical address has a value within a certain range 62 supported by the system, and this value is the same regardless of which physical address space is selected. However, in addition to generating the physical address, the address translation circuitry 16 can also select a specific physical address space (PAS) based on the current domain 14 and / or information in the page table entries used to derive the physical address. Alternatively, instead of the address translation circuitry 16 performing the selection of the PAS, the address translation circuitry (e.g., the MMU) can output the physical address and information derived from the page table entries (PTE) for selecting the PAS, which the PAS filter or GMPU 20 can then use to select the PAS.

[0093] The selection of PAS for a given memory access request can be restricted according to the rules defined in the table below, based on the current domain that the processing circuitry 10 is operating on when issuing the memory access request:

[0094]

[0095] For those domains where multiple physical address spaces are available, information from page table entries used to provide access to physical addresses is used to select among the available PAS options.

[0096] Thus, at the point in time when the PAS filter 20 outputs the memory access request to system architectures 24, 8 (assuming it passes any filtering checks), the memory access request is associated with the physical address (PA) and the selected physical address space (PAS).

[0097] From the perspective of memory system components (such as caches, interconnects, snooping filters, etc.) operating prior to the Physical Alias ​​Point (PoPA) 60, the corresponding physical address space 61 is viewed as a completely separate address range corresponding to different system locations within memory. This means that, from the perspective of the pre-PoPA memory system components, the address range identified by a memory access request is actually four times the size of the range 62 that can be output in address translation, because the PAS identifier is actually treated as an additional address bit next to the physical address itself, so that the same physical address PAx can be mapped to multiple alias physical addresses 63 in different physical address spaces 61 depending on which PAS is selected. These alias physical addresses 63 all actually correspond to the same memory system location implemented in the physical hardware, but the pre-PoPA memory system components treat the alias address 63 as a separate address. Thus, if any pre-PoPA cache or snooping filter exists to allocate entries for such addresses, the alias address 63 will be mapped to a different entry with separate cache hit / miss decisions and separate consistency management. This reduces the likelihood or effectiveness of an attacker using a cache or consistency side channel as a mechanism to probe operations in other domains.

[0098] The system may include more than one PoPA 60. At each PoPA 60, the aliased physical address is shrunk to a single de-aliased address 65 in the system physical address space 64. The de-aliased address 65 is provided downstream of any subsequent PoPA component such that the system physical address space 64, which actually identifies the memory system location, is once again the same size as the range of physical addresses that can be output in the address translation performed on the requester side. For example, at PoPA 60, the PAS identifier may be stripped from these addresses, and for downstream components, these addresses can be simply identified using physical address values ​​without specifying the PAS. Alternatively, for some cases where some completer-side filtering is expected for memory access requests, the PAS identifier may still be provided downstream of PoPA 60, but may not be interpreted as part of the address, such that the same physical address appearing in different physical address spaces 60 will be interpreted downstream of the PoPA as involving the same memory system location, but the supplied PAS identifier can still be used to perform any completer-side security checks.

[0099] Figure 5This illustrates how the granular protection table 56 can be used to divide the system physical address space 64 into blocks of access allocations within a specific architecture physical address space 61. The granular protection table (GPT) 56 defines which portions of the system physical address space 65 are allowed to be accessed from each architecture physical address space 61. For example, the GPT 56 may include multiple entries, each corresponding to a physical address granule of a certain size (e.g., 4K pages), and may be defined as the PAS allocated to that granule, which can be selected from non-secure domains, secure domains, domains, and root domains. By design, if a particular granule or group of granules is allocated to a PAS associated with one of these domains, it can only be accessed within the PAS associated with that domain and not within PASs of other domains. However, it should be noted that while granules allocated to secure PASs (for example) cannot be accessed from within the root PAS, the root domain 82 can access the physical address granule by specifying PAS selection information in its page table to ensure that the virtual address associated with a page in that region of physically addressed memory is translated into a physical address in the secure PAS (not the root PAS). Thus, the sharing of data across domains can be controlled at the point in time when a PAS is selected for a given memory access request (to the extent permitted by the accessibility / inaccessibility rules defined in the previously described table).

[0100] However, in some specific implementations, in addition to allowing access to physical address particles within the allocated PAS defined by the GPT, the GPT can also use other GPT attributes to mark certain regions of the address space as shared with another address space (e.g., an address space associated with a domain of lower or orthogonal privileges (which typically does not allow it to select an allocated PAS for access requests to that domain)). This facilitates temporary sharing of data without requiring changes to the allocated PAS of a given particle. For example, in Figure 5 In the GPT, region 70 of the domain PAS is defined as being allocated to the domain domain and therefore is normally inaccessible from the non-secure domain 86 because the non-secure domain 86 cannot select the domain PAS for its access requests. Since the non-secure domain 26 cannot access the domain PAS, non-secure code typically cannot see the data in region 70. However, if a domain temporarily wishes to share some data in its allocated region of memory with the non-secure domain, it can request the monitoring code 29 operating in the root domain 82 to update GPT 56 to indicate that region 70 will be shared with the non-secure domain 86, and this allows region 70 to also be accessed from the non-secure domain 86. Figure 5The non-secure PAS access shown on the left-hand side does not require changing which domain is the domain allocated to region 70. If a domain has designated a region of its address space to be shared with a non-secure domain, then although a memory access request originating from the non-secure domain targeting that region may initially specify a non-secure PAS, PAS filter 20 can remap the PAS identifier of the request to instead specify a domain PAS, so that downstream memory system components treat the request as always originating from the domain domain. This sharing can improve performance because the operations used to allocate different domains to specific memory regions can be more performance-intensive, involving a greater degree of cache / TLB invalidation and / or data zeroing in memory or data copying between memory regions (which can be undesirable if the sharing is expected to be only temporary).

[0101] Figure 6 This is a flowchart illustrating how the current operating domain is determined, which can be performed by the processing circuitry 10 or by the address translation circuitry 16 or the PAS filter 20. At step 100, it is determined whether the current exception level 15 is EL3. If so, at step 102, the current domain is determined to be the root domain 82. If the current exception level is not EL3, at step 104, the current domain is determined to be one of the non-secure domain 86, the secure domain 84, and the neighborhood domain 88, as indicated by at least two domain indicator bits 14 in the processor's EL3 control register (since the root domain is indicated by the current exception level as EL3, it may not be necessary to have an encoding of the domain indicator bits 14 corresponding to the root domain; therefore, at least one encoding of the domain indicator bits can be reserved for other purposes). The EL3 control register can be written to when operating at EL3 and cannot be written to from other exception levels EL2-EL0.

[0102] Figure 7An example of a page table entry (PTE) format is shown that can be used for page table entries in a page table structure. These page table entries are used by the address translation circuitry 16 to map virtual addresses to physical addresses, virtual addresses to intermediate addresses, or intermediate addresses to physical addresses (depending on whether the translation is performed in an operational state where a stage 2 translation is fully required, and whether the translation is a stage 1 translation or a stage 2 translation if a stage 2 translation is required). In general, a given page table structure can be defined as a multi-level table structure implemented as a page table tree, where the first level of the page table is identified based on a base address stored in the processor's translation table base address register, and an index for selecting a specific level 1 page table entry within the page table is derived from a subset of bits of the input address to which a translation lookup is performed (the input address can be a virtual address for stage 1 translation or an intermediate address for stage 2 translation). A level 1 page table entry can be a "table descriptor" 110 that provides a pointer 112 to the next level page table, from which further page table entries can be selected based on a further subset of bits of the input address. Finally, after one or more lookups at consecutive levels of the page table, block or page descriptors PTE114, 116, and 118 can be identified, which provide an output address 120 corresponding to the input address. The output address can be an intermediate address (for a stage 1 transition performed while the operation is still in the state of performing a further stage 2 transition) or a physical address (for a stage 2 transition or a stage 1 transition when stage 2 is not required).

[0103] To support the different physical address spaces mentioned above, in addition to the next-level page table pointer 112 or output address 120 and any attributes 122 used to control access to the corresponding block of memory, the page table entry format also specifies some additional states for physical address space selection.

[0104] For page table descriptor 110, the PTE used by any domain other than the non-secure domain 86 includes a non-secure table indicator 124, which indicates whether the next-level page table will be accessed from the non-secure physical address space or from the physical address space of the current domain. This facilitates more efficient management of page tables. Typically, the page table structure used by the root domain, domain domain, or secure domain 24 may only need to define special page table entries for a portion of the virtual address space, and for other portions, the same page table entries used by the non-secure domain 26 can be used. Therefore, by providing the non-secure table indicator 124, this allows higher levels of the page table structure to provide dedicated domain / secure table descriptors, while at certain points in the page table tree, the root domain or secure domain can switch to using page table entries from the non-secure domain for portions of the address space that do not require higher security. Other page table descriptors in other parts of the page table tree can still be obtained from the associated physical address space associated with the root domain, domain domain, or secure domain.

[0105] On the other hand, block / page descriptors 114, 116, and 118 may include physical address space selection information 126 depending on which domain they are associated with. The insecure block / page descriptor 118 used in the insecure domain 86 does not include any PAS selection information because the insecure domain can only access insecure PASs. However, for other domains, block / page descriptors 114 and 116 include PAS selection information 126, which is used to select which PAS to translate the input address to. For the root domain 22, EL3 page table entries may have PAS selection information 126, which includes at least two bits to indicate the selected PAS to which the corresponding physical address will be translated when the PAS associated with any of the four domains 82, 84, 86, and 88 is associated. In contrast, for both the domain and security domains, the corresponding block / page descriptor 116 only needs to include one bit of PAS selection information 126, which selects between the domain PAS and non-security PAS for the domain domain, and between the security PAS and non-security PAS for the security domain. To improve circuit implementation efficiency and avoid increasing the size of page table entries, the block / page descriptor 116 can encode the PAS selection information 126 at the same location within the PTE for both the domain and security domains, regardless of whether the current domain is the domain or the security domain, so that the PAS selection bit 126 can be shared.

[0106] like Figure 8 As shown, the page table structure can be implemented using multiple levels of page tables 150, 152, 154, and 156. These page tables can be traversed during page table walkthroughs to identify address mappings for specific target addresses. For example... Figure 8As shown, a given set of index bits L0I can be used to index into a level-zero page table 150, the location of which in memory is identified by a level-zero (L0) base address 151. The index entries of L0 table 150 identify pointers to L1 base addresses, which identify the location of L1 page table 152 in memory. A different subset of the index bits L1I from the target address selects one entry from the entries of L1 page table 152, which then identifies an L2 base address, the memory location of L2 page table 154. Another subset of the index bits L2I from the target address indexes into L2 page table 154 to identify an L3 base address, the location of L3 page table 156. Then, yet another subset of the bits L3I from the target address selects a specific entry from L3 page table 156, which provides the actual address mapping (and any associated access permissions and / or PAS selection information) for mapping the target address to a translation address (such as a physical address). Therefore, L3 page table 156 is the final page table that provides leaf page table entries, which provide actual address mapping information, and higher-level page tables 150, 152, and 154 provide intermediate entries that identify the base address of the next-level page table.

[0107] It should be understood that providing four levels of page tables is merely an example, and other examples may use page tables with different numbers of levels. Furthermore, it is possible that if larger address space blocks are to share the same translation mappings and other information, one entry in the higher-level page tables 150, 152, and 154 could be designated as a leaf entry that directly provides the address mapping, eliminating the need for further stepping through subsequent levels (while other entries within the same higher-level page tables 150, 152, and 154 can still serve as branch entries including base addresses pointing to subsequent-level page tables).

[0108] By splitting the page table into different levels in this way, the total amount of memory storage required to store the entire page table structure can be reduced because there is no need to locate address mappings for a given amount of address space in a memory region that has a size proportional to the size of the mapped address. This takes advantage of the fact that typically larger blocks of address space do not have any mappings defined by the operating system or other processes that set the address translation data. Although Figure 8 Examples are shown where index bits L0I, L1I, etc. are used directly as indexes for selecting corresponding page table entries, but an index can also be the result of a hash function applied to the index bits.

[0109] In some systems, TLB 18 may include separate cache structures for caching translation entries from different levels of page tables. For example, TLB 18 may include a main TLB structure for caching leaf entries from the final-level page table 156, and walk cache structures for caching higher-level page table entries from page tables 150, 152, and 154. Alternatively, other embodiments may provide a TLB using a shared cache structure to cache address translation data from multiple levels of page tables. Other embodiments may cache only leaf entries that can be looked up to provide an address mapping corresponding to a given VA, but may not carry branch entries from higher-level page tables 150, 152, and 154. Any of these methods may be used. Although Figure 1 A single TLB 18 is shown, but some implementations may include a multi-level TLB cache structure in the cache hierarchy to trade off capacity for access latency (e.g., a smaller number of entries stored in level 0 TLB for fast access, and a larger number of entries stored in level 1 TLB for slower access in case of a miss in level 0 TLB).

[0110] For some operating states of processor 10, the address translation process may involve multiple address translation stages (whether one or two address translation stages are required may depend on the configuration information set in the current exception level 15 and / or register 12). For example, in stage 1 translation, the VA used to identify a memory location by instructions executed by an application or operating system running on CPU 4 can be translated into an intermediate physical address (IPA). The stage 1 address translation structure used to control stage 1 address translation can be set, for example, by the operating system or another process operating at EL1. From the operating system's perspective, the IPA generated in stage 1 address translation can be assumed to be the physical address of the actual memory location being accessed. However, to support virtualization and prevent conflicts between the same IPA used by different operating systems coexisting on the same device, the hypervisor or other process operating at EL2 can then provide a further second-stage address translation between the IPA and PA to the memory system. See above reference. Figure 4 and Figure 5 As described, these PAs can be PAs within a selected physical address space, and some pre-POPA memory system components can treat the same PA values ​​in different physical address spaces as if they refer to different physical locations. Therefore, a second-stage translation table structure defined by the code operating at EL2 can exist to control stage 2 address translation.

[0111] Note that each of the two stages of address translation can use multiple levels of page tables, such as... Figure 8As shown. Therefore, a full page table walk to identify the address mapping of a given address block identified by the target VA may require each base address of the page table used in stage 1 address translation to undergo stage 2 address translation before accessing the corresponding level of stage 1 page table. That is, for an example where both stage 1 and stage 2 tables include four levels of page tables, such as... Figure 8 As shown, a complete page table walkthrough may include accessing multiple levels of page tables in the following sequence:

[0112] The stage 2 translation is from the base address 121 of the stage 1 level 0 page table to PA (the stage 1 level 0 base address can be the IPA address because the stage 1 translation structure is configured by the code operating at EL1). The stage 2 translation consists of 4 lookups (stage 2, level 0; stage 2, level 1; stage 2, level 2; stage 2, level 3).

[0113] Stage 1 Level 0 lookup based on the Level 0 index portion L0I of the target VA to identify the Stage 1 Level 1 Base Address (IPA).

[0114] Stage 2 translation from Level 1 base address to PA (also includes 4 lookups).

[0115] Stage 1 Level 1 lookup based on the L1I portion of the Level 1 index of the target VA to identify the Stage 1 Level 2 Base Address (IPA).

[0116] Stage 2 translation from the base address to the PA at level 1 (also includes 4 lookups)

[0117] Stage 1 Level 2 lookup based on the Level 2 index portion of the target VA to identify the Stage 1 Level 3 Base Address (IPA).

[0118] Stage 1 Level 3 base address to PA Stage 2 translation (also includes 4 lookups).

[0119] Stage 1 Level 3 lookup based on the Level 3 index portion L3I of the target virtual address to identify the target IPA corresponding to the target VA.

[0120] The stage 2 translation from target IPA to target PA (also includes 4 lookups) can be returned as the translated address corresponding to the original target VA.

[0121] Therefore, without any cache, the translation would involve a total of 24 lookups. As can be seen from the sequence above, performing a full page table walk can be very slow, as it may require numerous memory accesses to progressively traverse each page table level within each address translation stage. This is why it is often desirable to cache not only the last-level address mapping but also information from entries in the higher-level page tables within the Stage 1 and Stage 2 tables of TLB 18. This allows at least some steps of the full page table walk to be bypassed, even if the last-level address mapping for a given target address is not currently in the address translation cache.

[0122] In systems supporting two address translation phases, some TLBs 18 can be implemented as split TLBs, where separate cache structures are provided to cache information from the phase 1 and phase 2 page table structures, respectively. In this case, two separate TLB lookups might be needed to handle a translation request for a given VA: one in the phase 1 TLB to identify the corresponding IPA, and another in the phase 2 TLB to identify the PA corresponding to the IPA. Alternatively, combined phase 1 and phase 2 TLBs 18 can be provided, where, although a page table walk operation for an address request undergoing both address translation phases requires separate lookups of the phase 1 and phase 2 page table structures to first identify the VA-to-IPA mapping and then the IPA-to-PA mapping, once this is complete, the combined phase 1 and phase 2 TLBs can be allocated entries that directly map the VA to the PA, so that in future accesses to the same VA, the PA can be read from TLB 18 without performing two separate lookups.

[0123] In a typical page table structure with multiple levels, such as Figure 8 As shown, the maximum number of levels in the structure is fixed (e.g., Figure 8 (The example shows four levels). Additionally, the table size at a given level of the table structure, the size of the address space region to which an individual table entry at a given level applies, and the position / size of the offset bits are typically fixed and completely immutable, or can vary based on global parameters set for the table structure as a whole.

[0124] For example, a 4-level page table structure can be implemented with a variable granularity size selectable from multiple options (e.g., 4, 16, or 64kB), and in this case, for an exemplary implementation, the size per entry, offset bit position / size, and table size can be as follows:

[0125] (Notice:

[0126] "Size per entry" indicates the size of the address range to which the information in a given page table entry at a given level applies (not the size of the table data for the entry itself).

[0127] "Particle size" refers to the size of each block descriptor entry at level 3;

[0128] "Offset bit" refers to the bit extracted from the input address (VA for stage 1, IPA for stage 2) to select a specific entry from the table at a given level of the table structure; and

[0129] "Table size" refers to the minimum table size that can be allocated to a table, which corresponds to the size of a table entry's data and 2. X The product corresponds to the size, where X is the offset in bits used to index into the table at that level. This particular example assumes that each table entry has 64 bits of table data, or 8 bytes, but other examples may use different entry sizes.

[0130]

[0131] In this particular example, there is a restriction on using 52-bit addresses, and the maximum virtual address region size is 48 bits when the selected granular size is 4kB or 16kB. Similarly, the output address is limited to 48 bits. In this example, 52-bit addresses can only be used when using a 64kB granular size. Of course, other examples can define address sizes other than 52 bits.

[0132] It should be understood that the above represents the offset portions for each level for a specific example, and the specific offset portion size / position is not required. However, it is used to illustrate that in a typical page table, the position / size of the offset portion extracted for a given table level is the same for all tables at that level throughout the entire table structure (they do not vary between different tables at the same level), and is fixed for that level (if only a fixed granular size is supported), or is variable based on global parameters defined for the table structure as a whole.

[0133] It should also be noted that if a block descriptor entry is defined at a level other than level 3, it defines access control information applicable to a region of a size indicated by the "per-entry size" of that level. For example, for a 4kB granular size, any entry (table descriptor or block descriptor) at level 1 would be applicable to a 1GB region. Therefore, if all addresses in an adjacent 1GB region would share the same access control attributes, the block descriptor can only be defined at level 1 (any address mappings associated with permissions indicated in the page table, and PAS selection information). If a 4kB region with different access control attributes is to be defined, a block descriptor entry will need to be provided at level 3, and the full four traversal levels of the page table structure will be required.

[0134] Figure 9 This is a flowchart illustrating a method for selecting the PAS based on the current domain and information 124, 126 from the block / page PTE for generating a physical address for a given memory access request. PAS selection can be performed by the address translation circuitry 16, or by a combination of the address translation circuitry 16 and the PAS filter 20 if the address translation circuitry forwards the PAS selection information 126 to the PAS filter 20.

[0135] exist Figure 8 At step 130, the processing circuitry 10 issues a memory access request specifying a given virtual address (VA) as the target VA. At step 132, the address translation circuitry 16 searches its TLB 18 for any page table entries (or cached information derived from such page table entries). If any required page table information is unavailable, the address translation circuitry 16 initiates a page table roaming to memory to obtain the required PTE (potentially requiring a series of memory accesses to progressively traverse the corresponding levels of the page table structure, and / or potentially requiring multiple stages of address translation to obtain a mapping from VA to intermediate address (IPA) and then from IPA to PA). It should be noted that any memory access request issued by the address translation circuitry 16 during the page table roaming operation may itself undergo address translation and PAS filtering, so the request received at step 130 may be a memory access request issued to request a page table entry from memory. Once the relevant page table information has been identified, the virtual address is translated into a physical address (possibly via IPA in two stages). At step 134, the address translation circuitry 16 or the PAS filter 20 uses... Figure 6 The method shown determines which domain is the current domain.

[0136] If the current domain is a non-secure domain, then at step 136, the output PAS selected for the memory access request is a non-secure PAS.

[0137] If the current domain is a secure domain, then at step 138, an output PAS is selected based on PAS selection information 126, which provides the physical address and is included in the block / page descriptor PTE, wherein the output PAS will be selected as a secure PAS or a non-secure PAS.

[0138] If the current domain is a domain domain, then at step 140, an output PAS is selected based on PAS selection information 126 included in the block / page descriptor PTE from its derived physical address, and in this case, the output PAS is selected as a domain PAS or a non-secure PAS.

[0139] If the current domain is determined to be the root domain at step 134, then at step 142, the output PAS is selected based on the PAS selection information 126 from which the physical address is derived in the root block / page descriptor PTE 114. In this case, the output PAS is selected as any physical address space in the physical address space associated with the root domain, the domain, the security domain, and the non-security domain.

[0140] Figure 10 This is a flowchart illustrating the filtering of memory access requests by the filtering circuitry system 20. In step 170, a memory access request is received from the address translation circuitry system 16 (assuming any permission checks performed by the address translation circuitry system have passed). The received memory access request specifies a target PA and is associated with an output PAS (also referred to as the "selected PAS"), which is configured to... Figure 9 As described above, the output PAS can be indicated by the address translation circuitry 16, which provides an explicit identifier indicating the selected PAS, or by the address translation circuitry 16 forwarding PAS selection information 126 read from the page table to the filter circuitry 20. This PAS selection information, together with an indication of the current domain of the processing circuitry 10, can be used to determine the output PAS at the filter circuitry 20.

[0141] In step 172, the filter circuit system 20 obtains the particle protection information (GPI) corresponding to the target PA. This can be done by obtaining the GPI from the particle protection information cache 22 (if it is already in the cache), or by the GPT walk circuit system 23 obtaining the GPI from memory by performing a particle protection table walk. The following is about... Figure 13 The method for performing GPT walks is further described.

[0142] Once the GPI corresponding to the target PA has been obtained, in step 174, the filter circuit system 20 determines whether the output PA is indicated as an allowed PA by the GPI associated with the target PA. If the output PA is not indicated as an allowed PA by the GPI for the target PA, in step 178, the memory access request is blocked and a fault is signaled. The signaled fault may be associated with a fault type that indicates the fault will be handled by the program code executed in the root domain at EL3, and may be associated with fault syndrome / status information indicating the cause of the fault, such as identifying the target PA being accessed by the memory access request that caused the fault. On the other hand, if the output PA for the memory access request is indicated as an allowed PA by the GPI, in step 176, the memory access request is allowed to be passed to cache 24 or interconnect 8, so that the memory access request can be serviced by the memory system below. The memory access request, along with the indication of the target PA and the PA associated with the memory access request, is passed to cache 24 and / or interconnect 8. Therefore, the filtering circuit system 20 can govern whether the target PA of the memory access request is allowed to be accessed as part of the physical address space selected for the request, in order to enforce physical address space isolation and partitioning, as described above. Figure 4 and Figure 5 As shown.

[0143] The particle protection meter accessed by the GPT walking circuit system 23 can be used as follows Figure 8 The table structure shown has multiple levels, where each level stores a pointer to the beginning of the table at the next level. The complete table is traversed by extracting offsets from static locations within input addresses, where these locations are defined by the granularity, and the maximum number of nested table levels is fixed. A typical approach to managing protected tables is to use a nested structure based on the constraint that the maximum memory available for storing "branch tables" (tables not at the last level) or "leaf tables" (tables at the last level) has a constant size, such as a single page.

[0144] However, since the GMPU 20 is managed by a root of trust, it can reside in an opening with more memory linearity available for utilization. We propose a novel table format that allows this property to be leveraged and page tables of varying numbers of levels can be combined at each “subtree” of the page table. Thus, the example described below provides a method for efficiently storing protection information at the physical page granularity. This is achieved through a novel reverse page table format. In its basic form, the reverse page table is indexed by the address of a physical page (or “physical granule”) and stores information associated with that page. The granular protection table format introduced here has a structure that allows for more trade-offs between the following parameters: the address range covered by the table, the maximum number of lookups required to traverse the table, and the static cost (table size) that must be paid by leveraging linear ranges and localization parameters. The observation used is that locations with physical address space require the fastest possible access, while other locations may have more relaxed performance requirements, thus providing an opportunity to save table area. This is achieved by allowing offsets to have a size / location calculated based on parameters extracted from entries within the table itself.

[0145] By applying "mixed nesting" to GPT, each entry at the first level of the table can span "subtrees" with different maximum lookup counts. This is called the nesting level (NL):

[0146] The size of the table at any level other than the last level is defined by a set of constants specific to each {NL, level}.

[0147] The size of the table at the last level of the subtree is calculated based on the remaining range that must be covered after considering all previous levels.

[0148] The size / position of the offset in the table used to index to a given level of the table structure depends on the NL and the level of the table.

[0149] Therefore, we propose an efficient nested page table format in which the size of the table at each level is not necessarily a fixed size (as is the common practice in the prior art), and the maximum number of levels at each "subtree" within the nested page table is not necessarily a global constant.

[0150] The granular protection table describes the access permissions of physical pages within the system's address space. Since not all address ranges within the system's address space include pages requiring protection, the basic structure of the table can be a two-level table, where entries in the first level (L0GPT) describe the characteristics of memory blocks or include pointers to the table in the second level (L1GPT). However, such a structure can be further developed into "dense subtrees" with fast traversal and utilization of large linear memory, and "sparse subtrees" requiring longer traversal but with moderate memory allocation requirements.

[0151] Figure 11 An example of the format of a GPT entry is shown. A GPT entry can be a table descriptor entry 180 that points to a GPT entry at the next level, or a block descriptor entry 200 that provides particle protection information (GPI) specifying the protection characteristics of the corresponding particle or physical address. Figure 11 As shown, a block descriptor GPT entry 200 includes multiple GPI fields 194, each GPI field providing information associated with a corresponding particle at a physical address. Since only a few bits are needed to define the permissions associated with a page, a single block descriptor table entry 200 can include the GPI characteristics of multiple particles. As an example, the size of a block descriptor entry 200 in the last level of the protection table can be 8 bytes and contain 16 four-bit fields 194, where each field (particle protection information or GPI) 194 specifies the protection characteristics of a single physical particle.

[0152] For example, the protection features described by GPI can be:

[0153] The physical address space (PAS) associated with the particle (identifying the PAS as allowed and all other PAS as disallowed).

[0154] The specified particle is not associated with any PAS (and is therefore inaccessible, i.e., there is no PAS among the allowed PAS).

[0155] The encoding that specifies that a particle can be associated with any PAS (i.e., all PAS are allowed PAS).

[0156] In the example of supporting restricted sharing as described above, other encodings can identify that a subset of two or more PASs in a PAS are allowed PASs, but at least one other PAS is not allowed PASs.

[0157] The mapping of each different protection feature in GPI field 194 can be arbitrarily chosen for a specific instruction set architecture. For example, different four-bit codes such as 0000, 0001, and 0010 can be assigned to different features selected from the list above.

[0158] Therefore, each GPI field 194 provides information identifying zero or more allowed physical address spaces associated with the corresponding physical address granule. GPI encoding can also be assigned to indicate other information, and therefore, each GPI field does not necessarily need to be as... Figure 11 In the specific example, it is four digits. Not all encodings of the GPI field are valid. There may also be some invalid encodings, which are reserved for future expansion or after all options for the GPI deemed necessary have been encoded. Other invalid encodings may be used to represent information other than the valid options for the GPI attribute, such as the adjacency indicator 300 described further below.

[0159] Table descriptor GPT entry 180 includes several pieces of information, including a nesting level (NL) parameter 190, a next-level table pointer 193 providing the address of the start of the granular protection table at the next level of the table structure, and a type identifier field 196 distinguishing table descriptor entry 180 from block descriptor entry 200. Note that block descriptor entry 200 itself does not need to have a type ID field 196 because the type ID field 196 in table descriptor entry 180 can be selected to have a value that would not appear for any valid GPI encoding when the GPI field is set for the corresponding portion of the block descriptor entry used to encode the type ID field 196 in table descriptor entry 180. For example, the type ID field 196 in table descriptor entry 180 can be recorded at the location of a specific GPT field in GPT field 194 in the block descriptor entry and set to an invalid encoding in the invalid encoding of said GPT field 194. This allows for more efficient use of the encoding space of block descriptor entry 200 by avoiding the need for an explicit type ID field.

[0160] Optionally, table descriptor entry 180 may also specify one or more attributes 192, which can provide additional information associated with the address region, the attributes of which are represented by the lower subtree of the table structure. It should be understood that, although... Figure 11 Not shown, but the corresponding GPE 180, 200 may also include unspecified information. Furthermore, Figure 11 The specific order of fields 190, 192, 193, and 196 shown is just an example, and other examples may have fields in a different order.

[0161] The variable nesting level parameter 190 NL controls several aspects associated with the nesting of tables at multiple levels within the GPT table structure. Specifically, by changing the nesting level parameter for the initial level granularity protection table (e.g., the L0 granularity protection table accessed based on the stored GPT base address, similar to the L0 granularity protection table accessed based on the stored GPT base address), the nesting level parameter NL controls various aspects associated with the nesting of tables at multiple levels within the GPT table structure. Figure 8 The NL specified in the table descriptor entry 180 for a specific address access in the L0 base address 151 (L0 table 150) shown for page table walks, the GPT walk circuitry system 23 changes the size and position of the corresponding offset portion used to index into the target physical address in the corresponding level of the table within the multi-level GPT structure. The NL parameter 190 also controls the maximum number of levels traversed to reach the block descriptor entry 200 at a given physical address, the table size (memory footprint) associated with the table at a given level of the table structure, and the "size per entry," which indicates the size of the address range to which the information in a given table entry at a given entry applies.

[0162] In this example, the NL field 190 is ignored for any table descriptor accessed at levels other than the start level of the table structure, such that the NL parameter 190 within the start level of the table structure controls how all tables in the corresponding subtree under the start-level table descriptor entry 180 are accessed.

[0163] In this example, the following global parameters are specified for the table:

[0164] PGS[1:0] - Physical particle size (e.g., encoded such that PGS=0 indicates a particle size of 4KB, PGS=1 indicates a particle size of 16KB, and PGS=2 indicates a particle size of 64KB).

[0165] SL [1:0] - Starting level (0 - level 0, 1 - level 1, 2 - level 2, 3 - level 3). For tables that can be up to 4 levels deep, the starting level is level 0; for tables that can be up to 3 levels deep, the starting level is level 1, and so on.

[0166] SLBS [5:0] - Start-level block size - an exponent of the block size described by the entry at the start level (block size = 2^SLBS).

[0167] TSZ[5:0] is the exponent of the total size of the memory described by the table (total size = 2^TSZ).

[0168] For each entry at the starting level, the following parameters are specified:

[0169] Entry type 196 (block / descriptor)

[0170] Nesting Level (NL) 190 - The nesting level defines the maximum number of levels that make up a subtree (1 = 2 levels, 2 = 3 levels, etc.). NL defines which bits of the input address will be used as offsets to access the table at the next level.

[0171] The table size is defined as follows:

[0172] The size of a table at the starting level is defined by the total size and the block size.

[0173] The size of the table at any other level that is not the last level is a constant defined by {NL, level}, where NL is obtained from the starting level table entries accessed on the path traversing the tree structure to reach the tables at said other levels.

[0174] The size of the table at the last level of the subtree is calculated based on the remaining range that must be covered after considering all previous levels.

[0175] The following example illustrates how NL can be used to calculate the offset for traversing each subtree within a mix table. The example is based on the following principle (obviously, the principle may vary for other examples):

[0176] The table entry size (TES) is 8 bytes.

[0177] The particle size (GS) is 2^(12+PGS).

[0178] The entries in the tables at the final level have 16 GPI fields, where each GPI describes the characteristics of a single particle. The GPI size (GPIS) is 4 bits.

[0179] The entries in the table at the starting level describe a BlockSize (BS) of size 2^SLBS, so the table size itself is (2^TSZ / BS)*TES.

[0180] If StartLevel.NestingLevel indicates a subtree consisting of two levels, then the table size at the second level is (BS / GS)*GPIS.

[0181] If StartLevel.NestingLevel indicates a subtree consisting of 3 levels, then

[0182] ○ The table size at the second level is GS

[0183] The table size at the third level is ((BS / (GS / TES)) / GS)*GPIS

[0184] If StartLevel.NestingLevel indicates a subtree consisting of 4 levels, then

[0185] ○ The table size at the second level is GS

[0186] ○ The table size at the third level is GS

[0187] The table size at level 4 is ((BS / (GS / TES) / (GS / TES)) / GS)*GPIS

[0188] The offset can be derived from the NL parameter and the global parameter as follows (where SL represents the starting level, and SL.NL refers to the NL parameter specified by the entry in the starting level table selected by the starting level offset portion based on the destination address):

[0189]

[0190] Note that if SL.NL=1, the table at level SL+2 or SL+3 cannot be accessed because the maximum number of tables is 2, including the starting level. Similarly, if SL.NL=2, the table at level SL+3 cannot be accessed. Therefore, the table at level SL+3 can only be accessed when SL.NL=3. Furthermore, for the table at SL+1, when SL.NL=1, the table will have a larger size (and be indexed based on the larger offset) compared to SL.NL=2 or 3. Similarly, for the table at SL+2, when SL.NL=2, the table will have a larger size (and be indexed based on the larger offset) compared to SL.NL=3.

[0191] Additionally, note that in this example, the lower bits of the last level table are 12 + PGS*2 + 4 (not 12 + PGS*2), because... Figure 11 In the example, the 16 GPI entries for the 16 corresponding granules for the physical address are packed into a single block descriptor entry, so bits 15:12 of the target PA will be used to select which specific GPI of the block descriptor entry corresponds to the target PA, and therefore do not need to be used as offset bits for selecting table entries.

[0192] As a specific example, for PGS=0 (4kB particles), SL=0, SLBS=39 (starting block size of 512GB) and TSZ=48:

[0193]

[0194] It should be understood that providing the flexibility to change the aforementioned global parameters PGS, SL, SLBS, and TSZ is optional, and therefore any of these parameters can be fixed for a given implementation. The global parameters PGS, SL, SLBS, or TSZ do not need to be variable and can be selected by software at runtime. Alternatively, other methods can support variable definitions of these global parameters. Regardless of whether the global parameters are variable or fixed, defining a variable nesting level NL in the entry at the start level of the GPT structure enables a trade-off between the performance of locating a given target address in the GPI and the size of the address range in memory that needs to be allocated for table data to protect the target address.

[0195] Figure 12 A specific example of a GPT layout with variable nesting is shown, controlled by the NL parameter 190 in the L0 table descriptor entries. In this example, for a region of PA space allocated for Dynamic Random Access Memory (DRAM), it is more likely that this region will store performance-critical data that may need to be accessed quickly by the processor, and therefore it is probably preferable to reduce the maximum number of tables that need to be accessed to locate the corresponding GPI for a given physical address in this region. Therefore, the L0 GPT entries corresponding to physical addresses in the DRAM region are set to NL=1, such that they point to one or more larger L1 tables that together have a sufficient size to include GPI fields with a 4kB granularity across the DRAM region. For example, this could be multiple 64MB tables, each containing 2 23 Each L1 table entry provides 16 GPIs for the corresponding 4kB particle. Note that the reduction in the number of table levels (2 instead of the usual 4) comes at the cost of having to allocate a larger (64MB instead of 4kB) contiguous memory block for each individual L1 table.

[0196] In contrast, for regions mapped to the physical address space of Memory Mapped Input / Output (MMIO) devices, there may only be a few 4K particles for which mapping needs to be defined, and performance may not be critical for such access in these regions. For such regions, allocating the 64 MB L1 table can be considered a waste of memory space when only a few entries are expected to include valid GPIs. Therefore, by setting NL=3 in the L0 table descriptor entries corresponding to addresses in the MMIO region, the subtree of the MMIO region can be implemented more efficiently in memory by providing four levels of page tables, each with a table of size 4kB, such that the subtree providing the chain of entries at levels 1 to 3 for accessing specific 4kB particles includes 12kB of table data instead of 64MB of data as in a DRAM region. While the more memory-efficient subtree will be accessed more slowly than the subtree in the DRAM region, this is not a problem for MMIO regions where performance may not be critical.

[0197] Of course, although Figure 12 This illustrates an example of the performance tradeoff between DRAM and MMIO regions relative to memory footprint in different subtrees of the same table structure, but users can find many other use cases for leveraging different levels of nesting within the same table. For example, some level 0 table entries could specify a nesting level of 2 to indicate that the maximum number of levels is 3, but this... Figure 12 The example is not shown.

[0198] Note that even though NL indicates the maximum number of table levels required to find the GPI of the corresponding particle with the physical address, this does not preclude the possibility that block descriptor entries 200 can still be defined at earlier levels of the table structure to define uniform properties for larger memory blocks. Therefore, the variable parameter NL defines the maximum number of table levels to be traversed for a particular subtree of the structure under L0 table descriptor entry 180 with specified NL parameter 190, but this does not mean that every level in the table structure must be accessed up to the maximum number, and that a traversal of the table structure may encounter block descriptor entries 200 at earlier levels.

[0199] Despite Figure 8 In the page table structure, the number of table levels required to reach a block descriptor entry can be reduced by defining block descriptor entries 200 at levels other than the last level of the table. This reduces the number of steps required to traverse the structure to reach the block descriptor entry. However, this approach is only suitable when there are regions with a large number of physical addresses that all need to share the same GPI characteristics. This is because in situations similar to... Figure 8In the conventional multilevel table structure with a fixed-size offset shown in the method for page tables, for a 4kB granular size example, a given entry at level 1 would be indexed using L1I offset bits 38:30, making each L1 entry suitable for an address range of size 1GB. Therefore, all addresses that share the same L1I offset bit 38:30 would need to have the same access control attributes if they were to share a single block descriptor entry defined at level 1.

[0200] In contrast, utilizing Figure 12 The method shown, when indexing a DRAM region table in the physical address space at level 1, with NL=1, uses an index based on a larger offset portion including bits 38:16 (for the specific example above), thus covering all remaining offset bits not yet used for indexing a level 0 table. This means each entry corresponds to a smaller, separate address block (64kB, providing a separate GPI field for 16 4kB particles), allowing for finer-grained control over protection attributes despite only providing two levels of tables, rather than using the approach described above. Figure 8 The discussion covers the control that can be implemented for L1 block descriptor entries with fixed offset indexes.

[0201] Figure 13 This is a flowchart illustrating a method for performing a GPT walk to obtain a GPI from memory for a given target PA. A GPT walk can be used as... Figure 10 This is performed as part of step 172. For implementations with a granular protection information cache 22 (or a combined TLB / granular protection information cache 22), this can be performed when a memory access request misses in the granular protection information cache 22. Figure 13 For cache implementations that do not support granular data protection, a method can be executed for each memory access. Figure 13 The GPT walking method is executed by the GPT walking circuit system 23.

[0202] In step 240, the size and location of the start-level (SL) offset portion within the target PA are determined based on the start-level block size SLBS and the previously described total memory size TSZ. In an implementation where both the start-level block size and the total memory size are fixed, step 240 can be omitted because the start-level offset size and location can be hardwired to a fixed size and location. However, in cases where one or both of SLBS and TSZ are variable, some circuitry may be present to determine the start-level offset using control parameters defining one or both of SLBS and TSZ according to PA[TSZ-1:SLBS] as shown above.

[0203] In step 242, the GPT walk circuit system 23 obtains the starting level GPT entry corresponding to the target PA by reading the address determined by adding a multiple of the SL offset portion of the PA (with the size and location determined in step 240) to the SL base address stored in the GPT base address register. Once the starting level GPT entry has been returned from memory, in step 244, the GPT walk circuit system 23 determines whether the starting level GPT entry is a block descriptor or a table descriptor (if the type ID field 196 has a value indicating a table descriptor entry 180, then the entry is a table descriptor entry 180, and otherwise the entry is a block descriptor entry 200). If the starting level GPT entry is a block descriptor entry 200, in step 246, the GPI for the target PA is extracted from the GPI field 194 located at the location corresponding to the target PA (e.g., some bits PA[15:12] of the target PA can be used to select which GPI field to use), and the extracted GPI is then returned to the PA filtering circuit system 20 to perform a check on whether the memory access request is allowed, such as... Figure 10 As described in step 174.

[0204] If the initial level GPT entry is a table descriptor, then in step 248, the variable nested control parameter NL 190 and the next-level table pointer 193 are extracted from the initial level GPT entry obtained in step 242. In step 250, due to... Figure 13 The purpose of the subsequent steps is to make the next level of the table structure the "current level". Therefore, if step 250 is reached after step 248, the next level will become a level beyond the starting level, for example... Figure 12 In the example, level 1, where the starting level is level 0. The loop begins through steps 252 to 260, which executes for each subsequent level of the table structure reached during the traversal, until the final block descriptor entry 200 is identified and the traversal ends.

[0205] In step 252, the size and position of the current level offset portion in the current level used for indexing into the GPT are determined based on the variable nesting control parameter NL 190 and the current level. This is done according to the offset equations shown in the table above for the corresponding levels SL+1, SL+2, and SL+3. Therefore, the size and condition of the offset portion for a given level vary depending on the variable nesting control parameter specified at an earlier level in the table, and can differ for different subtrees depending on which physical address is being accessed.

[0206] In step 254, after determining the address by adding the pointer 193 read from the previous level of the table to a multiple of the current level offset portion of the target physical address determined in step 252 (the multiple is based on the size of a GPT entry), the current level GPT entry is read from memory. In step 256, when the current level GPT entry has been returned from the memory system, the GPT walkthrough circuitry determines whether the current level GPT entry is block descriptor entry 200 or table descriptor entry 180. Similarly, if it is a block descriptor entry, in step 258, the GPI for the target PA is returned, as in step 246. However, if the current level GPT entry is table descriptor entry 180, in step 260, the next level pointer 193 is obtained from the current level GPT entry, and the method returns to step 250 to proceed to the next level of the table structure, and again loops through steps 252 to 256 for the next level of the table structure. The method continues until block descriptor entry 200 is finally identified, and the method ends in step 258.

[0207] Although not in Figure 13 As shown, however, the GPT walk circuitry system 23 may also have circuitry for identifying errors during the GPT walk, such as invalid coded GPT entries, or entries read from the index position of the level 3 table that are still not block descriptor entries even after reaching level 3. If any such error is identified, the fault can be signaled for handling by the root domain code at EL3.

[0208] Figure 14 This illustrates how multiple GPT entries can be grouped together by specifying an adjacency indicator 300, so that GPI information for all granules representing physical addresses by two or more different GPT entries 200 can be cached as a single entry in the granule protection information cache 22, thereby increasing cache coverage and thus improving cache hit rate, and consequently performance. Figure 14 In the example, block descriptor entry 200, which is not grouped together as adjacent entries, has the same characteristics as... Figure 11 The same format is shown. However, the GPI field at the least significant bits [3:0] of the block descriptor entry is used as a "pivot" GPI, which can have a special encoded value used to specify a uniform entry that uses a 64-bit entry to provide characteristics common to all granules mapped to that entry. Figure 14 The lower part shows the uniform adjacency entry format, in which, in addition to the adjacency indicator 300 at the pivot GPI position and having an encoding that is otherwise invalid for other GPIs, the adjacency GPT block descriptor format also specifies the adjacency size parameter 202 and GPI information 304 of the adjacency entry.

[0209] The adjacency indicator 300 allows multiple table entries to be collected to form a large block. The size parameter 302 specifies the size of the adjacent block for which the physical address of the entry is part. The GPI protection attributes of the adjacent block are specified in the remaining bits 304 of the block descriptor entry 200.

[0210] For example, in the working example above, the maximum allowed table-level block descriptor entries (L1 for NL=1, L2 for NL=2, or L3 for NL=3) would typically specify 64KB of attributes in the physical address space. However, using the adjacency indicator set, this 64KB block can be defined as part of a 512MB adjacency block with a single GPI attribute set. Therefore, all 8192 individual block descriptor entries for the 512MB adjacency block can have their GPT entries in memory set to specify the adjacency entry 300, the adjacency size parameter 302 identifying the 512MB size, and the same GPI information in the GPI field 304. This means that regardless of which address in the 512MB is accessed first, the corresponding GPT entry can be cached immediately, and the cache lookup mechanism of the granular protection information cache 22 ensures that any address in the 512MB block is subsequently considered to have hit a single cache entry, returning the shared protection attribute from the GPI field 304 when any address in the 512MB is accessed, even if only a single cache entry in the granular protection information cache 22 is occupied. This frees up many other cache entries for caching GPT entries for other addresses, thereby improving cache utilization.

[0211] Figure 14 The example illustrates one method where an invalid encoding is used for a specific GPI field 194 within block descriptor table entry 200 (e.g., the GPI field at the least significant bit of the block descriptor table entry) to indicate the adjacency indicator 300. However, this is not necessary, and other methods can provide a dedicated field in block descriptor table entry 200 to specify whether the entry is part of an adjacent block. Therefore, it is not necessary to use... Figure 14 The method shown represents the adjacency indication.

[0212] Figures 11 to 14 The characteristics of a GPT structure are illustrated, which includes variable nesting controlled by the nesting level parameter NL in the start-level table entries, and an adjacency indicator 300 that allows large blocks of entries to be merged together. These are particularly suitable for GPTs, but can also be applied to other types of access control tables to control access to memory, such as the page table structure used by the address translation circuitry system 16. Therefore, the page table walk circuitry system 17 can also use it when performing page table walks to identify address translation mappings. Figures 11 to 13The technique illustrated is as follows. The page table walk circuitry system 17 can use a variably defined offset portion to index into the corresponding level of the table structure, depending on the variable nesting control parameter NL defined in the access control table at a higher level than the table whose offset portion is determined. Although the GPT is a reverse page table indexed by physical addresses, similar techniques can also be used for non-reverse page tables indexed by virtual addresses to balance the size of the table data itself with the number of memory accesses required to reach the protection information associated with a specific address.

[0213] Figure 15 Emulator implementations that can be used are illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as emulators, in part because they provide a software-based implementation of a hardware architecture. Types of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, emulator implementations can run on a host processor 430 supporting an emulator program 410, which optionally runs a host operating system 420. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide emulator implementations that execute at a reasonable speed, but this approach may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, emulator implementations may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0214] With respect to embodiments previously described with reference to specific hardware constructions or features, in simulated embodiments, equivalent functionality may be provided by suitable software constructions or features. For example, a particular circuit system may be implemented as computer program logic in a simulated embodiment. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in a simulated embodiment. One or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 430), and where appropriate, some simulated embodiments may utilize the host hardware.

[0215] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 400 (which may include applications, operating systems, and management programs), the program interface being identical to the interface of the hardware architecture modeled by the simulator program 410. Therefore, the simulator program 410 can be used to execute the program instructions of the target code 400 from within the instruction execution environment, allowing the host computer 430, which does not actually possess the hardware features of the device 2 discussed above, to emulate these features. This is useful, for example, for allowing testing of the target code 400 being developed for a new version of the processor architecture before a hardware device actually supporting the architecture is available, since the target code can be tested by running it within a simulator executed on a host device that does not support the architecture.

[0216] The simulator code includes processing program logic 412 that simulates the behavior of the processing circuit system 10. For example, it includes instruction decoding program logic that decodes the instructions of the target code 400 and maps the instructions to corresponding instruction sequences in the native instruction set supported by the host hardware 430 to perform functions equivalent to the decoded instructions. Processing program logic 412 also simulates the processing of code in different exception levels and domains as described above. Register emulation program logic 413 maintains data structures in the host processor's host address space, emulating the architecture register states defined according to the target instruction set architecture associated with the target code 400. Therefore, it is not as... Figure 1 Instead of storing this architectural state in hardware register 12 as in the example, it is stored in the memory of the host processor 430, where register emulation logic 413 maps register references of the instructions of the target code 400 to corresponding addresses to obtain the simulated architectural state data from the host memory. This architectural state may include the previously described current domain indicator 14 and current exception level indicator 15.

[0217] The simulation code includes address translation program logic 414 and filtering program logic 416 (both examples of memory management program logic 419), which respectively reference the same page table structure as described above and the functionality of the GPT 56 emulated address translation circuit system 16 and PAS filter 20. Therefore, address translation program logic 414 translates the virtual address specified by target code 400 into a simulated physical address in the PAS (from the target code's perspective, it refers to a physical location in memory), but in reality, these simulated physical addresses are mapped to the host processor's (virtual) address space by address space mapping program logic 415. Filtering program logic 416 performs a lookup of particle protection information in the same manner as the aforementioned PAS filter to determine whether memory access triggered by the target code is allowed to proceed.

[0218] The table access program logic 418 simulates the functions of the page table walk circuitry 17 and the GPT walk circuitry 23 to control the loading of page table and GPT entries from simulated memory (mapped to the virtual address space of the host processor by the address space mapping program logic 415). However, for the simulator, the TLB 18 and the particle protection information cache 22 may not be simulated, so the simulator implementation will behave like a hardware device without any TLB 18 or GPT cache 22. Therefore, each memory access request will be treated as if it were a cache miss, and thus each memory access may require a page table walk and / or a GPT walk. As in the hardware implementation, for the simulated implementation, the page table structure and / or GPT structure can be implemented with variable nesting having an offset portion selected based on the size / position of the offset portion specified in the higher-level table entry.

[0219] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operation.

[0220] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes and modifications can be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus for controlling access to a memory system, the apparatus comprising: A memory management circuitry system for controlling access to a memory system based on access control information defined in table entries of a table structure comprising multiple levels of access control tables; and A table access circuitry system is used to access the table structure to obtain the access control information corresponding to the target address; wherein: For a given access control table at a given level other than the initial level of the table structure: The table access circuitry is configured to select a chosen table entry in a given access control table corresponding to the target address based on an offset portion of the target address. The selected table entry provides a pointer to the access control table at the next lowest level of the table structure or the access control information corresponding to the target address. The table access circuitry is configured to determine the size of the offset portion of the target address based on variable nesting control parameters specified in a table entry of a higher-level access control table at a higher level than the given access control table in the table structure.

2. The apparatus of claim 1, wherein the variable nested control parameter is specified separately in the corresponding table entry of the higher-level access control table.

3. The apparatus of claim 2, wherein when different entries of the higher-level access control table specify different values ​​for the variable nested control parameter, the size of the offset portion used by the table access circuitry to select the selected table entry is different for different access control tables at the given level of the table structure.

4. The apparatus according to any one of claims 1 to 3, wherein the maximum number of levels of the table structure to be traversed to reach the table entry providing the access control information corresponding to the target address can vary depending on the variable nesting control parameter.

5. The apparatus according to any one of claims 1 to 3, wherein the table size of the given access control table can vary depending on the variable nesting control parameter.

6. The apparatus according to any one of claims 1 to 3, wherein for the given access control table at the given level of the table structure: Each table entry defines information applicable to an address range of a given address range size; and The size of the given address range can vary depending on the variable nesting control parameter specified in the table entry of the higher-level access control table.

7. The apparatus according to any one of claims 1 to 3, wherein the variable nesting control parameter is specified in a table entry of the start-level access control table at the start level of the table structure.

8. The apparatus according to any one of claims 1 to 3, wherein the table access circuitry is configured to obtain the access control information corresponding to the target address from a block descriptor table entry in an access control table at the last level of the table structure reached during traversal of the table structure, the block descriptor table entry specifying the access control information for including target address granularities of the target address.

9. The apparatus of claim 8, wherein the block descriptor table entry includes a plurality of access control information fields, each of the access control information fields indicating access control information for a different address granularity.

10. The apparatus according to claim 8, wherein: When the block descriptor table entry specifies an adjacency indication, the table access circuitry is configured to determine that the access control information for two or more different address granules including the target granule is represented by a shared set of access control information shared between the two or more different granules.

11. The apparatus of claim 10, wherein when the block descriptor table entry specifies an adjacency indication, the table access circuitry is configured to identify how many granules share the shared access control information set based on an adjacency size parameter specified in the block descriptor table entry.

12. The apparatus of claim 10, wherein the block descriptor table entry includes a plurality of access control information fields, each of the access control information fields being used to indicate access control information for a corresponding address granularity; When a predetermined access control information field among the plurality of access control information fields has a predetermined code other than a code in a valid set of codes used to indicate valid options for the access control information, the block descriptor table entry specifies the adjacency indication; and When one of the predetermined access control information fields among the plurality of access control information fields has the predetermined encoding, the shared access control information set is indicated by one or more other access control information fields in the block descriptor table entry or another block descriptor table entry corresponding to the target address.

13. The apparatus according to any one of claims 1 to 3, wherein the table structure is indexed by physical addresses.

14. The apparatus according to any one of claims 1 to 3, wherein the memory management circuitry system comprises: An address translation circuit system is configured to translate a target virtual address specified by a memory access request into a target physical address associated with a selected physical address space chosen from a plurality of physical address spaces; as well as A filtering circuit system is used to determine whether the memory access request should be allowed to access the target physical address based on whether the access control information obtained from the table structure indicates that the selected physical address space is a permitted physical address space for the target physical address.

15. The apparatus according to any one of claims 1 to 3, wherein the table structure is indexed by a virtual address.

16. The apparatus according to any one of claims 1 to 3, wherein the memory management circuitry includes an address translation circuitry for translating a target virtual address specified by a memory access request into a target physical address based on an address translation mapping indicated by the access control information obtained from the table structure.

17. A method for controlling access to a memory system, the method comprising: Access to the memory system is controlled based on access control information defined in table entries within a table structure that includes multiple levels of access control tables. as well as Access the table structure to obtain the access control information corresponding to the target address; wherein: For a given access control table at a given level other than the initial level of the table structure: Based on the offset portion of the target address, a selected table entry of the given access control table corresponding to the target address is selected, and the selected table entry provides a pointer to the access control table at the next lowest level of the table structure or the access control information corresponding to the target address. and The size of the offset portion of the target address is determined based on variable nested control parameters specified in a table entry of a higher-level access control table at a higher level than the given access control table in the table structure.

18. A computer program product comprising a computer program, the computer program including instructions that, when executed on a host data processing device, control the host data processing device to provide an instruction execution environment for executing object code; the computer program comprising: The memory management program logic is used to control access to the simulated memory based on access control information defined in table entries of a table structure that includes multiple levels of access control tables. as well as Table access procedure logic, wherein the table access procedure logic is used to access the table structure to obtain the access control information corresponding to the address of the target simulation; wherein: For a given access control table at a given level other than the initial level of the table structure: The table access procedure logic is configured to select a chosen table entry in the given access control table corresponding to the address of the target simulation based on an offset portion of the target simulated address. The selected table entry provides a pointer to the access control table at the next lowest level of the table structure or the access control information corresponding to the address of the target simulation. The table access procedure logic is configured to determine the size of the offset portion of the address of the target simulation based on variable nested control parameters specified in a table entry of a higher-level access control table at a higher level than the given access control table in the table structure.

19. A computer-readable storage medium storing a computer program, the computer program including instructions that, when executed on a host data processing device, control the host data processing device to provide an instruction execution environment for executing object code; the computer program comprising: The memory management program logic is used to control access to the simulated memory based on access control information defined in table entries of a table structure that includes multiple levels of access control tables. as well as Table access procedure logic, wherein the table access procedure logic is used to access the table structure to obtain the access control information corresponding to the address of the target simulation; wherein: For a given access control table at a given level other than the initial level of the table structure: The table access procedure logic is configured to select a chosen table entry in the given access control table corresponding to the address of the target simulation based on an offset portion of the target simulated address. The selected table entry provides a pointer to the access control table at the next lowest level of the table structure or the access control information corresponding to the address of the target simulation. The table access procedure logic is configured to determine the size of the offset portion of the address of the target simulation based on variable nested control parameters specified in a table entry of a higher-level access control table at a higher level than the given access control table in the table structure.

Images