Regional integration

Abstract

The domain management unit (RMU) 20 maintains an ownership table 128, which specifies ownership entries of corresponding memory regions, and the ownership entries define ownership attributes, and the ownership attributes specify the owner domain of the corresponding region from multiple domains. Each domain corresponds to at least a part of at least one software process. The owner domain has the right to exclude other domains from accessing the data stored in the corresponding region. Memory access is controlled based on the ownership table. In response to a regional fusion command that specifies a fusion target address, the fusion target address indicates a continuous region of the memory that will be fused into the fusion group of the region, and the regional fusion operation updates the ownership table to indicate that the ownership attribute of the fusion group of the region is represented by a single ownership entry. This provides architectural support for achieving improved TLB performance.

Description

Technical Field

[0001] The present technology relates to the field of data processing. Background Art

[0002] It is known to provide memory access control techniques for implementing access rights to specific memory regions. Typically, these techniques are based on privilege levels, so that processes executed with higher privileges can exclude processes with lower privileges from accessing memory regions. Summary of the invention

[0003] At least some examples provide an apparatus comprising:

[0004] processing circuitry that performs data processing in response to one or more software processes;

[0005] a domain management unit that maintains an ownership table that specifies a plurality of ownership entries, each ownership entry defining an ownership attribute for a corresponding region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the corresponding region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one software process, and the owner domain has the right to exclude other domains from accessing data stored in the corresponding region; and

[0006] A memory access circuit controls access to a memory based on an ownership table; wherein:

[0007] The domain management unit performs a region fusion operation in response to a region fusion command specifying a fusion target address, wherein the fusion target address indicates multiple consecutive regions of the memory that are to be fused into a fusion group of regions, and the region fusion operation updates the ownership table to indicate that the ownership attribute of each region in the fusion group of regions is represented by a single ownership entry corresponding to a predetermined region of the fusion group.

[0008] At least some examples provide a method including:

[0009] maintaining an ownership table specifying a plurality of ownership entries, each ownership entry defining an ownership attribute for a respective region of a predetermined size of the memory, the ownership attribute specifying an owner domain of the respective region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one software process processed by the processing circuit, and the owner domain has the right to exclude other domains from accessing data stored in the respective region;

[0010] controlling access to the memory based on the ownership table; and

[0011] A region merge operation is performed in response to a region merge command specifying a merge target address indicating a plurality of contiguous regions of memory to be merged into a fused group of regions, the region merge operation updating an ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group.

[0012] At least some examples provide a computer program for controlling a host data processing device to simulate processing one or more software processes on a target data processing device, the computer program comprising:

[0013] processing program logic that controls a host data processing device to perform data processing in response to object code representing the one or more software processes;

[0014] domain manager logic that maintains an ownership table that specifies a plurality of ownership entries, each ownership entry defining an ownership attribute for a respective region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the respective region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one software process, and the owner domain has authority to exclude other domains from accessing data stored in the respective region; and

[0015] A memory access program logic that controls access to the memory based on the ownership table; wherein:

[0016] The domain manager logic performs a region merge operation in response to a region merge command specifying a merge target address indicating a plurality of contiguous regions of memory to be merged into a fused group of regions, the region merge operation updating an ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group.

[0017] The computer program may be stored on a storage medium. The storage medium may be a non-transitory storage medium. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Further aspects, features and advantages of the present technology will become apparent from the following description of examples read in conjunction with the accompanying drawings, in which:

[0019] Figure 1 A data processing system is schematically shown, the data processing system comprising a plurality of processing components utilizing memory areas stored in a first memory and a second memory;

[0020] Figure 2schematically illustrating the relationship between a plurality of processes executed, the privilege levels associated with the processes, and the realms associated with the processes for controlling which process owns a given memory region and therefore has exclusive rights to control access to the given memory region;

[0021] Figure 3 schematically shows memory areas managed by a domain management unit and a memory management unit;

[0022] Figure 4 schematically illustrates a sequence of program instructions executed to output a given memory region from a first memory to a second memory;

[0023] Figure 5 A flowchart schematically showing page output;

[0024] Figure 6 schematically illustrates a plurality of domains and their relationship within a control hierarchy for controlling which output commands can interrupt which other output commands;

[0025] Figure 7 A flowchart schematically showing page input;

[0026] Figure 8 schematically illustrates a first output command source and a second output command source for performing overlapping output operations for a given memory region;

[0027] Fig. 9 A more detailed example of processing components and domain management control data stored in memory is shown;

[0028] Fig.10 shows an example of a domain hierarchy in which a parent domain may define domain descriptors that describe properties of various child domains;

[0029] Fig.11 and Fig.12 Two different instances of the domain hierarchy are shown;

[0030] Fig.13 An example of a domain descriptor tree maintained by an upper domain to record domain descriptors of its child domains is shown;

[0031] Fig.14 shows an example of a local realm identifier constructed from a plurality of variable length bit portions that each provide an index to a corresponding level of a realm descriptor tree;

[0032] Fig.15 shows examples of local and global domain identifiers for each domain in the domain hierarchy;

[0033] Fig.16 An example of the content of a domain descriptor is shown;

[0034] Fig.17 A table showing the life cycle states of different domains;

[0035] Fig.18 A state machine diagram to indicate the changes in the life cycle states of a domain;

[0036] Fig.19 a table showing the contents of an entry in the ownership table for a given memory region;

[0037] Fig. 20 Table to show visibility attributes that may be set for a given memory region to control which realms other than the owner are allowed to access the region;

[0038] Fig.21 shows examples of different life cycle states for memory regions, including states corresponding to RMU-private memory regions that are reserved for exclusive access by domain management units;

[0039] Fig. 22 A state machine for illustrating transitions of life cycle states for a given memory region;

[0040] Fig.23 shows how ownership of a given memory region can be passed between an ancestor realm and its descendant realms;

[0041] Fig.24 schematically illustrates memory access control provided based on page tables that define memory control attributes that depend on privilege levels and domain management unit levels that provide orthogonal levels of control over memory access based on permissions set by an owner domain;

[0042] Fig.25 An example of a translation lookaside buffer is shown;

[0043] Fig.26 A flowchart showing a method for controlling access to a memory based on a page table and an RMU table;

[0044] Fig. 27 shows the states accessible to processes executing at different exception levels;

[0045] Fig.28 A flowchart showing a method of entering a realm or returning from an exception;

[0046] Fig.29A flowchart showing a method of exiting a domain or taking an exception;

[0047] Fig.30 An example of entering a child domain and returning to a parent domain is shown;

[0048] Fig.31 An example of nested domain exit and nested domain entry is shown;

[0049] Fig.32 shows an example of using lazy saving of a realm execution context when exiting from a realm;

[0050] Fig.33 shows an example of the use of a flush command that ensures that a subset of the state associated with a previously exited child realm is saved to memory before entering a different child realm;

[0051] Fig.34 shows the use of sub-realms corresponding to specific address ranges within a process associated with an ancestor realm of a child realm;

[0052] Fig.35 showing a second example of a set of region states associated with a memory region;

[0053] Fig.36 It shows that according to Fig.35 A state machine for transitions between different regional states of an instance;

[0054] Fig.37 shows the change in the state of a region when the region changes ownership between the parent domain and the child domain;

[0055] Fig.38 is a flowchart showing an example of processing of outputting commands;

[0056] Fig.39 is a flowchart showing an example of processing of input commands;

[0057] Fig.40 shows the hierarchical structure of the conversion table;

[0058] Fig.41 An example of a linear table structure for an ownership table is shown;

[0059] Fig.42 Schematically illustrates examples of regions of merging and shattering ownership tables;

[0060] Fig.43 is a flow chart illustrating a method of processing a region blend command;

[0061] Fig.44 is a flow chart illustrating a method of processing a region splitting command; and

[0062] Fig.45 An example of a simulator that can be used is shown. DETAILED DESCRIPTION

[0063] Figure 1 A data processing system 2 is schematically shown, comprising a system-on-chip integrated circuit 4 connected to a separate non-volatile memory 6, such as an off-chip flash memory used as a mass storage device. The system-on-chip integrated circuit 4 includes a plurality of processing components in the form of (in this exemplary embodiment) two general purpose processors (CPUs) 8, 10, and a graphics processing unit (GPU) 12. It will be appreciated that in practice many different forms of processing components may be provided, for example, additional general purpose processors, graphics processing units, direct memory access (DMA) units, co-processors, and other processing components for accessing memory areas within a memory address space and performing data processing operations on data stored in these memory areas.

[0064] The general purpose processors 8, 10 and the graphics processing unit 12 are coupled to an interconnect circuit 14 through which they conduct memory transactions with an on-chip memory 16 and an external memory 6 (via an external memory interface 18). Figure 1 16 is on chip, but in other embodiments, the memory 16 may be implemented as off-chip memory instead. The on-chip memory 16 stores data corresponding to multiple memory regions within the overall memory address space. These memory regions correspond to memory pages and are subject to management operations that control which memory regions (pages) exist within the on-chip memory 16 at a given time, which processes can access the data stored in these memory regions and other parameters related to these memory regions. More specifically, in this exemplary embodiment, each of the processing components 8, 10, 12 includes a domain management unit 20, 22, 24 and a general memory management unit 26, 28, 30. The general memory management unit 26, 28, 30 is used to control aspects of the operation of the memory region, such as address mapping (such as mapping between virtual addresses and intermediate physical addresses, or physical addresses), privilege level constraints on processes that can access a given memory region, storage characteristics of data within a given memory region (such as cacheability, device memory status, etc.), and other characteristics of the memory region.

[0065] The domain management units 20, 22, 24 manage data for implementing ownership rights to a plurality of memory regions, whereby a given memory region has a given owning process (or owner "domain") specified from a plurality of processes (a process or domain is, for example, one of a monitor program, a manager program, a guest operating system program, an application program, etc., or a specific sub-portion of such a program). A given owning process (owner domain) for a given memory region has exclusive rights to control access to given owned data stored in the given memory region. Specifically, the owner process has rights to prevent access to the memory region owned by the owner process by a process executing at a higher privilege level than the owner process.

[0066] Thus, multiple memory regions are divided between multiple owner domains. Each domain corresponds to at least a portion of at least one software process and is assigned ownership of multiple memory regions. The owning process / domain has exclusive rights to control access to data stored in the memory regions of their domains. Management and control of which memory regions are memory-mapped to each domain is performed by processes other than the owner domain itself. Using this arrangement, processes such as a manager can control which memory regions (pages of memory) are included in the domains owned by corresponding guest virtual machines (guest operating systems), which are managed by the manager, but the manager itself may not actually have the right to access data stored in the memory regions that the manager has assigned to a given domain. Thus, for example, a guest operating system can keep data stored in the domain of the guest operating system (i.e., data stored in the memory region owned by the guest operating system) private to its managing manager.

[0067] The division of the memory address space into realms and the control of ownership of these realms are managed by a realm management unit 20, 22, 24 associated with each of the processing components 8, 10, 12, and are control processes that are orthogonal to the more traditional forms of control provided by the general memory management unit 26, 28, 30. The realm management unit 20, 22, 24 thus provides memory access circuitry to enforce ownership rights to memory regions of the memory address space. In some cases, the memory access circuitry that enforces realm ownership rights may also include portions of the MMU 26, 28, 30 (e.g., a TLB in the MMU 26, 28, 30 may include some control data for controlling access based on realm control provided by the RMU 20, 22, 24 to avoid the need to access two separate structures). In this exemplary embodiment, each of the processing components 8, 10, 12 includes its own realm management unit 20, 22, 24; this is advantageous for performance purposes. However, more generally, the memory access circuitry that implements ownership rights may include a single instance of a domain management unit, a combination of all of the domain management units 20, 22, 24 that are present, or a subset of those domain management units 20, 22, 24 that are present. Thus, the memory access circuitry for implementing ownership rights may be dispersed across the system-on-chip integrated circuit 4 associated with different processing components 8, 10, 12, or collected together in one location or in some other configuration.

[0068] The processing assembly including general purpose processor 8,10 is shown as including corresponding decoding and execution circuit 32,34, and these corresponding decoding and execution circuits decode and execute program instructions.These program instructions include the command (domain management command or RMU command) of the management of the memory area in the different ownership domains of the control memory address space.As an example, the program instruction executed may include the program instruction designated as the domain management unit command, and when encountering these program instructions in the program instruction stream, these program instructions are directed to the associated domain management unit 20,22,24, so that these program instructions can be executed (take action) by the associated domain management unit 20,22,24.The example of the domain management unit command includes the command used to initialize a new domain or invalidate an existing domain, to allocate a memory area to a specific domain, to remove a memory area from a specific domain, to encrypt the output data and other processes so that the output data is protected in the second memory 6, and the data contained in the memory area is output from the first memory 16 to the second memory 6. Further domain management unit commands are provided to import data from the second memory 6 back into the first memory 16 with associated decryption and validation operations performed on the input data.

[0069] In the context of such export and import of data from memory areas, it will be appreciated that a first memory such as the on-chip memory 16 is closely managed by a domain management unit 20, 22, 24 within the system-on-chip integrated circuit 4, and that these domain management units 20, 22, 24 are therefore able to enforce ownership rights and restrict access to data within a given memory area to the process that owns the memory area, or to those processes to which the owning process has granted access. However, when the data within the memory area is exported, for example to an external non-volatile memory 6 as a second memory, the control of access provided by the domain management unit 20, 22, 24 is no longer effective and therefore the data needs to be protected in some other way. This is achieved by encrypting the data within the memory area before the data is exported, and then decrypting it with a private key when the data is imported back into the on-chip memory 16.

[0070] The output process may be accompanied by the generation of metadata that specifies the characteristics of the output data. This metadata may be stored separately in a metadata memory area of ​​the first memory (the on-chip memory 16), wherein the metadata remains private to the domain management units 20, 22, 24 (i.e., accessible only to such domain management units 20, 22, 24 and inaccessible to any of the existing processes), so that when data is input back into the on-chip memory 16, the metadata may be read for the input data and the characteristics of the data represented in the metadata and the characteristics of the input data may be checked to ensure the integrity of the input data (e.g., checksum, data size, signature, etc.). It may be the case that the private data of the domain management units 20, 22, 24 (including the above metadata representing the output area / page) needs to be output from the on-chip memory 16 to the off-chip non-volatile memory 6 (for example to make room within the on-chip memory 16), and in this case, the RMU-private metadata itself may be encrypted for protection of the RMU-private metadata and new metadata representing the output metadata may be maintained within the on-chip memory 16 (this maintained metadata is significantly smaller in size than the output metadata) so that the encrypted and output metadata can be checked and confirmed when it is input back into the on-chip memory 16 for use.

[0071] This metadata describing the characteristics of the memory area and the data stored in the memory area can be arranged as part of a hierarchical structure, such as a metadata memory area tree having a branching pattern. The form of this metadata memory area tree can be determined under software control, because different areas of the memory address space are registered as metadata areas owned by the domain management unit 20, 22, 24. It will be appreciated that although the software controlling the registration of such memory areas is able to allocate, de-allocate and control the relationship between memory areas used to store metadata, this software itself does not own the data contained within these memory areas in the sense of being able to control which processes can access this data. In the case of memory areas that are private to the domain management unit 20, 22, 24 (i.e., the memory management circuit), such access rights may be limited only to the domain management unit 20, 22, 24 itself and this RMU-private data will not be shared with any other process.

[0072] When the given data stored in a given memory area is output, the memory area under consideration is then invalidated so that the content is inaccessible. To reuse this page, the page is made "valid" by using a clean command, which overwrites the memory area with other data unrelated to the previous content, so that when the given memory area is released for use by another process, this previous content is not made accessible to another process. For example, the content of a given memory area can be all written as zero values, or as fixed values, or as random values, to overwrite the original content of the memory area. In other examples, the overwriting of the content of the output memory area can be triggered by the output command itself rather than subsequent cleaning commands. In a word, before making a given memory area accessible to a process other than a given owning process, the given owned data outputted can be overwritten by a value unrelated to the given owned data. When a given memory region owned by a given process is to be exported, as part of the export process, the domain management unit 20, 22, 24 executing the domain command to perform the export takes ownership of the memory region in question from the given process (even if the region is RMU-private), locks access to the memory region with respect to all other processes (and other domain management units), performs the export operation (including encryption, metadata generation, and overwriting), and then unlocks access to the memory region and releases ownership of the memory region. Thus, the memory region in the process being exported, being imported can remain private to the domain management unit in question while the command is being executed.

[0073] Figure 2The relationship between multiple processes (programs / threads), multiple exception levels (privilege levels), secure and non-secure processor domains, and multiple domains representing ownership of a given memory region is schematically shown. As shown, the hierarchy of privilege levels extends from exception level EL0 to exception level EL3 (where exception level EL3 has the highest privilege level). The operating state of the system can be divided between a secure operating state and a non-secure operating state, the secure operating state and the non-secure operating state as determined by the use of The architecture is represented by the secure domain and non-secure domain in the processor, for example. Architecture by Limited (Cambridge, UK).

[0074] like Figure 2 As shown, memory access circuitry (domain management units 20, 22, 24 and associated control software (e.g., millicode running a domain management unit)) manages multiple domains within an execution environment. A given memory area (memory page) is owned by a particular domain. A domain may have child domains within the domain, and grandchild domains within these child domains (e.g., see domain A (parent), domain B (child), and domain C (grandchild)). Ownership of memory areas given to domain A may allow ownership of these memory areas to be subsequently transferred from domain A to domain B under the control of a process owned by domain A. Thus, an ancestor domain is able to give ownership of an area to its own child domains of the ancestor domain. These child domains may then transfer ownership of the memory areas they receive from their ancestor domains to be subsequently owned by their own child domains (e.g., domain C), which are grandchild domains of the original domain (i.e., domain A). Processes within a given domain may be executed at the same privilege level or at different privilege levels. The domain to which a procedure belongs is therefore an orthogonal parameter relative to the privilege level of the procedure, but in many practical situations domains and privilege levels may correspond, since convenient mechanisms for moving between domains may involve the use of exceptions that themselves move the system between different privilege levels (exception levels).

[0075] Figure 2The relationship between the domains shown in shows the child / parent relationship between the different domains, and this can be used to create a control hierarchy for controlling the operation of the system when multiple different command sources for memory region management compete with each other. Thus, for example, in the case of an output command for outputting a memory region as discussed above, a first output command may be received by a given domain management unit (memory access circuit) from a first output command source, such as the operating system core 36 inside domain B. A second output command may then be received by a given domain management unit from a second command source, such as the manager program 38 executing in domain A. In this example, the manager program 38, as the second output command source, has a higher priority within the control hierarchy established by the relationship between the parent domain and the child domain, such that the second output command issued by the manager program 38 interrupts the processing of the first output command issued by the operating system core 36. When the second output command as issued by the manager 38 has completed, the first output command as issued by the operating system core 36 can be resumed.

[0076] In this example, the second output command has a higher priority and therefore interrupts the operation of the first output command. However, if the second output command had originated, for example, from an application 40 within domain C, this would have a lower priority position within the control hierarchy established by the relationship between the domains, and therefore the second output command from the application 40 would not interrupt the operation of the first output command from the operating system core 36, and would itself be blocked from execution until the first output command had completed. Thus, paging operations (both output and input operations) may be protected from each other in the sense that these paging operations may or may not interrupt each other depending on the control hierarchy, which may be associated with the domain hierarchy. In other exemplary embodiments, the control hierarchy may correspond to a privileged level.

[0077] Figure 3 A domain management unit 20 and a general memory management unit 26 are schematically shown, which respectively perform different management operations on multiple memory pages (memory areas) stored in the on-chip memory 16. As shown, the domain management unit 24 uses multiple domain descriptors 42, each of which specifies the properties of the domain. The domain management unit 24 can also maintain a domain zone group table (or ownership table), which includes entries indexed by physical addresses, each entry including information for the corresponding memory area, including an indication of which domain the memory area belongs to, that is, which domain has exclusive authority to control access to control data in the memory area, even if the domain does not control whether the domain itself actually owns the memory area. The domain descriptors and domain zone group table entries can be stored in the memory 16, but can also be cached in the RMU itself. Thus, if Figure 3As shown, different memory regions have different ownership domains as indicated by the domain designations RA, RB, RC, RD, and RE. Some of the memory regions are also owned by the domain management unit 20 (private to the domain management unit) and are marked as RMU-private. Such RMU-private regions can be used to store metadata describing the characteristics of other memory regions, temporarily store memory regions being exported or imported, or for other purposes of the domain management unit 20 itself. RMU-private regions may still be owned by the corresponding owner domain, but may be inaccessible to general read / write access issued by the owner domain (instead an RMU command issued to the RMU 20 may be required to trigger the RMU 20 to make any changes to the RMU-private regions).

[0078] The addressing of the memory region may be by virtual address, intermediate physical address, or physical address, depending on the particular system under consideration. The domain management unit 20, and the general memory management unit 26, may therefore store translation data that enables received addresses (whether these received addresses are virtual memory addresses or intermediate memory addresses) to be translated into addresses that more directly represent the memory region within the on-chip memory 16 under consideration, such as physical addresses. This address translation data may be managed and distributed within the system-on-chip integrated circuit 4 using translation lookaside buffers and other distributed control mechanisms.

[0079] Figure 4 Program instructions associated with output operations of memory areas are schematically shown. These program instructions appear in a program instruction stream and may be executed (taken action) by different components within the overall circuit. For example, domain management unit commands are executed by corresponding domain management units 12, 22, 24. Instructions (e.g., virtual address demapping instructions (VUMAP)) and translation lookaside buffer invalidation instructions (TLBI) are broadcast within the on-chip system integrated circuit 4 and are used to clear the use of translation data as specified by these commands as a whole from locations within the system (but in some instances, dedicated virtual address demapping instructions may not be provided, and instead demapping of virtual addresses may be performed by modifying translation table entries rather than using special demapping instructions, the modification being performed by performing a store to memory). Barrier instruction DSB insertion Figure 4and is used to suspend processing of the sequence until confirmation has been received that the previous virtual address demap instruction (or equivalent storage instruction) and translation lookaside buffer invalidation instruction have been completed by all parts of the system. Thus, clearing of virtual address translations for a given memory region within the system other than in the domain management system itself can be achieved by a sequence of virtual address demap instructions (or equivalent storage instructions), translation lookaside buffer invalidation instructions, and corresponding barrier instructions. By demapping (and thereby effectively removing) the virtual address translation data for a given memory region (page), it can be ensured that when an output operation of data stored in that memory region is to be performed, this memory region will not be in use elsewhere within the system.

[0080] Once the barrier instruction DSB has received confirmation that the clearing of virtual address translation data from within the system has been completed, the output command for the domain management unit is executed by the domain management unit. The execution of such an output instruction received from a given process by the domain management unit triggers the performance of a command sequence (corresponding to the millicode embedded in the domain management unit) comprising a plurality of command actions with respect to a given memory region specified. These command targets may include, for example, Figure 4 The following steps are illustrated in FIG: collecting address translation data, locking a memory region, encrypting the data, storing the data externally, writing metadata associated with the memory region, and then unlocking the memory region.

[0081] The address translation collection step performed by the domain management unit as part of the command sequence collects the access control data required to complete the access operation under consideration to the domain management unit. This ensures that once an output operation is in progress, there is a reduced likelihood that the output operation will be suspended, for example, due to the non-availability of parameters or data required to complete the output operation, such as address translation data, attribute data or other data required by the output process. As an example of restoring and storing access control data into the memory access circuit (domain management unit), the address translation step is used to extract all required address translation data (such as virtual to intermediate physical address (or physical address) mapping data) that may be required to complete the output operation.

[0082] Once the address translation data has been extracted, the domain management unit is used to set the lock flag associated with the considered region to a locked state. This lock flag may be stored in the region attribute data 42 for the considered region. Alternatively, the lock flag may be stored in a memory region private to the domain management unit that is performing the output operation, so that the lock flag cannot be overwritten by any other process or domain management unit. To set the lock flag to a locked state, the domain management unit must determine that no other domain management unit is currently keeping the considered memory region in a locked state itself. Thus, a poll of the lock flag value of any region control data stored elsewhere is performed, and if a result indicating that the region is not locked elsewhere is returned, the lock flag is set to a locked state. If the region is locked elsewhere, the output operation fails and an error is reported to the process that guides the output operation. Once the lock has been obtained, the data in the given memory region is encrypted and stored outside the system-on-chip integrated circuit, such as stored in an external non-volatile memory 6. As previously discussed, metadata characterizing the encrypted data (or the given data before encryption) is subsequently generated and stored in the domain management unit private region so that the metadata can be used to confirm the output data at a later time. Finally, the memory area under consideration is unlocked by the domain management unit executing the output command by switching the lock flag from the locked state to the unlocked state. The use of the lock implemented by the hardware mechanism of the memory access circuit (domain management unit) serves to prevent the progress of any other (second) access command from the further processing component that may be received while the lock flag is in the locked state.

[0083] Figure 5 Flow chart for schematically illustrating page (memory area) output. At step 44, program instructions are executed (VUMAP, TLBI, DSB), which are used to clear the use of pages in other places except regional management units 20, 22, 24 in the system. This can be achieved by invalidating the conversion data pointing to the area to be output and clearing the conversion data. Once this conversion data is cleared, another process or processing component wishes to access the area, and then the other process or processing component will attempt to re-take the conversion data. When attempting to re-take the conversion data, the process or processing component that attempts to reuse the area will fail to obtain the relevant conversion data, because the area under consideration will have been placed in the RMU private state, in which the regional management unit 20, 22, 24 that only attempts to perform page output has the authority to access the data.

[0084] When clear requests have been issued at step 44, processing waits at step 46 until a response is received from these clear requests indicating that the address data has been invalidated elsewhere (except in the domain management unit), at which point it is safe to continue beyond the barrier instruction DSB in the program sequence (the barrier instruction DSB halts processing components 8, 10, 12 until the response has been received). At step 48, the domain management unit output initialization instruction is executed. This output initialization instruction includes a pointer to a memory area established as RMU private, where a command context buffer (CCB) is established to store context data representing the current partial completion status of a command sequence corresponding to the output operation for which the command sequence should be interrupted. In an alternative exemplary embodiment, the domain management unit itself may be responsible for generating a pointer to the command context buffer (CCB). Step 50 determines whether the command context buffer indicated by the pointer in the output command step 48 is empty. If the command context buffer is empty, step 52 sets this to the RMU-private area. If the command context buffer at step 50 is not empty, this indicates that the output initialization command executed at step 48 is attempting to restart the previously interrupted output operation. In this case, processing proceeds to step 54, where the contents of the command context buffer pointed to by the pointer are verified using the relevant metadata stored when the partially completed state data was stored to the CCB. If verified, step 56 is used to use the contents of the command context buffer to restore the partially completed state of the output command, such as any partially encrypted data, pointers to the location within the original data to which encryption has progressed, further attributes of the partially completed command, etc. After the initialization of the output operation indicated by the command at step 48, processing proceeds via the path including step 52 or the path including steps 54 and 56 to reach step 58, where the command for executing the domain management unit output command is reached. When this command is reached, the regional management unit 20, 22, 24 then encrypts a portion of the data in the memory area and stores this in the destination (the destination is also the pointer specified in the RMU output initialization instruction at step 48). Step 60 determines whether an interrupt has been received from a command source having a higher priority than the command source that issued the instructions executed at steps 48 and 58. This higher priority command will be from a source having a higher priority position within the control hierarchy (e.g., domain hierarchy, priority hierarchy, etc.) as previously discussed. If this higher priority interrupt is received, then processing proceeds to step 62 where the output of the instruction is suspended and an error code is returned to the command source that issued the instructions executed at steps 48 and 58. Step 64 is used to save the status of the partial completion of the command to the command context buffer.Step 66 stores the command context buffer metadata to the RMU-private memory area for use in verifying the partially completed state stored in the command context buffer when it is subsequently retrieved. Step 68 is used to mark the memory area of ​​the output command that has undergone partial completion as being in a "partial output" state and indicating the process of performing this partial output. This helps to restart the output at a later time.

[0085] If the determination at step 60 is that there is no interruption, then processing proceeds to step 70 where a determination is made as to whether the output of the memory area has been completed. If the output has not been completed, then processing returns to step 58. If the output has been completed, then processing proceeds to step 72 where the memory area that has been cleared (the stored data of the memory area has been output from the memory area) is overwritten with data that is unrelated to the original stored data (e.g., zeroed, set to some other fixed number, filled with random data, etc.). Processing then terminates.

[0086] In the exemplary embodiments discussed above, the CCB is provided as a separate private memory area specified by, for example, an associated pointer within an initialization instruction. However, in other exemplary embodiments, the CCB may not be provided as a separate memory area, but may be provided as a part of a memory area already used by a command that may be interrupted, such as a destination memory area, in which the result data generated by the command is stored. In the case of an interruptible output command, the output encrypted data is stored in a destination memory area, which is an RMU private memory area when the output is executed. When the CCB is filled with encrypted data, the CCB may, for example, be provided as the end part of this destination area. The integrity of the context data stored in the CCB is ensured by the RMU private destination area during the execution of the output operation.

[0087] In another exemplary embodiment, the CCB may be provided as part of a domain descriptor (RD); in this case, the storage space available for context data may be constrained by the space available in the RD, and thus the number of interruptible parallel commands supported may be constrained by the storage space available in the RD for use as a corresponding CCB. The CCB may be provided separately, or as part of a memory area or resource that is also used for another purpose.

[0088] Figure 6The relationship between domains and the control hierarchy is schematically shown, and the control hierarchy determines which commands from different command sources are allowed to interrupt / block partially completed commands from other sources. The example shown includes three levels of nested domains. The parent domain M corresponds to exception level EL3. The child domain N corresponds to exception level EL2. The two grandchild domains within domain N include domain O and domain P and both are at exception level EL1. In this example, both the exception level priority and relative position within the nested hierarchy of domains give an order in the control hierarchy, where domain M has a higher priority than domain N, and domain N has a higher priority than domain O and domain P. Domain O and domain P have equal priority.

[0089] Figure 7 Flowchart for schematically illustrating a page (memory area) input operation following an RMU input command. Step 74 is used to obtain and clean an empty page (memory area) into which data can be input. Step 76 then uses the associated storage metadata of the encrypted data (stored in the RMU-private area) to verify the encrypted data to be input. If this verification is unsuccessful, an error is generated. After successful verification, step 78 is used to decrypt the encrypted data and step 80 is used to store the decrypted data in the memory page obtained at step 74. Once the memory page has been filled with decrypted data, the memory page can be released to the owning domain (process). The page that is obtained and then filled is locked so that it can be used exclusively by the memory management circuit (domain management unit 20, 22, 24) during the page input process.

[0090] Figure 8 Two output commands are schematically shown that may occur in parallel from different command sources. One of the instruction sequences originates from a process corresponding to a virtual machine (e.g., a guest operating system). The other command source is a manager at a higher privilege level (or possibly higher level within the domain hierarchy) than the virtual machine. Thus, an output command from the manager can interrupt a partially completed output command on behalf of the virtual machine being executed by the domain management unit 20, 22, 24. When the output on behalf of the manager is completed, the output on behalf of the virtual machine can then be resumed.

[0091] In this example, the command to the domain management unit 20, 22, 24 may be a combined initialization and execution command that is repeatedly executed until the memory access circuit reports that the command sequence corresponding to the output operation has been completed. In the previously discussed example, the output command may be formed by an output initialization command that specifies a pointer to a command context buffer and other pointers followed by a subsequent output execution command that is repeatedly executed until the memory access circuit reports that the command sequence has been completed. In other exemplary embodiments, the output operation may be controlled by a combined initialization and execution instruction that is interruptible and an execution continue command issued in the event that the combined initialization and execution command is interrupted.

[0092] The command context buffer is used to store a partially completed state representing a partially completed command sequence so that this data can be restored at a later time. In this way, the system does not need to wait until the complete output operation has completed before the interrupt can be serviced. In addition, when the partially completed state is maintained, even if the output operation is repeatedly interrupted, forward progress through the output operation is ensured because the output operation will not need to be restarted from the initial point of the output operation.

[0093] Fig. 9 Shows Figure 1 A more detailed example of one of the processing components 8, 10, 12 and the control data stored in the memory 16 for controlling memory access. For ease of explanation, Fig. 9 CPU 0 is shown as processing component 8, but it will be appreciated that the processing component may also be CPU 110 of GPU 12 or any other processing component within data processing device 2. Fig. 9 As shown in FIG. 1 , the processing component 8 includes a processing circuit 32 (which may include the decoding and execution logic described above), a memory management unit 26 that may include one or more translation lookaside buffers 100 for caching entries of a translation table (if a shared MMU-RMU TLB structure is used, the one or more translation lookaside buffers may also be supplemented with field-based control data from the RMU 20), and a table traversal unit 102 for controlling the allocation of data to the TLB 100 and triggering a traversal access to the memory to locate the required data used to control whether a given memory access is allowed to be executed. The processing component 8 may also include a cryptographic unit 104, which may perform cryptographic operations for encrypting or decrypting data used, for example, in the paging (output / input) operations discussed above. The processing component 8 also includes a plurality of caches 110, which may cache data or instructions read from the memory 16. If an access to the memory triggered by the processing circuit 32 or by the table traversal unit 102 misses in the cache, the data may be located from the main memory 16.

[0094] The processing component 8 also includes a domain management unit 20 as discussed above. In some embodiments, the domain management unit (RMU) 20 may be provided as a hardware circuit. However, some of the RMU operations discussed below may be relatively complex to be implemented simply in hardware, for example if these RMU operations require multiple accesses to different memory areas. Therefore, in some instances, the RMU 20 may be implemented using program code that may be stored in the data processing device 2 and may be executed using a general processing circuit 32. Unlike general software that can be written to the memory 16 and may be rewritable, the RMU software (millicode) may be installed on the data processing device in a relatively permanent manner so that the RMU software is not removable and may be considered as part of the platform provided by the processing system. For example, the RMU program code may be stored in a read-only memory (ROM). Therefore, the RMU may include a hardware unit, or may include a processing circuit 32 that executes the domain management software, which is triggered to execute by RMU commands, which are included in the general software executed by the processing circuit 32. In some examples, RMU 20 may be implemented using a combination of hardware and software, e.g., some simpler functions may be implemented using hardware circuits for faster processing, but more complex functions may be implemented using millicode. Thus, it will be appreciated that subsequent references to the RMU may refer to hardware or software or a combination of both.

[0095] like Fig. 9 As shown in , the memory 16 may store multiple pieces of control information used by the MMU 26 and the RMU 20 to control access to the memory. This includes translation tables (also called page tables) 120, which define memory access attributes for controlling which processes are allowed to access a given memory region, and address mapping information for translating virtual addresses to physical addresses. The translation tables 120 may be based on the information described above with respect to Figure 2 The exception level in question is defined such that a process executing at a more privileged exception level can set permissions that govern whether a process executing at a less privileged exception level is allowed to access a corresponding memory region.

[0096] In addition, a plurality of domain management tables or domain control information 122 are provided for controlling memory access in an orthogonal manner relative to the MMU page table 120 to allow less privileged processes to control whether to access more privileged processes (domain control is orthogonal to MMU control in the sense that a memory access request to be serviced may need to pass two types of access control checks). Using the domain management tables, the owner process (domain) of a given memory region has the right to exclude processes executing at more privileged exception levels from accessing the memory region. The domain management data includes a domain descriptor 124 that describes the properties of a given domain. Each domain corresponds to at least a portion of at least one software process executed by the processing circuit 32. Some domains may correspond to two or more processes, while other domains may correspond to only a sub-portion of a given software process. A domain may also be viewed as being mapped to a given region of a memory address space (wherein the processing circuit 32 is executing within a given domain when the processing circuit is executing program instructions located within a corresponding region of the memory address space). Thus, a domain may be viewed as a collection of software processes or a portion of a software process, or as a region of a memory address space. These two viewpoints are equivalent. For ease of explanation, the subsequent description refers to a domain as at least a portion of at least one software process, but the corresponding view of a domain as a collection of memory areas is equally valid (in which case "entry" and "exit" to / from a domain may correspond to arriving at / leaving the portion of program execution corresponding to the memory address of the domain).

[0097] The domain management data 122 also includes a domain execution context area 126, which can be used to save and restore the architectural state associated with a given domain when the domain is exited or entered. The domain management data also includes a domain zone group table (or ownership table) 128, which defines, for each region of the memory address space, which domain is the owner domain of the memory region. The owner domain of a given memory region has the right to exclude other domains (including more privileged processes) from accessing data stored in the memory region. The use of this domain management data is discussed in more detail below. In general, the domain management unit 20 and the MMU 26 can be viewed as memory access circuits that enforce ownership permissions defined by the owner domain for the memory region owned by the domain. This can be particularly useful, for example, for a cloud platform, in which multiple virtual machines 36 provided by different parties can be executed under the control of a hypervisor 38 provided by a cloud server operator. The party providing one of the virtual machines may not want its data and code to be accessible to the hypervisor. By introducing the concept of a domain where a domain executing at a less privileged exception level can exclude a more privileged exception level from accessing data or instructions of that domain, this enables the provision of a blind hypervisor that can increase the confidence of code developers to install their software on a cloud service where the physical hardware can be shared with code provided by other parties.

[0098] like Fig.10 As shown in , the domains are managed by the RMU 20 according to a domain hierarchy in which each domain except the root domain 130 is a child domain having a corresponding parent domain that initializes the child domain by executing an initialization command. The root domain 130 may be, for example, a domain associated with a monitor code or system firmware executing at the most privileged exception level EL3. For ease of explanation, Fig.10 The example of and the initial example discussed later show the situation that each child domain executes at a lower privilege level than its parent domain. However, as will be discussed below, it is also possible to establish a sub-domain that executes at the same exception level as its parent.

[0099] Generally speaking, for the domain management part of the memory access control provided by MMU 26, the child domain has the default access to any memory area owned by its parent domain. Similarly, it is assumed that any descendant of a given domain can access the memory area owned by a given domain. However, because the domain management control is orthogonal to the control provided by the conversion table 120 based on the exception level, the process executed at a higher privilege level can still exclude less privileged code from accessing its data by setting the parameters of the conversion table 120 accordingly. Therefore, generally speaking, a given child domain has the right to exclude the parent domain of the given child domain from accessing the data stored in the given memory area owned by the given child domain. Whether the child domain actually excludes the parent domain from accessing the given memory area can be set based on the control attribute set in the ownership table 128 (the default situation can be that the parent domain does not have access to the area owned by the child domain, but the child domain can choose to grant access to the parent domain by setting the visibility attribute accordingly). When there are multiple sibling realms (different child realms that share the same parent realm), then a given child realm may exclude a sibling realm from accessing data stored in a given memory region owned by the given child realm. Additionally, visibility attributes set in ownership table 128 may control the extent to which a sibling realm may access data from each other generation realm. Alternatively, access to sibling realms may be controlled based on a parent visibility attribute, such that if a child realm makes a page visible to its parent realm, the same page also becomes visible to the sibling realms of the child realm and further descendants of the sibling realm. In some cases, ownership table 128 may have a global visibility attribute that may allow a given owner process to enable any process executing under any realm to access data within the memory region owned by the given owner process.

[0100] like Fig.10 As shown in , each domain 140 is associated with one or more domain execution context (REC) memory areas 126, which can be used to store the architectural state of the domain, such as register values, when exiting from a given domain. The number of RECs 126 provided for a given domain may depend on how many threads of execution are operating under the given domain. For example, a domain may be established using a single main REC area 126 when initially initialized, but the domain may then configure other memory areas owned by the domain to be used as further RECs when necessary. REC memory areas are owned by the corresponding domain whose execution state is stored in the REC.

[0101] Each domain is associated with a domain descriptor 124, which is stored in a memory area owned by an ancestor domain of the domain whose properties are described in the domain descriptor 124. In order to be flexible in the number of child domains that can be defined at a given domain generation, a tree structure called a domain descriptor tree (RDT) is used to manage domain descriptors, which will be discussed in more detail later. The domain descriptor 124 can be used to define the properties of the domain, which can be checked by the RMU 20 when entering or exiting the domain to ensure safety. The domain descriptor can also track the progress of the domain through various life cycle states, so that the execution of certain RMU commands for the domain can be limited to specific life cycle states to ensure that the domain is created and invalidated in a safe manner.

[0102] Fig.11 and Fig.12 shows two different examples of possible domain hierarchies. Fig.11 In the example, Figure 2 Each defines its own domain in the process shown in . Thus, the root domain 130 corresponds to the monitor software or firmware operating at the exception level EL3. The root domain defines two child domains 142, one corresponding to the secure operating system operating at the secure EL1 and the other corresponding to the manager at EL2. The manager defines a grandchild domain 144 corresponding to different guest operating systems at EL1, and each of these guest operating systems defines a further great-grandchild domain 146 corresponding to an application executed at the least privileged exception level EL0. Similarly, the secure operating system in domain 142 may define a grandchild domain 148 corresponding to different secure applications. The parent domain in the hierarchy may transfer ownership of the memory page it currently owns to the new child domain (by using a Granule.add command as discussed below), or may invalidate one of the pages of the parent domain, map the page to the virtual address space of the child, and allow the child domain to claim ownership of the page by executing a page ownership (claim) command. A page ownership command may be rejected if the specified page of the memory address space is not already owned by the ancestor domain issuing the command.

[0103] like Fig.12 As shown in , it is not necessary for processes at each privilege level to have separate domains, and thus in Fig.12 Some of the privilege level boundaries shown in the dashed lines in FIG. 1 may not correspond to domain boundaries. Fig.12, an application 150 and its operating system execute in the same domain as the manager domain 142 operating at exception level EL2, and thus a single domain spans the EL2 manager code, the operating system operating at EL1, and the application at EL0. On the other hand, a different application 152 under the same manager may define its own separate domain. In this case, the domain boundary is between EL1 and EL0 and there is no EL2-EL1 domain boundary (both the manager and the operating system may execute in the same domain). For another operating system, a separate EL1 domain 154 may be defined, which may also have some applications executing in the same domain as the operating system, and other applications having their own dedicated domain. Similarly, on the security side, Fig.12 The secure OS and applications in EL3 execute entirely within the EL3 root realm, and therefore there are no realm boundaries when operating on the secure side. Therefore, the exact configuration of realms can be determined at run time on a given system, depending on the needs of the processes being executed. Software can determine at run time whether it only requires a small and fixed number of child realms (which may be the case for low-level firmware), or requires many realms or a varying number of realms (for example, this may be used for a hypervisor on a cloud platform that may manage an unknown number of guest virtual machines).

[0104] The domain descriptors 124 for a given ancestor domain are managed according to a domain descriptor tree (which is an instance of a domain management tree that defines domain management data for a plurality of child domains of the ancestor domain). The tree has a variable number of levels. Fig.13 An example of a domain descriptor tree 160 managed by a particular parent domain is shown. The tree 160 includes a plurality of domain descriptor tree blocks (RDTGs) 162, each of which includes a plurality of domain descriptor tree entries (RDTEs) 164. Each RDTE 164 provides a pointer to a domain descriptor 166 for a given child domain of the parent domain, or to a further RDTG 162 for the next level of the domain descriptor tree. The RDTG 162 for the first level of the tree can be identified by a domain descriptor tree pointer 168, which can be stored as part of the data associated with the parent domain (e.g., the domain descriptor of the parent domain). Therefore, when the parent domain issues an RMU command associated with a given child domain, the parent domain can trigger the RMU to traverse the domain descriptor tree in order to locate the domain descriptor 166 of the required child domain (if the domain descriptor has not yet been cached in the RMU 20). Each RDTG 162 can have a variable number of entries 164.

[0105] like Fig.13As shown in the table in , a given RDTE 164 that provides a pointer to an RDTG 162 at a subsequent level of the tree may include an order value indicating the maximum number of entries in the pointed RDTG. For example, the order value may indicate a power of 2 corresponding to the total number of entries in the pointed RDTG. Other information that may be included in the RDTE 164 may include a state value that indicates the state of the RDTE (e.g., whether the RDTE is free for allocation of domain descriptor tree data, and whether the RDTE provides a pointer to a further RDTG 162 or to a child domain descriptor 166). In addition to the pointer, the RDTE may also include a reference count that tracks the number of non-free RDTEs in the pointer to the RDTG, which RDTEs can be used to determine whether further RDTEs can be assigned to the RDTG 162. RMU commands triggered by the previous domain can control the RMU 20 to establish further RDTGs of the tree and / or edit the contents of the RDTEs within the existing RDTG.

[0106] It should be noted that Fig.13 The tree shown in shows the child realms of a particular ancestor realm. Each other ancestor realm may have a separate realm descriptor tree that tracks its own child realms for that ancestor realm. The datagrams associated with the tree (including RDTG 162 and child realm descriptors 166) are stored within pages owned by the ancestor realm, and other realms may therefore be excluded from accessing this data. Thus, only the ancestor realm may have visibility of those specific child realms that the ancestor realm is configured with, so that a process executing at a higher privilege level may not have visibility of what realms have been created below any child realms that the process itself has directly created.

[0107] like Fig.13 As shown in , each of the child domains of a given parent domain may have a corresponding domain identifier (RID) 168 that is used by the parent domain to identify the particular child domain. A RID is a local domain identifier because the RID is specific to a particular parent domain. Child domains of different parent domains may have the same local RID. Although it is possible to use a local RID with an arbitrary value selected by the parent domain for a given child domain, Fig.13 and Fig.14 In the method shown in , the local RID for a given child realm has a variable number of variable length bit portions and each of the variable length portions is used by the RMU 20 to index into a given level of the realm descriptor tree 160. For example, Fig.13The domain descriptor of the child domain with local RID = 7 in is accessed by the domain descriptor pointer in entry 7 of the following first level RDTG 162. The domain descriptor of the child domain with local RID = 3.3 is accessed by entry 3 in the following first level of the tree and entry 3 in the following second level of the tree. Similarly, the domain descriptor of the child domain with local RID = 1.2 is accessed by entry 1 in the following first level and entry 2 in the following second level.

[0108] exist Fig.13 In the , the local RID is shown in decimal form, but Fig.14 170 and each of these bit portions may specify an index to be used at a corresponding level of the RDT. In this example, the binary local RID is filled upward from the least significant end first, so that the lowest 5 bits correspond to entries in the first level of the tree, the next 4 bits correspond to entries in the second level, and so on. In this example, the complete local RID corresponds to 7.1.3, because the least significant portion provides a value of 7, the next least significant bit portion provides a value of 1, and so on.

[0109] The number of bits to be used in each of the variable length bit portions 170 may be determined by the order value in the RDTE traversed when stepping through the domain descriptor tree using the RMU 20. The order value used for the first bit portion of the local RID may be defined in the domain descriptor of the parent domain (along with the first level RDTG pointer). Fig.14 In the example of , for example, the level values ​​for the 3 levels are 5, 4, and 2, respectively, indicating that the first 5 bits indicate the index for level 1, the next 4 bits indicate the index for level 2, and the next 2 bits indicate the index for level 3 of the RDT. Eventually, an RID end (termination) marker 172 is reached, which has a predetermined pattern indicating that there are no further levels of the tree to traverse, and therefore the next memory area accessed from the pointer in the last level RDTG will provide the realm descriptor for the required child realm. Any unused bits are filled with zeros. Although Fig.14 An example is shown where the RID is filled from the least significant end upwards, but it would also be possible to construct the RID by sequentially concatenating the indices required to step through the tree starting from the most significant end of the binary value.

[0110] This method provides a flexible architecture that allows different numbers of child domains to be established by a given parent domain, and allows domain descriptors for these child domains to be efficiently accessed. Because the domain identifier explicitly provides the index required to step through the domain descriptor tree, there is no need to maintain a mapping table that maps arbitrary domain numbers to special routes through the tree. When using a tree structure, compared to a table structure that will provide a certain fixed number of entries, the tree can be expanded as required by the number of child domains by adding additional RDTGs or additional RDTEs to a given level of the tree where appropriate. Therefore, the structure is scalable for the needs of different software processes. Because it is not precisely specified in advance which parts of the RID will be mapped to a given level of the tree, this enables the available bits of the RID to be flexibly allocated to accommodate the different depths / widths of the tree.

[0111] The domain management unit 20 may be responsible for accessing the domain descriptor tree when needed, such as when entering or exiting a domain in order to identify the nature of a new domain and determine whether entry into the new domain is permitted, or when determining whether execution of certain RMU commands is appropriate. In general, the domain management circuitry may index the domain descriptor tree using a domain identifier for a given domain, the domain identifier comprising a variable number of variable-length bit portions, wherein a given one of the variable-length bit portions provides an index into a given level of the domain descriptor tree. This enables flexible scalability of the domain descriptor tree in order to support various requirements for different software processes to establish child domains.

[0112] The domain management circuitry 20 may determine how many bits are included by the variable length bit portion for indexing into a given level of the domain descriptor tree based on the order value specified by the entry index at the previous level of the domain descriptor tree. By storing the order value within the entry of the tree, there is no need to predefine which bits of the RID will be used to correspond to a given level of the tree, which provides further flexibility.

[0113] The RMU may allow the variable length bit portion used to index into different branches at the same level of the realm descriptor tree to have different numbers of bits. Fig.13 In the RDTG 162 shown in middle level 2, both have the same order value (and therefore the same number of entries), but this is not necessary, and some embodiments may have different RDTGs 162 at the same level of the tree, with different numbers of entries. Therefore, corresponding portions of the RIDs of corresponding domains may have different numbers of bits for the same level of the tree. Therefore, the length of the bit portion used to index into a given length of the tree may vary not only from one generation to another, but may also vary within different branches of the tree managed by one generation, thereby providing further flexibility in the way that child domains may be defined.

[0114] In general, the RID for a given domain may include a concatenation of indexes to be used at the corresponding level of the domain descriptor tree to access the domain management data for the given domain. Although it is not necessary that the indexes are concatenated in the same sequential sequence as they are used to step through the tree, this may be preferred because it makes the management of tree access simpler. It does not matter whether the concatenation is from low to high or from high to low. The concatenation of the indexes may be followed by a predetermined termination pattern that allows the RMU 20 to determine when there are no further levels of the tree to be stepped through.

[0115] Some embodiments may apply this RID construction technique to a global domain descriptor tree, which can store domain descriptors for all domains in the system in a similar tree structure (where each of the RIDs is a globally unique value). However, software development can be made simpler by defining a given parent domain in a tree and then using a separate tree for each other parent domain to track the child domain of the parent domain. Therefore, the domain descriptor tree can be a local domain descriptor tree associated with a given parent domain for storing domain management data for child domains initialized by a given parent domain. The domain identifier can therefore be a local domain identifier that identifies a specific child domain used by a given parent domain. Child domains initialized by different parent domains may be allowed to have the same value of a local domain identifier. In this way, a parent domain can select which RIDs are used for the child domains of the parent domain without knowing what other domains have been established by other parent domains, wherein the RIDs used for the child domains are constructed according to the way in which the parent domain configures its domain descriptor tree.

[0116] Local domain identifiers can be used by domain entry instructions or RMU commands issued by a software process. However, the hardware architecture can use the absolute identification of a given descendant domain to distinguish between domains created by different ancestors. Fig.13 and Fig.14 In addition to the local realm identifiers shown in , a given realm may also have a global realm identifier (or "internal" realm identifier) ​​that is unique to the given realm. At least one hardware structure may use a global realm identifier (GRID) rather than a local realm identifier (LRID) to identify a given realm. For example, realm block table 128 and / or TLB 100 may use a global realm identifier to identify a realm.

[0117] In some examples, an arbitrary binary value may be assigned as the GRID for a given domain, which may be completely independent of the LRID used by the parent domain to reference the child domain. Different microarchitecture implementations of the same domain architecture may use different methods to assign GRIDs.

[0118] However, in Fig.15 In one example shown in , the GRID for a given domain may be constructed based on the LRID of a domain that is a predecessor of the given domain. This may be useful because it may enable a simpler determination that a given domain is a descendant of another domain or a predecessor of another domain, which may be used for access control by MMU 26 and RMU 20. Specifically, domains that share a common predecessor domain may share a common prefix or suffix portion of the GRID. For example, a GRID for a child domain may include a sequential concatenation of the GRID of the parent domain of the child domain and the LRID of the child domain. For example, Fig.15 As shown in , if a given domain 180 has a local domain identifier X, the child domains 182 of the given domain may each have a GRID formed by concatenating X with a specific LRID based on the index in the domain descriptor tree of domain X. For example, a child domain with LRID 1.2 may have GRID X.1.2. Similarly, a grandchild domain of domain X.1.2 with LRID 7 may have GRID X.1.2.7.

[0119] In some cases, LRIDs may be concatenated in a GRID, including Fig.14 , and the bits filled with zeros. Alternatively, the binary representation of the GRID may exclude such termination flags and bits filled with zeros, and instead the meaningful portions of the LRID containing the RDT index may be directly concatenated. Because each of the LRIDs may itself have a variable number of bits depending on the depth and width of the RDT used to associate the previous generation domain, the number of bits of the global RID assigned to the local RID representing a given domain generation may be variable. In addition, this variation in which portion of the global RID is assigned to a given domain generation may vary at runtime based on the particular software being run, but may also vary between different branches of a "family tree" of a domain, such that one branch of the family tree may use a larger portion of the domain identifier than other branches. Because the common prefix or suffix of the GRID is the same for domains sharing a common ancestor, any subsequent generation can still be distinguished by the remainder specific to the subsequent generation, regardless of how that remainder is divided between further generations.

[0120] By constructing the GRID as a sequential concatenation of the LRIDs of multiple predecessor domains, this enables a more efficient determination of whether a first domain is an ancestor or a descendant of a second domain. Circuitry may be provided (e.g., within TLB 100 or RMU 20) to determine whether the global RID of one of the first domain and the second domain matches a prefix or suffix portion of the global RID of the other, such as by using bit masking to mask the portion of the global RID corresponding to the later generation so as to allow a comparison between the global RIDs of an earlier domain and a later domain within the same family to match.

[0121] All local RIDs use Fig.13 It is not necessary to construct the sequence connection of the tree index method shown in . In some cases, it may be useful for a specific value of the local RID to be reserved for reference to certain default domains. The RMU command that specifies the current domain or the domain of the previous generation of the current domain may be relatively common. Therefore, a predetermined RID value may be reserved for reference to the domain of the previous generation of the current domain. For example, an LRID (indicating a value of 1) with all bits set to 1 may be reserved for reference to the domain of the previous generation of the current domain. Similarly, a predetermined domain identifier value may be reserved for reference to the current domain itself. For example, an LRID value of 0 may be used to reference the current domain. It should be noted that the use of the RID termination flag 172 in the LRID helps to support the use of a zero value as a predetermined domain ID value for the current domain, because this means that even if the child domain descriptor is identified using RDTE 0 in each level of the RDT, the resulting RID value is still not equal to zero, because the resulting RID value may include this termination flag 172, which may have at least one bit set to 1. Therefore, in addition to indicating the end of the RID, the termination flag 172 may also support other functions.

[0122] The RMU may support certain query commands that may be triggered by a given domain in order to query the constraints that must be satisfied when the given domain establishes its domain descriptor tree. For example, in response to the query command, the RMU 20 (or processing circuit 32) may return a constraint value indicating at least one of the maximum number of levels of the domain descriptor tree 160 allowed to be defined by the given domain, the maximum number of entries allowed at a given level of the tree structure for the given domain, and / or the maximum number of child domains that can be initialized by the given domain. For example, the system may include registers that may indicate properties such as the number of bits available in the LRID or GRID for a particular hardware implementation. The RMU or processing circuit may, in response to the query command, check the number of bits available for the domain identifier (or an appropriate response may be hardwired for a particular processor implementation), and may also check for information specifying how many bits of the identifier have been used up by the previous domain in the global domain identifier in order to determine how many bits are available remaining for the current domain to define further children. The previous domain may use the response to the query command to determine how to construct the RDT of the previous domain.

[0123] Fig.16 An example of the content of a domain descriptor 166 for a given domain is shown. It will be appreciated that this is only an example and other implementations may not include all of the listed information, or it may include additional information. In this example, the domain descriptor includes the following items:

[0124] The global RID of the realm. Thus, by traversing the realm descriptor tree based on the local RID, the corresponding global RID can be identified and this can be used to index hardware structures such as the TLB by the given realm, or to check ownership tables or other information based on the GRID definition.

[0125] • The lifecycle state of a given realm, which can be used by the RMU 20 to determine whether to accept a given command triggered by the given realm.

[0126] The type of a given domain. For example, the domain type may indicate whether the domain is a full domain or a sub-domain as discussed later.

[0127] A boundary exception level (BEL) value that identifies the boundary exception level for the corresponding domain. BEL indicates the maximum privilege level at which the domain is allowed to execute. For example, Fig.12 In the example, realm 142 may have a BEL at EL2, realm 152 may have a BEL at EL0, and realm 154 may have a BEL at EL1. By providing an explicit parameter identifying the BEL in the realm descriptor, this provides flexibility for realms spanning multiple exception levels, because the BEL can be used when an exception occurs to determine whether the exception can be taken within the current realm or whether a realm exit to a parent realm is required to handle the exception.

[0128] A resource count indicating the total number of memory regions (realm protection group or RPG) owned by a realm and its descendants. This is used to ensure that all memory pages owned by a realm and its descendants are invalidated (and eventually erased of data) before these memory regions can be allocated to a different realm. For example, the resource count can be used to track how many regions still need to be scrubbed.

[0129] The start and end addresses of protected addresses for a realm. For example, a protected address range may define a range of memory address space within which pages may be owned by the corresponding realm. This may be used to protect against a malicious ancestor realm reclaiming ownership of an area previously allocated to a child realm in an attempt to access child realm data, because by comparing the protected address range defined in the realm descriptor to subsequent addresses of memory accesses, it may be identified that a memory area previously owned by a realm is no longer owned by the realm.

[0130] One or more encryption keys used by cryptographic circuitry 104 to encrypt or decrypt data associated with a given realm. In this example, two separate encryption keys are provided: a memory key used to encrypt / decrypt content and memory owned by a realm, and a paging key used to encrypt / decrypt data exported / imported between memory 16 to persistent storage 6 as discussed above. However, in other examples, the same key may be used for both purposes, or further may be provided for other specific purposes.

[0131] • Domain Description Tree Entry (RDTE) which identifies the root of the domain descriptor tree. The RDTE in the domain descriptor provides a pointer for accessing the root RDTG (and an order value defining how many bits will be used as an index to that RDTG).

[0132] - A pointer to the main REC (Domain Execution Context) memory area used to save or restore architectural state related to the execution of the domain.

[0133] Fig.17 The set of lifecycle states that can exist for a given domain is shown, which in this example include a clean state, a new state, an active state, and an invalid state. Fig.17Summarizing the properties of each state, for each state it is indicated whether the realm in the corresponding state can have the parameters of the realm descriptor 166 of the realm modified by the realm's ancestor realm, whether the encryption keys specified for the realm can be used effectively, whether the realm can own any memory areas (RPGs), and whether the code associated with the realm is executable. It should be noted that the parameters of the realm descriptor are modifiable in the clean state, but not in any of the other states. This prevents a malicious ancestor realm from updating the properties of a given realm after it has become active. Additionally, realms are only executable in the active state.

[0134] Fig.18 is a state machine diagram showing the allowed transitions of the life cycle states of a realm. Fig.18 Each state transition shown in is triggered by an ancestor realm issuing a realm management command to the RMU 20 that specifies the local RID of the child target realm (a Realm.Invalidate command 212 may also be issued by the target realm itself). This triggers the configuration of a given memory region owned by the ancestor realm when no previous realm has been defined for that local RID and a Realm Descriptor Register Block Group command 200 is executed by the ancestor realm because the realm descriptor for the child realm has the specified local RID. The global RID for the child realm may be set based on a sequential connection of the global RID of the ancestor realm and the new local RID specified in the realm descriptor register block group command 200. The specified child realm then enters the clean state 202. In the clean state, the ancestor realm may set properties of the child realm by updating various parameters of the domain descriptor of the child realm. These properties may be modified using further RMU commands issued by the ancestor realm (such realm descriptor modification commands may be rejected if the specified child realm is not in the clean state). When the parent domain has finished setting the parameters of the domain descriptor of the child domain, the parent domain executes the domain initialization command 204 that specifies the LRID of the child domain and this triggers the transition of the child domain from the clean state 202 to the new state 206, and at this point, the parameters of the domain descriptor can no longer be modified by the parent domain. If the specified domain is not currently in the clean state, the domain initialization command 204 will fail.

[0135] When a realm is in the new state 206, execution of a realm active command 208 specifying the local RID of the realm triggers a transition from the new state 206 to the active state 210, in which the realm is now executable and after this moment, realm entry into the corresponding realm will no longer trigger a fault. The realm is now fully operational. A subsequent realm invalidate command 212 triggered by an ancestor realm of a child realm in any of the clean state 202, the new state 206, and the active state 210 causes a transition to the invalid state 214. To leave the invalid state 214 and return to the clean state 202, the ancestor realm must execute a realm wash command 216. If the resource count that tracks the number of pages owned by the realm has a value other than zero, the realm wash command 216 is rejected. Therefore, in order for the realm wash command 216 to succeed, the ancestor realm must first issue a Granule.Reclaim command for each page owned by the invalid realm. The block.reclaim command specifies a target memory page and triggers invalidation of the target page to render the page inaccessible and also decrements the reference count of the owner domain of the page by one. When the block.reclaim or domain scrub command 216 is executed, it is not necessary to actually overwrite the data in the invalid region, as the overwrite can be done when a clean command is subsequently issued to transition the memory page from invalid to valid (see the discussion below). Fig. 22 ). In addition, in response to the realm flush command, any cached data associated with the invalid realm may also be invalidated, such as within the TLB 100 or cache 110 of any of the processing components 8, 10, 12 (not just the processing component executing the RMU command). The global RID may be used to trigger such invalidation of cached data.

[0136] Thus, by providing a managed lifecycle of a realm associated with a given realm identifier, this ensures that before a realm can be returned to a clean state in which parameters of the realm can be modified (and therefore before a given realm identifier can be recycled for use by a different realm), data associated with a previous realm using the same realm identifier must be flushed from memory and any caches to prevent any data associated with the old realm from leaking to other realms by reuse of the same realm identifier. While a realm is in the clean state 202, the realm descriptor for that realm may also be revoked by executing a realm descriptor release command 218, which enables the memory area stored in the realm descriptor to be allocated for other purposes (at this point, no flushing is required because the realm is clean).

[0137] Fig.19An example of the contents of an entry of a domain region group table 128 (or ownership table) is shown. Each entry corresponds to a given memory region of the memory address space. The size of a given memory region may be fixed or variable, depending on the implementation. The specific manner in which ownership table 128 is structured may vary significantly depending on implementation requirements, and thus the specific manner in which the corresponding memory region for a given entry is identified may vary (e.g., data may be stored in each entry identifying the corresponding region, or alternatively, the corresponding entry may be identified based at least in part on the location of the corresponding ownership entry within the table itself). In addition, Fig.19 Specific examples of parameters that may be specified for a given memory region are shown, but other examples may provide more information or may omit some of the types of information shown.

[0138] like Fig.19 As shown in , each ownership table entry may specify the following items for the corresponding memory region:

[0139] • Identify the global RID for the owner realm of the memory region. The owner realm may be a realm that has the authority to set attributes that control which other realms are allowed to access the memory region.

[0140] The lifecycle state of the corresponding memory region, which is used to control which RMU commands are allowed to be executed on the memory region.

[0141] The mapped address that is mapped by the MMU 26 when a memory region becomes owned by the owner realm. The mapped address may be a virtual address or an intermediate physical address. By specifying this address in the ownership table, this may prevent possible attempts to exceed the security provided by the realm structure by remapping the address translation table after a realm has taken ownership of a given memory region.

[0142] Visibility attributes that specify which fields other than the owner can access the memory region. For example, Fig. 20As shown in , the visibility attribute may specify the previous visibility bit that controls whether the previous domain of the current domain is allowed to access the region, and the global visibility bit that may specify whether any domain can access the corresponding memory region. In general, the domain protection scheme may assume that the descendant domain of the current domain is always allowed to access the memory region owned by the previous or predecessor domain of the current domain (subject to whether access is allowed based on the conversion table 120, which provides protection based on the privilege level), but a given domain may control whether the previous generation of the given domain or any other domain that is not a direct descendant of the given domain can access the memory region. In some embodiments, both the previous visibility bit and the global visibility bit can be set by the owner domain itself. Alternatively, although the previous visibility bit can be set by the owner domain, the global visibility bit may be able to be set by the previous domain of the owner domain (provided that the previous visibility bit for the memory region has been set to give the previous visibility of the memory region). It will be understood that this is only one example of how the owner domain can control which other processes can access the data of the owner domain.

[0143] Fig.21 is a table showing the different life cycle states in which a given memory region may exist, and Fig. 22 is a state machine showing commands that trigger transitions between corresponding life cycle states. Fig.18 In a similar manner to the domain life cycle states shown in , the transitions between memory region life cycle states are managed to ensure that the memory region that is transferred from the ownership of one domain to the ownership of another domain must first undergo an invalidation process, wherein the data in the region is washed (e.g., set to zero). Therefore, in order to transition from the invalid state 220 to the valid state 222 of the software accessible memory region, the cleaning command 224 must be executed by the RMU 20, triggered by the software executed on the processing component 8. The cleaning command 224 identifies a specific memory region (page) and controls the RMU to step through the memory addresses of the corresponding memory region to invalidate / zero the data in each position in the memory region. If the target memory region is in any state other than invalid, the cleaning command is rejected (e.g., a fault trigger).

[0144] In some systems, it may be sufficient to provide the valid state 222 and the invalid state 220 as the only memory region life cycle states. Fig. 22In the example of , a given memory region may also be designated as an "RMU-private" memory region that is reserved for exclusive access by the RMU 20 itself, such that access to the RMU-private memory region triggered by software executing on the processing circuitry 32 (other than any RMU software) will be denied. This is particularly useful for storing domain management data, such as domain descriptors, domain descriptor tree entries, domain execution contexts, and metadata for paging as discussed above. By providing an attribute for designating a given memory region as an RMU-private memory region that is reserved for exclusive access by the RMU, software processes (including the owner process of the memory region itself) may be prevented from being able to access domain management data, which might otherwise allow the software process to circumvent the security protections provided by the domain scheme.

[0145] Therefore, cleaning command 224 can be used as one of the parameters of this cleaning command to specify privacy indication, and this privacy indication specifies whether this is a normal cleaning command or a private cleaning command. Alternatively, two fully separated commands can be provided for these purposes. When cleaning command was a normal cleaning command, this triggered the conversion to active state 222, as discussed above. However, when cleaning command was a private cleaning command 224, this triggered the conversion to RMU cleaning state 226, wherein the memory area was designated as the RMU-private memory area. In some instances, all types of RMU data can be stored in the RMU-private memory area corresponding to a single type of RMU cleaning state.

[0146] However, robustness can be improved by specifying multiple types of RMU-private memory areas, each corresponding to a specific form of domain management data. Fig.21 and Fig. 22, a plurality of RMU registration states 228 are defined, each corresponding to an RMU private area, which is designated for a specific purpose. In this example, the RMU registration state 228 includes an RMU registration RDT (for storing a domain descriptor tree RDTG), an RMU registration RD (for storing domain descriptors), an RMU registration REC (for storing domain execution context data), and an RMU registration MDT (for storing paging metadata used during output / input operations as discussed above). Different forms of registration commands 230 may be executed by the RMU for a memory area in the RMU clean state to convert the memory area to a corresponding one of the RMU registration states 228. A command for storing data in an RMU-private memory area that does not correspond to a specified purpose (RDT, RD, REC, or MDT) may be rejected. Thus, in a first lifecycle state of the RMU registration state, a first type of RMU command for storing a first type of domain management data may be allowed, and in a second lifecycle state, a second type of RMU command for storing a second type of domain management data may be allowed, wherein the first RMU command is rejected when the target memory area is in the second lifecycle state, and the second RMU command is rejected when the target memory area is in the first lifecycle state. This can achieve further security by avoiding a malicious parent domain, which, for example, attempts to store a domain descriptor entry into a domain execution context area or vice versa in an attempt to split the operation of a child domain. According to each of the RMU registration states 228, a corresponding form of release command 232 may return the corresponding memory area to the invalid state 220. A further clean command may trigger the scrubbing of data from a previously defined RMU-private area before the area can be reallocated for general data.

[0147] Thus, in summary, at least one RMU-private memory region may be defined that is still owned by a given owner domain, but has an attribute specified in the ownership table that means that the at least one RMU-private memory region is reserved for exclusive access by the RMU. In this example, the attribute that controls the RMU-private state is the lifecycle state specified in the corresponding entry in the ownership table, but the attribute may also be identified in other ways. When a given memory region is specified as an RMU private memory region by at least one state attribute, the MMU may prevent access to the given memory region by one or more software processes. Thus, any software-triggered access that is not triggered by the RMU itself may be denied when it targets the RMU-private memory region. This includes preventing access to the RMU-private memory region by the owner domain itself.

[0148] A skilled person might ask why it is useful to define an owner realm for an RMU-private memory region if the owner realm cannot even access the data in the memory region. For example, an alternative approach for implementing access to data by the RMU only would be to define a special realm for the RMU, and allocate pages of the memory address space for storing data that would remain private to that special RMU owner realm. However, the inventors have recognized that when invalidating a realm, there may be a requirement to invalidate all control data associated with that realm, and this can make scrubbing of the invalidated realm's data more complicated if this control data is associated with the special RMU owner realm rather than the invalidated realm.

[0149] In contrast, by using the RMU-private attribute, memory regions storing control data for a given domain remain owned by the domain, even if the owner cannot access the control data, which means that it is simpler to identify which memory regions need to be invalidated when the owner domain is revoked. When invalidating a given domain, the parent domain can simply perform a sequence of reclaim operations (e.g., by executing a reclaim command that is then acted upon by the RMU) that triggers memory regions owned by the specified invalidating domain (or descendants of the specified invalidating domain) to be invalidated and made inaccessible, and ownership returned to the parent domain that triggered the reclaim command. Reclaim operations can affect not only pages accessible to the invalidating domain, but also RMU-private memory regions owned by the invalidating domain.

[0150] Another advantage of storing control data for a domain in an RMU-private memory area owned by the domain is when performing export operations. To reduce the domain's memory footprint to zero, during export operations, management structures associated with the domain can be exported in addition to normal memory. Requiring these structures to be owned by the domain simplifies management of the export operations.

[0151] In general, any kind of domain management data may be stored in the RMU-private area, but specifically, the domain management data may include any of the following: a domain descriptor defining properties of a given domain, a domain descriptor tree entry or further domain descriptor tree entries identifying a memory area in which domain descriptors for the given domain are stored, domain execution context data indicating an architectural state associated with at least one thread executing within the given domain, and temporary working data used at intermediate points of predetermined operations associated with the given domain.

[0152] Although RMU-private areas may generally be used to store domain-specific control data associated with a given domain, these RMU-private areas may also be used to increase security regarding certain other operations performed once a domain is active. For example, when performing the paging-out or paging-in operations discussed above where data is encrypted or decrypted, and a check using metadata is performed to check that the data is still valid when it is input again, such operations may take many cycles and such long-running operations are more likely to be interrupted midway. To avoid the need to restart the operation again, it is desirable to allow metadata or other temporary working data associated with such long-running operations to remain in cache / memory even when interrupted, without making this data accessible to other processes (including the owner domain itself). This temporary working data may be protected by temporarily designating an area of ​​the memory system as an RMU-private area. Thus, if Fig.21 As shown in , the page state may also include RMU output (RMUExporting) and RMU input (RMUImporting) states that can be used when the temporary working data is stored in the memory area, and when one of these states is selected, only the RMU can access the data.

[0153] Other examples of operations that may benefit from temporarily designating corresponding memory regions as RMU-private may include: generation or verification of encrypted or decrypted data during data transfer between at least one memory region owned by a given domain and at least one memory region owned by a domain other than the given domain; transfer of ownership of a memory region to another domain; and destructive reclaim operations performed to render data stored in an invalid memory region inaccessible. For example, a reclaim operation for scrubbing the entire contents of a given page of an address space may be interrupted midway, and thereby ensure that other processes cannot access the page until the scrubbing is complete, and the page may be temporarily designated as RMU-private. In general, any long-latency operation performed by the RMU may benefit from converting the lifecycle state of some memory regions to the RMU-private state before starting the long-running operation, and then converting the lifecycle state back when the long-running operation is complete so that the temporary working data of the long-latency operation is protected.

[0154] When a region is designated as RMU private, the region is reserved for access by the RMU 20, which is used to perform domain management operations. Domain management operations may include at least one of: creating a new domain; updating the properties of an existing domain; invalidating a domain; allocating a memory region for ownership by a given domain; changing the owner domain for a given memory region; changing the state of a given memory region; updating access control information used to control access to a given memory region in response to commands triggered by the owner domain for a given memory region; managing transitions between domains during processing of one or more software processes; managing the transfer of data associated with a given domain between a memory region owned by the given domain and a memory region owned by a different domain than the given domain; and encryption or decryption of data associated with a given domain. The RMU may be a hardware unit used to perform at least a portion of the domain management operations, or may include processing circuitry 32 that executes domain management software to perform at least a portion of the domain management operations, or may be a combination of both.

[0155] Fig. 22 State transitions are shown that may be triggered by a given realm to clean a given page so it can be accessed validly, or to invalidate the corresponding page. Fig.23 This scenario is expanded to illustrate further commands that can be used to transfer ownership of a given page from one domain to another. If the memory region is currently in the invalid state 220 and is owned by an ancestor domain, execution of a region claim command 230 by the ancestor domain enables the corresponding memory region to be transferred to the specified child domain. When the target memory region is owned by any domain other than the ancestor domain of the given child domain, or if the memory region is valid or in one of the RMU-private lifecycle states 226, 228, the region claim command 230 is rejected. This prevents an ancestor domain from arbitrarily assigning ownership of pages that are not accessible to the ancestor domain itself or used by the RMU 20. Once a page has been assigned to a child domain, the child domain may execute a clean command to transfer the page to the specified child domain with the same ownership as the ancestor domain. Fig. 22 222 in the same manner as shown in FIG. 224. For simplicity, the use of the RMU-private area is not shown in FIG. Fig.23 Not shown, but within any given domain, a private clean command may instead transition the memory region to the RMU clean state 226, as previously discussed.

[0156] The block group claim command 230 is used to transfer ownership to an already established child domain. In addition, the parent domain can execute a block group add command 232, which triggers the RMU 20 to assign ownership to the new child domain in a new state, so that the parent domain can write data to the area assigned to the child. For example, this can be used to install program code for the new child domain so that the child domain can be executed for the first time. Therefore, the add command 232 is different from the claim command 230 in terms of the life cycle state of the corresponding memory area assigned to the child domain. Only when the child domain is in Fig.18 , the add command 232 may be allowed. A child realm may release ownership of a given memory region back to the parent realm of the child realm by executing a block release command 234 that triggers the RMU to update the corresponding entry of the ownership table 128 and update properties such as resource counts in the realm descriptor of the child realm. If the specified memory region is not owned by the current realm issuing the command, or if the region is in a state other than invalid, the block release command 234 may be rejected (ensuring that destructive cleaning of the data is required before the data can be returned to the parent realm's ownership).

[0157] One advantage of using the hierarchical domain structure discussed above in which the domain of the parent generation initializes the domain of the child generation is that this greatly simplifies the invalidation of the domain and the descendants of the domain. It is relatively common that if a given virtual machine domain is to be invalidated, it is also desirable to invalidate the domain of any application running under the virtual machine. However, there may be a large amount of program code, data and other control information associated with each of the processes to be invalidated. It may be desirable to ensure that such invalidation occurs atomically so that when only part of the data scrubbing has been achieved, it is impossible to continue to access data associated with the invalid domain. If each domain is established completely independently of other domains without a domain hierarchy as discussed above, this may make such atomic invalidation difficult because multiple separation commands must be provided to individually invalidate each domain identified by the corresponding domain ID.

[0158] In contrast, by providing a domain hierarchy in which the RMU manages domains such that each domain except a root domain is a descendant domain initialized in response to a command triggered by an ancestor domain, when an invalid command requesting a target domain is received, the RMU 20 can use more efficient operations to make the target domain and any descendant domains of the target domain inaccessible to processing circuitry.

[0159] Specifically, in response to the invalidation of the target domain, the RMU may update the domain management data (e.g., domain descriptor) associated with the target domain to indicate that the target domain is invalid, but there is no need to update any domain management data associated with any descendant domain of the target domain. The domain management data associated with the descendant domain may remain unchanged. This is because even if the domain management data has not changed, simply invalidating the target domain may also make any descendant domain inaccessible, because access to a given domain is controlled by the ancestor of the given domain and therefore if the ancestor domain is invalidated, this means that it is not possible to access the descendants of the ancestor domain. Because each of the domains is entered using a domain entry instruction (ERET instruction discussed below), the domain entry instruction uses a local RID defined by the ancestor domain to identify a specific descendant of the ancestor domain, and this is used to step through the domain descriptors stored in the memory area owned by the ancestor domain of the given descendant domain, so no process other than the ancestor domain can trigger the RMU to access the domain management data of the descendant domain. Therefore, if the ancestor domain is invalidated, the RMU cannot access the domain management data of the given descendant domain, thereby ensuring that the given descendant domain becomes inaccessible.

[0160] After a realm has been invalidated, the realm's ancestor realm may trigger the RMU to perform a reclaim operation for reclaiming each memory region owned by the invalidated target realm. Fig.23 As shown in , a reclaim command 236 for a memory region owned by a descendant domain may trigger a return of the memory region to the invalid state 220 and also transfer ownership of the memory region back to the ancestor domain. However, this reclaim operation may be performed in the background of ongoing processing of other domains and need not be performed immediately in order to allow any descendant domains of the invalid domain to be rendered inaccessible. Fig.18 The single action of changing the activity shown in to invalid is sufficient to ensure that all data associated with any descendant domains of the invalidated domain is also inaccessible. Since any ancestor domain can only assign pages owned by the ancestor domain to the ancestor domain's children, and children can only assign pages owned by the children to grandchildren domains, this also means that tracking which pages need to be invalidated and reclaimed upon invalidation of a given domain is relatively straightforward, because of the protected address ranges defined in the domain descriptors of the invalidated domains (see Fig.16 ) can be used to identify which pages are to be reclaimed, since any further descendant realms of the invalid realm will also own pages within that range.

[0161] Therefore, in summary, the use of domain hierarchy greatly simplifies the management of domains and invalidations. When such invalidation and overwriting the data in the memory, invalidation can also trigger the invalidation of cache domain management data for the target domain and any descendant domain of the target domain, which is not only kept in the processing component 8 that triggers the invalidation, but also kept in other processing components such as another CPU or GPU. Therefore, there may be broadcasts of invalidation to other processing components to ensure that other processing components do not continue to have access to the invalid domain. When such invalidation is triggered, it may be useful that the cache domain management data will be associated with the global domain identifier that uniquely identifies the corresponding domain, and form a global domain identifier as discussed above, so that the global RID of a given descendant domain shares a common prefix portion with the global RID of the previous generation domain of the given descendant domain. This enables the use of bit masking or other similar operations to quickly compare whether a given domain is a descendant of a specified domain ID. If the invalidation of a predecessor domain renders a given domain inaccessible, then an attempt to enter the specified target domain is impossible (because there is no predecessor domain to execute the ERET instruction for that domain), but even in other implementations using different domain entry mechanisms, domain entry may fail and trigger a fault condition if the domain descriptor for the descendant domain is no longer locatable.

[0162] Fig.24 An example of a check performed by the MMU 26 and RMU 20 to determine whether a given memory access is allowed is shown. The MMU 26 supports two levels of address translation, level 1 which translates virtual addresses (VA) to intermediate physical addresses (IPA) under the control of the level 1 page table 120-1 set by a given guest operating system, and level 2 address translation which translates the intermediate physical address provided by the level 1 translation into a physical address (PA) used to access memory 16 based on the level 2 page table 120-2 set by the hypervisor 38. The hypervisor may define multiple sets of level 2 page tables for different virtual machines, and a virtual machine ID (VMID) 250 provided with a memory access request may identify which particular level 2 page tables to use. Similarly, an operating system may define multiple sets of level 1 page tables for different applications, and an address space identifier (ASID) 252 may be used to identify which level 1 page tables to use. VMID 250 and ASID 252 may be collectively referred to as a translation context identifier 254, which identifies the current translation context associated with the memory access request. The memory access request also specifies various attributes 256, such as an attribute indicating whether the transaction is a read (R) or write (W) request, or indicating an exception level (X) associated with the process issuing the memory access request.

[0163] Upon receiving a memory access, the MMU 26 may determine whether the transaction attributes are valid based on information from the stage 1 page table. For example, the stage 1 page table may specify that only read transactions may be allowed for certain addresses, or both read and write access may be allowed for a given address (some embodiments may also allow only writes to a region of the address space to be defined). In addition, the attributes in the stage 1 page table may restrict access to processes operating at a given exception level or higher. If the transaction attributes are valid and the access is allowed by the stage 1 page table, the MMU may return the corresponding intermediate physical address (IPA). The IPA is then indexed into the stage 2 page table along with the VMID 250, which again verifies the attributes of the transaction and, if valid, returns the physical address. It should be noted that not all transactions need to go through both stages of address translation. For example, if the input memory transaction is issued at EL3 or EL2, or at EL1 or EL0 in the security domain, the output of the stage 1 MMU may be considered a physical address and the stage 2 MMU may be bypassed.

[0164] After obtaining the physical address, the physical address can then be looked up in the RMU table 128 (realm zone group table) to determine whether the realm protection implemented by the MMU allows the memory access to proceed. Fig.26 The realm check is discussed in more detail in . If the RMU check at stage 3 succeeds, then the verified physical address is output and the memory access is allowed to proceed. If either the check at stage 1 or stage 2 address translation or the RMU-implemented realm protection provided at stage 3 fails, then the memory access is denied. Thus, the protection provided by the realm management unit can be viewed as an additional layer of checks to be performed in addition to any existing address translation checks based on page tables 120. Fig.24 The checks shown in can be performed relatively slowly because there may be multiple tables in memory that need to be accessed and compared to the parameters of the memory access request or the current translation context or realm from which the access is made. Although it will be possible to perform these checks for each memory access, when the checks have been successfully performed for a given memory access request, the data within TLB 100 can be cached more quickly so that the next time a similar memory access request is issued, it can be allowed without repeating all the checks again. Therefore, it may be desirable to perform these permission checks only when there is a miss in TLB 100, and not for a hit.

[0165] Fig.25 An example of a TLB structure 100 for caching data related to authenticated memory accesses is shown. Fig.25A single TLB is shown, but it will be appreciated that some systems may include multiple levels of TLBs in a cache hierarchy, with a level 1 TLB storing a smaller subset of translation entries for faster access, and a level 2 or further level TLB storing a larger set of translation entries that can be accessed in the event of a miss in the level 1 TLB. The TLB 100 (or "translation cache") has a plurality of entries 260, each entry specifying address translation data for a corresponding memory region. Each entry 260 includes a virtual addressing tag 262 that corresponds to a virtual address for which a corresponding physical address 264 is provided for the virtual address. In this example, the TLB is a combined level 1 and level 2 TLB, so that a virtual address can be directly translated to a physical address using the TLB without having to go through an intermediate physical address (although a corresponding level 1 and level 2 translation will be performed on a TLB miss in order to locate the correct physical address, the TLB does not need to store an intervening IPA and can map the VA directly to the OA). Other examples may use split stage 1 (S1) and stage 2 (S2) TLBs, in which case the VA-PA pairs 262, 264 may be replaced with VA-IPA pairs or IPA-PA pairs. The TLB entries 260 are also tagged with a translation context identifier 254 (formed by ASID 252 and VMID 250). Although this example provides two separate translation context identifiers, in other examples a single unified translation context identifier may be used, or in the case of a split S1 / S2 TLB, the S1 TLB may use an ASID and the S2 TLB may use a VMID. The translation context identifiers allow different operating systems or applications that specify the same virtual address to have accesses by those different operating systems or applications mapped to different entries of the TLB 100 that provide different physical addresses.

[0166] A hit in the TLB 100 requires not only that the tag 262 matches the corresponding portion of the address 258 specified for the memory access request, but also that the translation context identifier stored in the same entry should match the current translation context from which the memory access is issued. It is expected that the comparison of the tag 262 and the translation context identifier 254 may be sufficient to locate the correct physical address 264 for a given memory access. However, if these are the only comparisons performed in the lookup, then there is a potential security vulnerability if a memory access hit in the TLB is accepted without further checking of the domainless management unit table 128. This is because it is possible to create a new process that has the same VMID 250 or ASID 252 as a previously executed process to trick the MMU into accepting a memory access that is actually from a different domain than the one previously accepted for accessing a given memory region.

[0167] To address this issue, the TLB 100 may specify within each TLB entry 260 a global RID 270 of the owner realm that owns the corresponding memory region, and a visibility attribute 272 set by the owner realm to control which other realms are allowed to access the corresponding memory region. When a given lookup of the translation cache 100 is performed in response to a memory access to a given target memory region issued from the current translation context and the current realm, if there is a miss in the translation cache 100, the TLB control circuit 280 may trigger the table walk unit 102 to access the associated page table 120 and the RMU table 128 to check whether the access is allowed. If the page table or the RMU table 128 excludes the current combination of the translation context, the exception level, and the realm from accessing the corresponding memory region, no data is allocated to the translation cache in response to the memory access. Specifically, when the lookup misses and the current realm is excluded from accessing the target memory region by the owner realm of the target memory region, subsequent allocation of address translation data to the translation cache is prevented. Thus, when the corresponding memory access passes checks of both the MMU page table 120 and the RMU table 128 , an entry is allocated to the TLB 100 .

[0168] Subsequently, when looking up the translation cache to check whether the translation cache already includes an entry 260 providing an address translation for a given address, the TLB control circuitry 280 determines whether the memory access matches a given entry of the translation cache 100 based on a first comparison between the translation context identifier 254 specified in the corresponding entry 260 and the translation context identifier 254 for the current translation context received in conjunction with the memory access request, and a second comparison between the global RID 270 specified by the entry 260 and the current global RID associated with the current realm issuing the memory access request. By providing an additional check that the TLB entry is still accessed from a realm previously verified as being allowed to access the memory region, this ensures that even if a malicious supervisory process regenerates another process having the same ASID 252 or VMID 250 as a previously existing process allowed to access data by the owner realm, since the global realm identifier 270 is not subjected to the same ASID 252 as the previously existing process allowed to access data by the owner realm, the memory access does not match the given entry of the translation cache 100. Fig.18 In the case of the realm flush command 216 in question, it cannot be reallocated to other processors, so this means that the global RID of the current realm can be trusted to be valid and not "fake", as is possible with an ASID or VMID. Therefore, if the global RID of the current realm still satisfies the permissions indicated by the owner GRID 270 and visibility attributes 272, then this indicates that the realm table check previously performed is still valid.

[0169] If the second comparison of the realm identifiers detects a mismatch, then even if the tag comparison and translation context comparison match, the access request is considered to have missed in the TLB because it indicates that there is a change in the mapping between the translation context ID 254 and the realm ID 270 because an entry was allocated. This does not necessarily imply that the access will be denied because another traversal of the page table and RMU table may be triggered by the table walk unit 102, and if the realm check is successful, this may result in the allocation of a different entry 260 in the TLB 100 and the servicing of the memory access based on the information from the newly allocated entry.

[0170] Fig.26 1 is a flow chart illustrating a method of determining whether a given memory access is allowed by MMU 26. At step 300, a memory access request is received and the memory access request is looked up in TLB 100. The memory access request specifies at least a virtual address to be accessed, one or more translation context identifiers indicating a current translation context, and a global realm identifier identifying a current realm. For example, the global RID may be read from a status register of processing component 8, which may be written with the global RID of the current realm upon entering a realm.

[0171] In response to a memory access request, the TLB control circuit 280 performs a search of these TLBs. The search accesses at least some entries of the TLB. Some methods may use a fully associative cache structure, and in this case, all entries of at least the first level TLB may be searched and compared with the parameters of the current request to identify whether there is a hit or a miss. Other methods may use a set associative cache allocation strategy, and in this case, only a subset of the entries of a given level of the TLB may need to be searched, indexed using the target address of the memory access. For each of the access sets of entries, the TLB control circuit 280 performs these multiple comparisons (in parallel or sequentially), including:

[0172] A tag comparison 302 for comparing whether the address of the memory access request matches the tag 262 stored in the access entry;

[0173] a first (context) comparison 304 of the translation context identifier stored in the access entry with the translation context identifier of the memory access request; and

[0174] • A second (field) comparison 306 comparing the global RID of the memory access request with the owner RID 270 and the visibility attribute 272 for each of the entry's access set.

[0175] At step 308, the control circuit 280 determines whether there is an entry in the TLB that returns a match for all comparisons 302, 304, 306, and if so, a hit is identified, and at step 310, the physical address 264 specified in the matching entry is returned and the memory access is allowed to proceed based on the physical address. In the case of a hit, no lookup of the page table or RMU table needs to be performed (the ownership table lookup for memory access can be omitted). The protection provided by the page table and RMU table is only invoked on a miss.

[0176] If there is no entry matching all three of the comparisons 302, 304, 306, then a miss is detected. If further TLB levels are provided, then corresponding lookup steps 300-308 may be performed in a second or subsequent level TLB. If the lookup misses in the last level TLB, then a traversal of the various page tables and RMU tables is performed. Thus, a level 1 page table traversal is performed at step 311, and a determination is made at step 312 whether a level 1 page table fault has occurred (e.g., because there is no address mapping defined for a specified virtual address or because the current parameters 256 of the access request violate the access permissions specified for the target virtual address). If a level 1 fault has occurred, then at step 314, memory access is denied and allocation of address mapping data to the TLB 100 in response to the memory access is prevented.

[0177] On the other hand, if the access request passes the stage 1 page table check, then at step 315, a stage 2 page table walk is triggered to obtain mapping data for the intermediate physical address returned by the stage 1 process, and at step 316, it is determined whether a stage 2 page table fault has occurred (again, because the address mapping is undefined or because the access is not allowed by the stage 2 access permissions). If a stage 2 fault has occurred, then the access request is again denied at step 314.

[0178] If no stage 2 failure has occurred, then at step 318, an RMU table lookup is triggered based on the physical address returned by stage 2, and at step 320, a determination is made as to whether a domain failure has been detected. A domain failure may be triggered if any of the following events occur:

[0179] If the lifecycle state for the corresponding memory region is indicated as invalid in the domain ownership table 128. This ensures that Fig. 22 The pages of the memory address space of the cleaning operation 224 shown in FIG. 2 are made inaccessible to protect any data previously stored in that memory region by another realm from being accessed by a different realm.

[0180] ·The current realm is not allowed by the owner realm for the corresponding memory region to access the memory region. There may be multiple reasons why a given realm may not be allowed to access a given memory region. If the owner realm has specified that the memory region is visible only to the owner itself and the descendants of that owner, then another realm may not be allowed to access that realm. In addition, if the current realm is an ancestor realm of the owner realm and the owner realm has not defined an ancestor visibility attribute to allow the ancestor to access the region, then memory access may be denied. In addition, if the memory region is currently set to RMU-private as discussed above, then the owner realm itself may be prevented from accessing the memory region. At the RMU check stage, descendant realms of the owner realm may be allowed to access the memory region (as long as the memory region is not an RMU-private region). Therefore, this check enforces the access permissions set by the owner realm.

[0181] If the physical address mapped by S1 / S2 for the current memory access does not match the virtual address or intermediate physical address in Fig.19 , memory access is denied if a mapping address specified in ownership table 128 for the corresponding memory region is not specified. This protects against the following situation: a malicious parent domain may assign ownership of a given memory region to a child domain, but then change the translation mapping in page table 120 so that subsequent memory accesses triggered by the child domain using the same virtual address that the child domain previously used to reference a page owned by the child domain now map to a different physical address that is not actually owned by the child domain itself. By providing a reverse mapping in the ownership table from the physical address of the corresponding memory region back to the mapping address used to generate the physical address when ownership was asserted, this allows security breaches caused by changes in the address mapping to be detected so that memory accesses will fail.

[0182] It will be appreciated that other types of checks may also be performed. If the realm check is successful, then the physical address is returned at step 322, the memory access is allowed to proceed using the physical address, and a new entry is allocated to the TLB indicating the physical address obtained from the page table 120 and the owner realm and visibility attributes obtained from the ownership table 128 corresponding to the requested virtual address and translation context.

[0183] Thus, in summary, by requiring a second comparison (comparing the GRID of the current realm with the GRID provided in the entry of the translation cache) to match in order to allow a hit to be detected in a translation cache lookup, this ensures that even if there is a change in the translation context identifier associated with a given realm after the TLB entry has been allocated, this cannot be used to exceed the realm protection, even if the realm check is not repeated again on a TLB hit. This allows for improved performance, such as by making it unnecessary to repeat the realm check on every memory access (which would be relatively processor intensive given the number of checks that would be performed). This allows most memory accesses to be performed faster, as hits are much more common than misses. When the second comparison identifies a mismatch between the realm identifier specified in the entry and the realm identifier of the current realm, a mismatch between the memory access and the given entry of the translation cache is detected. This will then trigger a miss and this can trigger a page table and RMU table traversal in order to find the correct access control data (where the realm check is repeated in the case where the VMID / ASID has changed).

[0184] This method is safe because the RMU can prevent the initialization of a new domain with the same domain identifier as a previously active domain until after a scrubbing process has been performed to invalidate information related to the previously active domain. This scrubbing process may include not only the invalidation of domain management data and any data stored in memory related to the invalid domain, but also the invalidation of at least one entry of the translation cache for which the second comparison identifies a match between the domain identifier of the entry and the domain identifier of the invalid domain. Therefore, this means that it is impossible to regenerate a different process using the same domain identifier as the previous process unless all data in the translation cache 100 related to the domain has been invalidated. Therefore, matching the domain identifier in the TLB can be trusted to indicate that the previously performed domain check is still valid. Specifically, each domain can be associated with a life cycle state as discussed above and this can be used to emphasize that the scrubbing process is performed. Address translation data can only be allocated to the translation cache when the current life cycle state for the current domain is active. Commands for initializing a new domain with a given domain identifier can be rejected in any state except the clean state, and the transition from the active state to the clean state may require a predetermined command sequence to be executed, which includes at least one command for triggering the scrubbing process.

[0185] A miss in the translation cache may trigger an ownership table lookup that accesses an ownership table that specifies, for each of a plurality of memory regions, an owner realm for the corresponding memory region and access constraints set by the owner realm for controlling which other realms are allowed to access the memory region. By including an additional second comparison for determining a TLB hit, this enables the ownership table lookup to be omitted when the lookup hits. An ownership table lookup is performed on a TLB miss.

[0186] Although Fig.25 An approach is shown in which the GRID of the owner domain is stored in each TLB entry, but there may be other ways of representing information that implements the determination of whether the GRID of the current domain is suitable for accessing the corresponding memory region. For example, a list of the GRIDs of the granted domain may be maintained in the TLB, or the TLB may maintain a separate list of active domains with TLB entries containing indexes into the active domain list, rather than the full GRID, which may reduce the TLB entry size compared to storing the list in the TLB entry. However, simply representing the GRID of the owner domain may be a more efficient way to identify the granted domain because it makes the process of allocating and checking TLB entries less complicated by avoiding an extra level of indirection in consulting the active domain list, and also avoids the need to synchronize changes in the active domain list between TLBs.

[0187] It should be noted that a match in the second (GRID) comparison performed when looking up the TLB does not necessarily require that the current realm identifier be exactly the same as the global realm identifier 270 specified in the two corresponding TLB entries 260 - some forms of the second comparison may use a partial match. Some embodiments may only allow the owner realm to access pages owned by the owner realm, and so in this case an exact match between the current GRID and the owner GRID 270 may be required. However, because it may be useful that data is to be shared between realms, a visibility attribute 272 may also be provided to allow the owner realm to define what access is allowed by other realms.

[0188] Therefore, by caching the visibility attribute 272 in the TLB 100 and the owner domain global RID 270, this enables the TLB control circuit 280 to change the degree of match required for the second comparison to determine a match based on the visibility attribute. For example, the visibility attribute 272 can control which parts of the GRID should be masked when comparing, so that it does not matter if these masked bits do not match because these masked bits do not affect the overall match of the comparison. For example, when the current domain indicates a domain other than the owner domain or a descendant domain of the owner domain, the control circuit may determine a mismatch in some cases. The descendant domains can be easily identified using the global RID format discussed above because these descendant domains will have a prefix or suffix portion of the GRID that matches the owner domain.

[0189] For at least one value of the visibility attribute, the control circuitry may determine a mismatch when the current domain is a domain other than the owner's domain, a domain that is a descendant of the owner's domain, or a domain that is an ancestor of the owner's domain (e.g., when ancestor visibility is set as discussed above). In some cases, at least one value of the visibility attribute may allow the control circuitry 280 to determine a match for the second comparison regardless of which domain is the current domain (e.g., if the global visibility bit is set). Thus, while in general the second comparison based on the domain identifier need not pass, exactly what requirement will be satisfied by the GRID of the current domain may depend on the visibility bit 272. This enables such partial matches to be performed efficiently by constructing the domain identifier of the child domain to include a bit portion of the domain identifier of the ancestor domain that initialized the child domain. In embodiments that support variable assignment of different variable-length bit portions of the global domain identifier to different generations of domains, the TLB entry 260 may also specify some information identifying the location of the boundary between different local RIDs that are concatenated to form the GRID (so as to allow the ancestor domain to be distinguished from the grandparent or earlier generation domain). This may enable TLB control circuitry 280 to determine which parts of the realm identifier are to be masked. For other embodiments, this may not be necessary (e.g. if any predecessor is allowed to access a memory region for which the owner realm has given visibility to its ancestor realm). Additionally, some embodiments may have a fixed mapping where each global realm identifier has a fixed number of bits (such as 32-bits), and in this case it may not be necessary to provide any additional boundary definition data.

[0190] Fig. 27 is a Venn diagram showing examples of architectural states accessible to processing component 8 at different exception levels. Fig. 27 Shown based on Limited (Cambridge, UK) architecture, but other embodiments may be based on other architectures that may have different states associated with a given process. Fig. 27 Only a subset of the states accessible at each exception level are shown for simplicity as an example, but it will be appreciated that other registers may also be accessible, which are Fig. 27 Not shown.

[0191] When operating at exception level EL0, processing component 8 may access a subset of the architectural state referenced as 350, including, for example, the following:

[0192] General purpose registers, including integer registers, floating point registers, and / or vector registers, used to store general data values ​​during data processing operations.

[0193] - A Program Counter (PC) register, which stores the address of a program instruction representing the current execution point within the program being executed.

[0194] Save Processor State Register (SPSR_EL0) for storing information about the current state of the processor when an exception is taken from a procedure executing at exception level EL0. The SPSR may include information about the current processor state, such as a value PSTATE indicating the current processor mode when the exception occurred. The processor mode may specify the exception level as well as other information, such as which instruction set is being executed. In addition, the SPSR register may include a domain entry flag R used to control domain entry, as discussed below.

[0195] Exception link register ELR_EL0, used to store the current program counter value when an exception is taken, so that the ELR provides the return address to which processing should branch once the exception has been handled.

[0196] A realm identifier register RID_EL0, which is used to store the local RID of the child realm for which the realm entry is made (even though exception level EL0 is the lowest, least privileged exception level, a realm may still be entered from a process operating at exception level EL0, utilizing the ability to create sub-realms as discussed below).

[0197] - Exception Status Register (ESR), which is used by ELO to store information about exceptions that have occurred (eg, to allow selection of an appropriate exception handler).

[0198] When processor 8 is operating at exception level EL1, it can access a subset of states 352 that includes all of the states 350 accessible at exception level EL0, but also includes additional architectural states. For example, at EL1, there are grouped versions of the SPSR, ELR, ESR, and RID registers that are used by processes operating at EL1 for purposes corresponding to the EL0 versions of these registers. The SPSR_EL1 register may include, in addition to the PSTATE and R values, an intermediate realm flag Int that is used during nested realm entry and exit, as will be discussed below. Although Fig. 27 An example is shown where the mid-realm flag is stored in the SPSR, but this is not necessary and other examples may store the flag in a different register. Another example of a state that may be accessible at EL1 but not accessible at EL0 may be the translation table base register TTBR_EL1, which provides an address indicating the base address of the stage 1 page table 120-1 used by the MMU during a page table walk.

[0199] Similarly, when executing instructions at exception level EL2, processing component 8 can access a state subset 354 that includes all of the states 352 accessible at EL1, but also includes additional states, such as further grouped versions of the SPSR, ELR, and RID registers for EL2 and a virtual translation table base register VTTBR_EL2 that provides the base address of the stage 2 translation table 120-2.

[0200] Finally, when operating at EL3, the processing component can access a state subset 356 which includes all of the subset 354 accessible at EL2, but may also include other states, such as a further realm identifier register RID_EL3 used by a process operating at exception level EL3 to enter a realm, and further exception handling registers ELR, SPSR, ESR similar to corresponding registers for lower exception levels. In addition, Fig. 27 These are examples only and other states may also be included in the associated subset accessible to a particular exception level.

[0201] Thus, each exception level is associated with a corresponding group of registers that are accessible to the processing circuitry when processing a software process at that exception level. For a given exception level other than the least privileged exception level, the group of registers accessible at the given exception level includes the group of registers accessible at the less privileged exception level than the given exception level. The state hierarchy accessible at a particular level can be utilized to reduce the management burden associated with state preservation and restoration at domain entry and exit, as will be discussed below.

[0202] When entering or exiting a domain, the processing component 8 and / or RMU 20 may need to perform multiple operations for ensuring safe handling of domain entry or exit. For example, when entering a domain, multiple checks may need to be performed to check that the target domain is in the correct life cycle state (to avoid exceeding the safety measures by attempting to enter a non-existent domain or, for example, a domain that has not yet undergone a scrubbing of data from its owned pages). In addition, when exiting a domain, it may be desirable to mask the architectural state stored in the registers of the processing component so that higher privilege level processes cannot access state data used by domains at lower privilege levels (which would otherwise cause the safety measures provided by the domain protection to be exceeded). One method for handling domain entry and exit may provide a dedicated domain entry or domain exit instruction that triggers the RMU 20 to perform the associated operations for entering or exiting the domain. However, this may require significant modification of existing software in order to use the new instructions.

[0203] In the techniques described below, the realm mechanism reuses the mechanism already provided for exception entry and return to enter and exit from the realm. This reduces the amount of software modification required to support realm entry and exit, and simplifies the architecture and hardware. This is particularly useful because typically realm boundaries may correspond to exception level boundaries anyway, and even if new instructions are provided to control entry and exit, behavior for handling exceptions will still be required, so overall, extending the exception mechanism to also control entry and exit may be less expensive.

[0204] Thus, an exception return (ERET) instruction that would normally cause processing to return from an exception handled in the current domain to another process also being handled in the current domain (where the other process may be handled at the same exception level or a less privileged exception level than the exception) may be reused to trigger a domain entry from the current domain to a destination domain. In response to a first variant of the exception return instruction, the processing circuitry may switch processing from the current exception level to a less privileged exception level (without changing domains), while in response to a second variant of the exception return instruction, the processing circuitry may switch processing from the current domain to a destination domain, which may operate at the same exception level or a reduced (less privileged) exception level as the current domain. Using an exception return instruction to trigger a domain entry may greatly simplify the architecture and hardware management burden and reduce software modification requirements to support the use of domains.

[0205] Another advantage of using the exception return instruction is that, usually when returning from an exception, the processing circuit can execute an atomic set of operations in response to the exception return instruction. The set of operations required when returning from an exception can be executed atomically, so that these operations cannot be divided midway, and therefore the instruction fails and none of the atomic set of operations is executed, or the instruction is successfully executed and all of the atomic set of operations are executed. For the second variant of the exception return instruction, the processing circuit can similarly execute an atomic set of second operations, which can be different from the atomic set of the first operation. The mechanism provided in the processor to ensure that the exception return instruction is completed atomically can be reused for domain entry in order to avoid situations where domain entry can only be partially executed, which can lead to security weaknesses. For example, the atomic set of the second operation can include making the domain execution context state available, changing the current domain being executed, and controlling the branch to the program counter address where the process was previously executed when the same domain was last executed.

[0206] The first variant and the second variant of the exception return instruction may have the same instruction encoding. Therefore, no modification of the exception return instruction itself is necessary in order to trigger the domain entry. This improves compatibility with legacy code. Whether a given exception return instruction is executed as the first variant or the second variant may depend on the control value stored in the state register of the given exception return instruction (for example, the first value and the second value of the control value may represent the first variant and the second variant of the exception return instruction, respectively). Therefore, the current architectural state when the exception return instruction is executed controls the exception return instruction to return the processor to a lower privilege level in the same domain, or trigger entry to a new domain.

[0207] This approach enables domain entry to be controlled with fewer software modifications, particularly when the value in the status register can be set automatically by hardware in response to certain events that suggest a domain switch is possible (in addition to allowing voluntary setting of the control value in response to software instructions). For example, when an exception condition occurs that triggers an exit to a given domain, the processing circuitry may set the control value to the second value for the given domain, so that a subsequent exception return instruction will automatically return processing to the domain where the exception occurred, even considering that the exception handler code used to handle the exception is the same as the previous legacy code that was not written in the domain. Alternatively, it may be expected in some architectures that when exiting from a domain, the control value in the status register will still contain the second value that was set prior to triggering domain entry to that domain, and thus explicit setting of the control value in the status register may not be required.

[0208] In one example, the control value in the status register may be an R flag in a SPSR register associated with the current exception level, as discussed above. Using the SPSR may be useful because this register will be used normally at an exception return to provide a processor mode (including the exception level) and other information about how the process should continue when returning from the currently processed exception. However, for domain entry, this information may be determined based on the domain execution context (REC) instead, and therefore the SPSR may not be needed. By reusing a portion of the SPSR to store the R flag that controls the exception return instruction to be considered as the first variant or the second variant, this avoids the need to provide an additional register for storing this information. Therefore, it may be useful to use a status register that is used to determine the return state information (such as the processing mode) for continuing the exception at the less privileged exception level in response to the first variant of the ERET instruction, but in response to the second variant of the exception return instruction, this return state information will be determined based on the memory instead, so that there is no need to access the status register itself. Specifically, the status register for storing the control value may be a status register associated with the current exception level, and the exception return instruction is executed from this current exception level.

[0209] like Fig. 27 As shown in , at least one domain identifier register may be provided, and in response to a second variant of the exception return instruction, the processing circuit may identify the destination domain from the domain identifier stored in the domain identifier register. The domain identifier register may be grouped so that there are multiple domain identifier registers each associated with one of the exception levels, and in response to the second variant of the exception return instruction, the processing circuit may identify the destination domain from the domain identifier stored in the domain identifier register associated with the current exception level. By using the domain identifier register to store the target domain identifier, it is not necessary to include this in the instruction encoding of the ERET instruction, which enables the existing format of the ERET instruction to be used to trigger domain entry, thereby reducing the amount of software modification required. The domain identifier in the domain identifier register may be a local domain identifier used by an upper-generation domain to reference a descendant domain of the upper-generation domain, and thus domain entry may be limited to transmission from an upper-generation domain to a descendant domain, and it is not possible to go from a first domain to another domain that is not a direct descendant of the first domain. In response to the second variant of the exception return instruction, the processing circuitry may trigger a fault condition when the realm associated with the realm ID identified in the RID register is an invalid realm (no realm descriptor has been defined or the realm descriptor defines a RID for a lifecycle state other than active).

[0210] In response to the second variant of the exception return instruction, the processing circuitry may restore the architectural state associated with the thread to be processed in the destination domain from a domain execution context (REC) memory area specified for the exception return instruction. The state restoration may be performed immediately (e.g., as part of an atomic set of operations) in response to the second variant of the exception return instruction, or may be performed later. For example, the state restoration may be performed in a lazy manner, so that the state required to start processing in the destination domain may be restored immediately (e.g., program counter, processing mode information, etc.), but other state such as general registers may be gradually restored when needed at a later time, or in the background of continued processing in the new domain. Therefore, the processing circuitry may begin processing of the destination domain before all required architectural state has been restored from the REC memory area.

[0211] In response to a first variant of an exception return instruction, the processing circuitry may branch to the program instruction address stored in the link register. For example, this may be Fig. 27 The ELR corresponding to the current exception level at which the exception return instruction is executed. In contrast, for the second variant of the exception return instruction, the processing circuitry may branch to a program instruction address specified in a domain execution context (REC) memory area. Therefore, because the link register will not be used for the second variant of the exception return instruction to directly identify any architectural state for the new domain, the link register may be reused to instead provide a pointer to the REC memory area from which the architectural state of the new domain will be restored. This avoids the need to provide a further register for storing the REC pointer.

[0212] Therefore, prior to executing an exception return instruction that attempts to cause a realm entry to a given realm, some additional instructions may be included to set the RID register to the realm identifier of the destination realm and to set the link register to store a pointer to the REC memory area associated with the destination realm. The REC pointer may be obtained by the parent realm from the realm descriptor of the destination realm.

[0213] In response to the second variant of the exception return instruction, when the REC memory area is associated with the owner domain other than the destination domain or the REC memory area specified for the exception return instruction is invalid, the fault condition can be triggered by the processing circuit. The first check prevents the previous generation domain from inducing the child domain to execute with the processor state that the child domain has not created itself, because the memory area owned only by the child domain can be stored in the REC memory area that can be accessed when entering the domain (and as discussed above, the REC memory area will be set to RMU private). The second check of the validity of the REC memory area can be used to ensure that the REC memory area can be used only once to enter the domain, and subsequent attempts to enter the domain with the same REC data will be rejected. For example, each REC can have a life cycle state that can be invalid or valid. In response to an exception occurring during the processing of a given thread in the current domain, the architecture state of the thread can be saved to the corresponding REC memory area, and the corresponding REC memory area can then be converted from invalid to valid. In response to the successful execution of the second variant of the exception return instruction, the REC memory area can then be converted back from valid to invalid. This prevents an ancestor realm from maliciously causing a child realm to behave incorrectly by specifying a pointer to a stale REC memory area, a REC memory area associated with a different thread, or some other REC that is associated with the destination realm but is not the correct REC used to store the architectural state at the previous exit of the realm.

[0214] In a corresponding manner, an exit from a domain may reuse the mechanisms provided for exception handling. Thus, in response to an exception condition occurring during processing of a first domain that cannot be handled by the first domain, the processing circuitry may trigger a domain exit to a parent domain that initialized the first domain. Upon exception occurrence / domain exit, some additional operations may be performed that would not be performed for an exception occurrence that could be handled within the same domain. For example, this may include masking or washing of architectural state and triggering of state storage to REC, as will be discussed in more detail below.

[0215] However, in some cases, an exception may occur that cannot be handled by the domain of the previous generation of the first domain in which the exception occurred. Therefore, in this case, it may be necessary to switch to a domain of a further previous generation that is beyond the previous generation. Although it may be possible to provide the ability to switch directly from a given domain to a domain of a previous generation that is more than one generation older, this may increase the complexity of the state registers required to handle exception entry and return or domain exit and entry.

[0216] Alternatively, when an exception condition is to be processed at a target exception level with a larger privilege level than the maximum privilege exception level allowed to be executed by the parent domain of the first domain, a nested domain exit may be performed. The nested domain exit may include two or more successive domain exits from the child domain to the parent domain until a second domain is reached, which is allowed to be processed at the target exception level of the exception that occurred. Therefore, by raising the domain level one level at a time, this can simplify the architecture. At each successive domain exit, there may be an operation performed to save a subset of the processor state to a REC associated with the corresponding domain.

[0217] When the exception has been handled, then in response to the exception return instruction of the second variant executed in the second domain after the nested domain exit, the processing circuit can then trigger the nested domain entry to return to the first domain. This can be handled in different ways. In some instances, the hardware can trigger the nested domain entry by itself without requiring any instructions to be executed at any intermediate domain encountered between the first domain and the second domain during the nested domain exit. Alternatively, the hardware can be simplified by providing a nested domain entry process, which returns back to each successive domain encountered in the nested domain exit one level at a time and executes a further ERET instruction of the second variant at each intermediate domain. In this case, to ensure that the intermediate domain triggers the return to the child domain of the intermediate domain that makes the domain exit to the intermediate domain during the nested domain exit, the exception status register can be set to indicate that the abnormal condition of the predetermined type occurs in the child domain. For example, a new type of abnormal condition (such as "fake domain exit") can be defined to handle this intermediate domain situation. Therefore, when the intermediate domain is reached, the processor can then resume the processing in the intermediate domain from the program instruction address, which corresponds to the abnormal handling routine for handling the abnormal condition of the predetermined type. This exception handling routine may, for example, simply determine that the child realm was exited for some unknown reason and may then choose to execute another exception return instruction of the second variant to return processing to the further child realm. By performing this operation at each intermediate realm, eventually, the original first realm where the original exception occurred can resume processing.

[0218] During this nested domain entry and exit procedure, the intermediate domain flag in the status register can be used to mark which domains are intermediate domains to trigger hardware-triggered immediate domain entry to the relevant child domain or trigger the setting of exception status information, which will then trigger the exception handler or other code in the intermediate domain to return to the child domain. For example, the intermediate domain flag can be as follows: Fig. 27 The Int flags in the associated SPSR are discussed in .

[0219] Fig.28Flowchart for illustrating a method for handling domain entry or exception return. At step 400, when the current exception level is ELx, an exception return (ERET) instruction is executed. ELx can be any one of the exception levels supported by the processing circuit. Although the technician may not expect an exception return to occur from the least privileged exception level EL0, the ability to create a secondary domain as discussed below means that there may still be an ERET instruction executed from EL0 to trigger the proceeding to the secondary domain also executed at EL0. In addition, some types of exceptions may be handled at the same exception level as the level where the exception occurs, in which case an exception return may still occur from EL0.

[0220] At step 402, processing component determines the current value of the domain flag R in the SPSR associated with exception level ELx. If domain flag R is zero, then this indicates traditional exception return, and does not enter different domains. At step 404, processing component 8 determines the target exception level to operate after exception return based on the PSTATE value in SPSR_ELx, and determines the program counter value to branch from link register ELR_ELx. New target exception level and program counter value and any other return state associated with returning to handle after exception are restored to the associated architecture state register associated with target exception level (this target exception level will be generally the less privileged lower exception level compared to exception level ELx, but can also be the same exception level ELx). This type of return state operation is performed atomically. At step 406, processing is subsequently recovered at the target exception level, but stays in the domain identical with the domain that performs ERET instruction.

[0221] If at step 402, the domain flag R is set to 1, this indicates a domain entry, and therefore this triggers a second atomic set of operations that is different from the set performed for a traditional exception return. At step 408, the processing component triggers the domain management unit to perform a number of domain checks. These include checks for:

[0222] The local RID indicated in the domain identifier register RID_ELx associated with the exception level ELx indicates a valid child domain. That is, the RMU checks the domain descriptor accessed from the domain descriptor tree 360 ​​for specifying the child domain, and checks whether the life cycle state of the domain descriptor of the child domain indicates an active state. If the child domain is in any state other than the active state, the domain check is unsuccessful.

[0223] The RMU 20 also checks that the REC memory area indicated by the pointer in the link register ELR_ELx is a memory area owned by the child domain indicated in the domain ID register RID_ELx. That is, the RMU 20 accesses the domain group table 128 (or cached information from the RGT 128), locates the associated entry corresponding to the memory area indicated in the REC pointer, and checks the owner domain specified for that memory area. The owner domain indicated in the ownership table may be specified as a global RID, and this may be compared to the global RID specified in the domain descriptor of the target child domain to determine whether the child domain is a valid owner of the REC. If the REC is owned by any domain other than the specified child domain in the RID register, this check is unsuccessful.

[0224] The RMU 20 also checks whether the state of the REC memory area defined in the ELR_ELx is valid. There are different ways in which the validity of the REC memory area can be indicated. For example, each REC memory area may include a flag that specifies whether the REC memory area is valid. Alternatively, a separate table may define the validity of RECs stored in other memory areas. If the REC has been used to store the architectural state of the associated domain on a previous exception exit, but has not yet been used to restore the state after returning from the exception, then the REC may be valid. If the REC is invalid, the domain check is again unsuccessful.

[0225] The RMU 20 also checks whether a flush command has been executed after the last exit from any child domain other than the one indicated in the RID register RID_ELx. The flush command will be discussed in more detail below, but is a command used to ensure that any state of the REC that is still to be saved to the child domain is pushed to memory (this helps support the lazy state preservation method). If no flush command has been executed and the system attempts to enter a different child domain than the previously exited child domain, there is a danger that there may still be state left in the processor registers that has not been pushed to memory. Implementing the use of the flush command ensures that different child domains can be safely entered without the loss of state of the previous child domain (or leakage to other domains). There may be multiple ways to identify whether a flush command has been executed. For example, some status flags may be used to track (a) whether there has been a change to the RID register RID_ELx after exiting from the last domain, and (b) whether a flush command has been executed after exiting from the last domain. This may cause the realm check to be unsuccessful if there is a change to the RID register and no flush command has been executed since exiting from the previous realm.

[0226] If any of the domain checks are unsuccessful, a fault is triggered at step 409 and the system stays in the current domain associated with the ERET instruction. Therefore, it is not possible to reach the child domain unless all of the domain checks are successful.

[0227] If all domain checks are successful, then at step 410, the processing component switches to processing in the child domain indicated in the domain ID register RID_ELx. For example, the processor may have an internal register that specifies the global RID of the current domain (this internal register may not be visible to software and is different from Fig. 27 A switch to a child realm may occur by writing the global RID of the new destination realm into the internal RID register.

[0228] At step 412, the state associated with the new domain is made available based on the state stored in the memory in the REC memory area indicated by the pointer in the ELR_ELx register. Because the REC area is owned by the new child domain, the REC area is now accessible, and therefore return state information, such as the program counter and the target exception level, can be obtained from the REC. At this point, a selected subset of the architectural state can be restored from the REC, or alternatively, the architectural state can be restored lazily so that processing can be started without fully restoring all state, and then the state can be gradually restored when needed or over a period of time to improve performance by reducing latency before processing can be restored from the new domain.

[0229] At step 414, it is determined whether the intermediate realm flag Int is set in the SPSR associated with the new realm. The SPSR contents will be restored from REC along with the rest of the architectural state. If the intermediate realm flag is not set, this indicates that the new realm is the realm where the original exception occurred (or the realm is being entered for the first time without any previous exception occurring in the realm), and therefore no further realm entry into the descendant realm needs to be triggered. At step 416, the program counter is obtained from REC, and then at step 418, processing continues in the new realm at the target exception level obtained from REC.

[0230] Alternatively, if the middle domain flag is set, this indicates that the nested domain exit has occurred previously, and the nested domain entry has reached the middle domain. Therefore, it is necessary to make the processing return to the further child domain, so as to return to the domain where the exception occurred originally. There are two alternative techniques for handling this situation. In the first alternative, at step 420, the forged domain exit exception is taken, and therefore the exception status register associated with the new domain can be set to the state code associated with the exception of this type by the processing component, and then the processing branch is to the exception vector associated with the exception of this type, and this exception vector triggers the exception handler to be processed. The exception handler does not have to perform any actual processing, but can simply determine that the exception of unknown type occurs in a given child domain and therefore can subsequently trigger another ERET instruction to execute at step 422. When the middle domain previously entered the further child domain, the RID and ELR registers associated with the middle domain still can have the values ​​placed in these registers, and therefore the ERET instruction execution can subsequently trigger the further domain entry to the further child domain. The method may return to step 408 to check whether the domain check was successful for this further domain entry, and then the method continues in a similar manner to previous domain entries in the nested process.

[0231] Alternatively, instead of handling the nested domain entry using another ERET instruction executed in the intermediate domain, at step 424, the hardware may detect that the intermediate domain flag is set for the current domain, and may then trigger further domain entry to the child domain without executing any instructions within the intermediate domain, and the method may then return to step 408.

[0232] Fig.29 A flow chart illustrating a method of exiting or taking an exception from a domain is shown. At step 430, an exception occurs within a given exception level ELx, which targets an exception level ELy (ELy ≥ ELx). The target exception level ELy is the exception level at which the exception will be handled. The target exception level may be the same as ELx, only one exception level higher than ELx, or may be multiple exception levels higher.

[0233] At step 432, the RMU determines whether the target exception level ELy is greater than the boundary exception level (BEL) of the current domain, which can be read from the domain descriptor of the current domain, and whether the current domain is a sub-domain (see the discussion of sub-domains below - Fig.16The type field of the domain descriptor shown in specifies whether the domain is a sub-domain). If the target exception level ELy is not greater than the boundary exception level, this indicates that the exception can be handled within the current domain, and therefore if the current domain is a full domain, there is no need to trigger a domain exit. In this case, at step 434, the processing component switches the current exception level to ELy (for example, by updating the current state register), or if ELx=ELy, the current exception level remains the same (in any case, the current exception level is now ELy). At step 436, the current processing state associated with the exception level ELx is saved to a register accessible to the target exception level ELy. For example, the program counter can be saved to the link register ELR_ELy, and the previous exception level ELx at which the exception occurred can be indicated in the PSTATE value in SPSR_ELy. In addition, the domain flag R in the SPSR_ELy register can be set to 0 to indicate that the exception is from the same domain, and therefore any subsequent exception return does not need to trigger a domain entry. Information about the type of exception that occurred can also be saved to the exception status register ESR_ELy. At step 438, the processing component branches to the exception vector associated with the specified exception type, and then processing continues to handle the exception. Finally, when the exception handling is completed, the ERET instruction will be executed to trigger a return to the previous processing, as described above for Fig.28 discussed.

[0234] On the other hand, if at step 432, the target exception level ELy is greater than the BEL of the current domain, or if the current domain is a sub-domain (for which any exception triggers an exit to the parent domain of the sub-domain), a domain exit is required in order to handle the exception. At step 440, it is determined whether the exception corresponds to a voluntary domain exit. Some types of exceptions may be triggered by unexpected events, such as a user pressing a button on a processing device, some failures occurring. However, it is also possible that the domain voluntarily withdraws processing and returns to the parent domain. For example, the child domain may have reached the end of some processing procedures, or some functions at a higher exception level may need to be called. When the child domain intentionally exits to the parent domain and then allows the child domain to share data with the parent domain, it may be useful to allow some architectural states of the child domain to be retained for access from the parent domain, so that fewer states are masked and washed compared to involuntary domain exits. For example, general registers may not be masked and washed, but other control registers may still be masked and washed. This avoids the need for data to be stored to a globally visible memory area, since the state can then be accessed directly from registers, thereby improving performance. That is, for voluntary domain exit, the child domain controls the domain exit and can therefore assume that the child domain has overwritten visible architectural state that should not be accessible to the parent domain, and leaves any state that the child domain wants to share with the parent domain in registers. Voluntary domain exit can be triggered, for example, by a predetermined variant of an exception-triggering instruction that corresponds to a particular type of exception for which no masking or scrubbing is performed.

[0235] If the domain exit is not a voluntary domain exit, then at step 442, masking of the selected subset of the architectural state is performed. Masking ensures that the architectural state to be hidden is inaccessible to the previous domain. However, the previous domain may still attempt to access the register storing the architectural state, and thus a scrubbing operation may be performed, which scrubbing operation ensures that any subsequent access to the scrubbed architectural register will return a predetermined value, regardless of what value is actually stored in the physical register associated with the architectural register. That is, when a register scrubbing operation is performed on a given architectural register that is part of the masked subset storing the architectural state, this ensures that if a subsequent read access to the given architectural register is performed by the processing circuit without any intervening write access to the architectural register between the domain switch and the subsequent read access, the subsequent read access to the given architectural register will return a predetermined value (e.g., zero). The register scrubbing operation can be performed in different ways. For example, the physical register corresponding to the given architectural register may be set to a predetermined value (e.g., this value of zero may actually be written to the physical register). Alternatively, register scrubbing may be performed by register renaming, such that a given architectural register is remapped from a first physical register to a second physical register. Another method can set a state value associated with a given architectural register or a physical register mapped to a given architectural register to indicate that a read access to a given architectural register should return a predetermined value. Using these latter two methods, the masked architectural state can be kept in the physical register file of the processing component, even if the masked architectural state is not accessible from the new domain, and any access to the state will return a predetermined value. This is useful for supporting the delayed state preservation as discussed below. Once the masking and washing operations have been performed, at step 444, the processing component triggers the preservation of the masked subset of the architectural state to the REC memory area associated with the current domain where the exception occurs. This preservation can be performed immediately, or can be performed lazily, overlapping with subsequent processing in the previous generation domain. Which method is adopted may depend on the specific implementation of the architecture and is therefore not a necessary feature of the architecture. However, delayed state preservation can improve performance.

[0236] If the domain exit is a voluntary domain exit, then at step 443, a reduced subset of architectural states is masked and scrubbed in the same manner as at step 442, except that at least some of the states that would be masked / scrubbed for an involuntary domain exit do not need to be masked / scrubbed for a voluntary domain exit. For example, the reduced subset of architectural states may exclude general purpose registers. After step 443, the method continues to step 444 as discussed above for an involuntary domain exit.

[0237] Regardless of whether the domain exit is voluntary or involuntary, at step 446, the processing component switches to the previous domain. Because the RID_ELx and ELR_ELx registers associated with the child domain exception level and controlled by the previous domain exception level will still be set to the RID and REC pointers of the previously exited child domain (because these have been set before the ERET instruction is executed to enter the child domain for the first time), there is no need to adjust this state, and therefore any subsequent ERET instruction will return to the same child domain as before. If the previous domain wishes to switch from the last exited child domain to a different child domain, only these registers need to be updated. Similarly, the domain flag R in the SPSR of the previous domain can still be set to 1 after the previous domain is entered, and therefore this value can be maintained so that the ERET instruction is subsequently regarded as an entry to the new domain unless the R flag is cleared to 0 by the instruction executed in the previous domain.

[0238] At step 448, the RMU determines whether the target exception level ELy is greater than the BEL of the new previous generation domain, and the processing has been switched to the new previous generation domain. If not, this indication can take an exception in the previous generation domain, and at step 450, the processing component 8 branches to the corresponding exception handler suitable for handling the type of exception that occurs. If the target exception level is higher than the BEL of the previous generation domain, a nested domain exit is required in order to branch to a further previous generation domain, and therefore at step 452, the intermediate domain flag associated with the previous generation domain is set to 1 in the SPSR, and then the method returns to step 442 to trigger the shielding and washing of the architectural state associated with the domain (at this time, the domain exit is not a voluntary domain exit because the domain exit has been triggered outside the control of the previous generation domain). The method can then loop again to shield or wash any appropriate state associated with the current domain and then switch to the previous generation domain of the domain. The nested domain exit can be looped multiple times until the domain that can handle the exception is finally reached.

[0239] At steps 412, 442, 444, the subset of architectural state that is masked, flushed, and saved upon exit from a domain, and restored upon entry to a domain may depend on the bounding exception level of the domain being exited / entered. For non-nested domain exits and entries, the selected subset may include a subset of architectural state accessible to the exception level where the exception occurred, such as in, for example, Fig. 27As indicated in . Thus, each exception level is associated with a group of registers, and in response to a domain exit exception condition occurring during processing of a given domain to be handled by an exception handler at a more privileged exception level than the boundary exception level of the given domain, a subset of registers may be selected according to the boundary exception level of the given domain, and may include those registers accessible to the processing circuitry when processing a software process at that exception level. If the exception occurs at EL1 or higher, this may include all registers accessible to that exception level and any lower exception level for non-nested domain exits. Similarly, upon returning to a domain, a corresponding subset of the architectural state may then be restored.

[0240] However, for nested domain exit, it may be assumed that for the intermediate domain, any registers accessible at a lower exception level than the boundary exception level of the intermediate domain will have been modified by the descendant domain at the lower exception level because the intermediate domain triggers entry into the descendant domain. Therefore, it may not be necessary to save such registers accessible at the lower exception level to the REC associated with the intermediate domain during nested domain exit (no further execution at the intermediate domain has occurred since the previous entry into the descendant domain). Conversely, during nested domain entry, it is not necessary to restore these registers accessible at the lower level during passage through the intermediate domain because these registers will subsequently be restored by the domain at the lower exception level. Alternatively, the intermediate domain state save and restore may simply include registers accessible at the boundary exception level of the intermediate domain but not accessible at the lower exception level. For example, in the intermediate domain at EL1, the state saved / restored on nested domain exit / entry may include Fig. 27 352 accessible at EL0 but may exclude subset 350 accessible at EL0. If the intermediate realm is at EL2, then the save / restore subset of state during nested realm exit / entry may include subset 354 accessible at EL2 but exclude subset 352 accessible at EL1. Using this approach, the amount of state save and restore required when passing through the intermediate realm may be reduced to improve performance.

[0241] Thus, when an exception condition is to be handled by an exception handler at a target exception level that is more privileged than the boundary exception level of the parent domain of a given domain where the exception occurs, a nested domain exit may be triggered, the nested domain exit comprising a plurality of successive domain exits from a child domain to a parent domain until a target domain having a boundary exception level corresponding to the target exception level or higher is reached. A corresponding state masking process (and state saving) may be triggered for each of the successive domain exits, and each corresponding state masking process may mask (and save) a corresponding register subset selected based on the boundary exception level. For a domain exit from a given child domain having a boundary exception level other than the least privileged exception level, the corresponding register subset masked / saved during the nested domain exit may include at least one register accessible at the boundary exception level of the given child domain, but may exclude at least one register accessible to a processing circuit at a less privileged exception level than the boundary exception level of the given child domain (because it may be assumed that such registers will have been saved when exiting the domain at the less privileged exception level). This reduces the amount of operations required for state masking and saving.

[0242] Similarly, upon domain entry (exception return), the intermediate domain flag may be used to determine whether the domain being entered is an intermediate domain. If the intermediate domain status value for a domain having a boundary exception level other than the least privileged exception level is set to a predetermined value (indicating an intermediate domain), the register subset to be restored upon domain entry may include at least one register accessible at the boundary exception level of the intermediate domain, but may exclude at least one register accessible to processing circuitry at a less privileged exception level than the boundary exception level of the particular domain. If the intermediate status value is set to a value other than the predetermined value, the domain being entered is the last domain and therefore the register subset to be restored that is accessed may include all registers accessible to processing circuitry at the boundary exception level of the particular domain (without excluding any registers from lower levels).

[0243] In this way, state saving and restoring operations during nested realm exit and entry can be performed more efficiently.

[0244] Fig.30An example of non-nested domain entry and exit is shown. In this example, the parent domain is A operating at exception level EL1 and the parent domain wishes to enter the child domain B having BEL of EL0. Obviously, similar domain entry and exit procedures can be performed at other exception levels. At step 460, the parent domain sets the domain identifier register RID_EL1 to the local domain ID of the child domain B. The local RID has a format obtained by sequentially connecting the tree index as discussed above. At step 462, the parent domain at EL1 sets the link register ELR_EL1 to the address that provides a pointer to the domain execution context of domain B. The parent domain obtains this pointer from the domain descriptor of the desired child domain B. At step 464, the parent domain sets the domain flag R in SPSR_EL1 to 1. At step 466, the parent domain then executes the ERET instruction, which is interpreted as triggering domain entry when the domain flag is set to 1. Execution for Fig.28 The various domain checks described above of step 408 of , and if these domain checks are successful, domain entry is executed to switch to domain B. At step 468, the state is restored from the REC indicated in the link register. This state includes the target exception level in which the new domain will execute. It should be noted that when REC is accessed, the processor is still in the previous exception level associated with domain A and therefore this is why link register ELR_EL1 is still accessible to obtain the REC pointer, even though a switch to domain B has been made and ultimately the domain will resume processing from EL0. State restoration can be performed immediately or can be performed deferred within a time period in parallel with the rule processing 470 of domain B.

[0245] When an exception occurs during execution of the child domain B at step 472, a set of masking operations are then performed to hide the state associated with domain B from the domain's parent domain. This includes masking and scrubbing of at least a subset of the architectural state associated with EL0 at step 474 (the subset of architectural state that is masked / scrubbed may depend on whether the exit is a voluntary or involuntary domain exit). Masking makes the state inaccessible and scrubbing ensures that subsequent accesses to the corresponding registers from the parent domain will trigger that the predetermined value will be returned. At step 476, a state save to the REC associated with domain B is performed for the masked subset of architectural state. In this case, because the child domain has a BEL of EL0, the masked subset of state includes at least the subset 350 accessible at EL0. In addition, the state save may be triggered immediately, or may be performed in a lazy manner in parallel with the continued processing of the exception at the parent domain. At step 478, the domain exit is then triggered to switch to the parent domain A, and at step 480, the handling of the exception is performed in the parent domain. Fig.30 Steps 474 and 476 may be omitted for voluntary domain exits.

[0246] Fig.31 A similar example is shown, which shows nested domain entry and exit. Grandparent domain A at exception level EL2 executes an ERET instruction at step 500, whereby the link register has been set to point to the REC of the desired child domain, the domain ID register RID_EL2 is set to the local RID of the child domain, and the R flag is set to 1 in SPSR_EL2. This triggers a domain entry to domain B at step 502, and the state of this trigger at step 504 will be restored from the REC of domain B, which can also be executed immediately or lazily. Finally, domain B then executes a further ERET instruction at step 506, again setting the link register, RID register and R flag to trigger a further domain entry at step 508. It should be noted that the domain entries at steps 502 and 508 can be as shown. Fig.28 , and thus steps (such as domain checking) are still performed, but for simplicity are shown in Fig.31 After entry to domain C, the architectural state of domain C is then restored from the REC of domain C at step 510 and processing is resumed within domain C at step 512 .

[0247] Subsequently, an exception occurs at step 514. The exception targets exception level EL2. For example, the exception may be an exception type to be handled by the hypervisor (such as an event associated with a virtualized device or a stage 2 address translation failure). At step 516, the state masking process includes any scrubbing and state preservation to communicate with the hypervisor. Fig.30 A similar manner as shown in is triggered, and at step 518, a domain exit to domain B is performed, which is the parent domain of domain C where the exception occurs.

[0248] At step 520, the processing component detects that the target exception level for the exception that occurred is higher than the boundary exception level of domain B, and therefore domain B is an intermediate domain and a domain exit to a further domain of the parent domain of domain B is required. Therefore, at step 522, the intermediate domain flag is set in SPSR_EL1, and at step 524, further state masking, scrubbing and saving of the subset of registers is performed. In addition, if the corresponding state can be maintained in the register process in some way that is inaccessible to the processor after the domain exit to domain A, then the saving part of this process can be postponed. The subset of registers saved for this intermediate domain includes registers 352 accessible at EL1 but excludes registers 350 accessible at EL0. There is no need to save the subset of registers 350 because domain B has not executed any instructions to change these registers since the previous domain entry at step 508, and these registers have been masked / scrubbed / saved by domain C. Therefore, this reduces the amount of additional masking and state saving required for the intermediate domain.

[0249] A further domain exit 526 to domain A is subsequently triggered, and this domain A is the parent of the middle domain. In this case, domain A can handle exceptions because this domain A can operate at EL2, and therefore at step 528, the exception is trapped and handled at exception level EL2. The exception is handled by the manager, and once the exception has been handled, the ERET instruction 530 is executed to return to the previous processing. At this time, the values ​​of ELR_EL2 and RID_EL2 and the R flag in SPSR_EL2 are still the same as before the ERET instruction is executed at step 500. Therefore, it is not necessary to set these values ​​again. The ERET instruction 530 triggers the domain entry of the previous child domain B at the exception level EL1 backward. It should be noted that the exception handler code may already have this ERET instruction in the old code for returning the processing to the lower exception level after the handling of the exception. Therefore, reusing the ERET instruction as discussed above to trigger the domain enables the existing exception handler code written without knowing the domain protection function to continue to be used, thereby reducing the platform development cost.

[0250] Upon returning to domain B at EL1, the processing component detects that the intermediate flag is set in SPSR_EL1 (step 532). Therefore, at step 534, the state restored from the REC of domain B is the state accessible to EL1 (register 352) but excludes register 350 accessible at EL0. If the processor implementation uses a software-assisted method of triggering nested domain entry, then at step 536, the processing component sets the exception state register ESR_EL1 for the intermediate domain to a specific value corresponding to the fake domain exit. The processing component sets the program counter to the exception vector, which indicates the exception handler for handling this predetermined type of fake domain exit exception, and then the exception handler is executed at step 538. The exception handler need not implement any real function, but may simply trigger an ERET instruction or alternatively may also provide some other operation. Finally, the ERET instruction is executed at step 542, which triggers a domain entry 544 backwards to the previous child domain that was executed before the original exception occurred, because the ELR_EL1, RID_EL1, and SPSR_EL1 registers are still set as they were before the ERET instruction was executed at step 506. At this point, at step 546, the state is restored from REC of domain C, and processing continues at step 548 in the same manner as at steps 510 and 512 above.

[0251] Alternatively, for hardware assisted nested domain entry, steps 536 to 542 may be omitted, and instead of restoring the required subset of states at step 534, the hardware of the processing component may detect from the intermediate domain flag that a further domain entry to domain C is required, and thus at step 550, the hardware may directly link the subsequent domain entry without requiring a further ERET instruction 542 to be executed. In this case, no instructions need to be executed within the intermediate domain.

[0252] By using this nested realm entry and exit procedure, this avoids the realm at EL2 needing to handle any realm values ​​or REC pointers associated with EL0. This allows for cleaner and simpler checks when entering a realm, as only the parameters of the immediate children of the current realm need to be checked. This greatly simplifies the architecture and hardware implementation.

[0253] Fig.32 and Fig.33The lazy state preservation to REC and the state recovery from REC at the time of domain exit and domain entry are shown respectively. In general, when a domain is exited to the previous generation domain, it is desirable to mask the state associated with the child domain to hide the state from the previous generation domain, and perform scrubbing to ensure that if the previous generation domain attempts to access the architectural register corresponding to the scrubbed state, some predetermined values ​​will be seen. These operations can be performed relatively quickly. However, if there is insufficient space in the physical register file of the processing circuit to be used to infinitely maintain the state of the child domain, it is desirable to save some of the data to REC. However, this can take a long time and occupy the memory bandwidth that can otherwise be used for processing in the previous generation domain, which can delay the processing in the previous generation domain. Similarly, the corresponding operation for restoring the state from the memory to the register after entering the domain can take some time. Therefore, for performance reasons, it is desirable to support asynchronous preservation / recovery of the processing component state to / from REC. Whether a given processor implementation actually performs this lazy state preservation is an implementation choice for a specific processor. For example, some processors that are not targeted for high performance may find it simpler to simply trigger the state save operation immediately to reduce the complexity of managing which state has been saved and which state has not been saved. However, to provide performance when needed, it may be desirable to provide architectural features that support such asynchronous, lazy state save methods.

[0254] Therefore, in response to a domain switch from a source domain to a target domain that will be processed at a more privileged exception level than the source domain, the processing circuitry may perform state masking to make a subset of the architecture state data associated with the source domain inaccessible to the target domain. Although it is possible that this masked subset of state is saved to memory, this is not necessary at this time. However, the architecture provides a clear command that can be used after the domain switch. When the clear command is executed, the processing circuitry ensures that any of the masked subsets of the architecture state data that have not yet been saved to at least one REC memory area owned by the source domain is saved to at least one REC memory area. By providing this clear command, it can be ensured that when it is necessary to ensure that a subset of the architecture state data has been explicitly saved, this can be forced through, and when this subset of the architecture state data is actually saved to memory when the clear command has not yet been executed, this gives the freedom of precise variation of the specific micro-architecture implementation for the architecture.

[0255] In addition to state masking, after a domain switch, the processing circuitry may also perform a register scrubbing operation as discussed above, which ensures that any subsequent read access to a given architectural register returns a predetermined value if performed without an intervening write access. This scrubbing may be performed by actually writing the predetermined value to a physical register corresponding to the given architectural register, or by register renaming, or by setting other control state values ​​associated with the given architectural register to indicate that a read access should return the predetermined value rather than the actual contents of the corresponding physical register. If these state saves are performed asynchronously in response to the domain switch, the processing circuitry may begin processing of the target domain while at least a portion of the subset of architectural state data that was made inaccessible in response to the domain switch is still stored in registers of the processing circuitry. For example, a processor may have a larger physical register file than the number of registers provided as architectural registers in an instruction set architecture, and therefore some spare physical registers may be used to hold previously masked state for a period of time after the target domain has begun processing. This is advantageous because if processing then returns to the source domain while a given item of the subset of architectural state data is still stored in a register, the processing circuitry can simply restore access to that given item of architectural state from the register file, without needing to restore the data from the REC. Some types of exceptions may require only a relatively short exception handler to be executed, in which case it is possible that some mask state will still be resident in the register file upon return from the exception. Such "shallow" exception entry / return events may benefit from the use of lazy state preservation.

[0256] If lazy state saving is used, once processing of the target domain has begun following an exception, the processing circuitry may trigger saving of a given entry of the REC area in response to the occurrence of a predetermined event other than a flush command. Although processing has now switched to the parent domain (which would not normally have access to the REC associated with the previous child domain), because these operations are triggered in hardware by the microarchitecture implementation rather than by software, they are not subject to the same ownership checks required for normal software-triggered memory accesses (effectively, these REC save operations will have been authorized by the child domain prior to exiting).

[0257] Many different types of scheduled events may be used to trigger certain items of a subset of the architecture state data to be saved to the REC, including the following:

[0258] Register access to an architectural register that corresponds to a given entry of a subset of the architectural state data. This approach may be useful for less complex processors that do not support register renaming. In this case, each architectural register may map to a fixed physical register, and so the first time the code associated with the parent domain attempts to access a given architectural register, then this may require the old value of the register used by the child domain to be saved to memory.

[0259] Remapping of the physical registers of a given entry storing a subset of the architectural state data. In systems that support register renaming, the architectural state may be retained longer in the register archive, but eventually it may be necessary to remap the corresponding physical registers to store different values ​​and at that point the corresponding architectural state of the descendant domain may be saved to the REC.

[0260] The number of available physical registers becomes less than or equal to a predetermined threshold. In this case, once the number of free physical registers (which can be reallocated to different architectural registers) becomes low, state saving can start to be performed preemptively, rather than waiting for the actual remapping of a given physical register.

[0261] After a given number of cycles or a given time period. Thus, it is not necessary for any particular processing event to trigger the save, but instead a lazy state save can simply extend the save of the context of the child domain to the REC over the time period in order to reduce the impact on the memory bandwidth available for other memory accesses triggered by processing in the parent domain.

[0262] An event indicating reduced processor workload, such as idle processor time cycles or some other event indicating that performing a state save now will have less impact on the overall performance of the previous generation domain process. At this point, a save of at least a portion of a subset of the architectural state data may be triggered.

[0263] After the domain switch, if the processing circuit attempts to enter a further domain other than the source domain, the domain was previously switched from the source domain to the previous domain, then when the further domain will be processed at the same exception level or less privileged exception level of the target domain exited compared to the previous domain and no clear command has been received between the domain switch and the domain entry request, the processing circuit can reject the domain entry request. Alternatively, the domain entry request can be accepted regardless of whether the clear command has been executed, but if the clear command has not been executed, the initial child domain REC state can be destroyed, so that REC cannot be used again, thereby preventing effective entry into the child domain. In short, the clear command is required before the previous domain can successfully direct the processing to a different child domain than a previously executed domain. This ensures that even if the hardware chooses to use a lazy state preservation method, all necessary states associated with the previous child domain will have been submitted to be saved to the memory when entering the different child domains. This avoids the need for multiple sets of child domain data to be saved to the memory to be backed up and simplifies the architecture.

[0264] It should be noted that the flush command is only required to ensure that the state from the mask register is committed to be stored to the REC memory area. The store operation triggered by the flush command may be queued within the load / store queue of the processing component 8, or in a queue within the interconnect 14, memory controller, or memory 16 itself, so the actual write to the memory cell may not occur until later, but from the perspective of the processing component, the memory write will definitely occur knowing the mask state.

[0265] The flush command may be a native instruction supported by an instruction decoder of the processing circuit. Alternatively, the flush command may be a command triggered by a predetermined event to continue processing of instructions decoded by the instruction decoder. For example, the flush command may be automatically triggered by some other type of instruction that implies that a state save operation should be ensured to have been triggered to memory for all required subsets of the architectural state associated with the previous child domain.

[0266] As discussed above, the particular subset of architectural state to be saved during a domain switch may depend on the boundary exception level associated with the source domain (and may also depend on whether the source domain is an intermediate domain in a nested domain exit). If the domain switch is a predetermined type of domain switch (e.g., a domain switch triggered by the execution of a voluntary domain switch instruction in the source domain), the state masking and saving operations may be suppressed.

[0267] therefore, Fig.32An example of lazy state preservation and restoration is shown. At step 560, domain exit is handled in the same manner as discussed above. Although a subset of the architectural state hidden for domain B is masked and washed at domain exit, the state preservation to REC can be postponed and thus the lazy state preservation process 562 can be performed in the background of processing 564 associated with the previous generation domain A. The specific way to perform lazy state preservation can be selected for the implementation of the special processing design. At step 566, the previous generation domain triggers a domain entry backward to the previous child domain (using the ERET instruction as discussed above). In this case, because the domain entry returns to the same child that was previously exited, the flush command that is not required for domain entry will be valid. If part 568 of the lazy state preservation operation is still executed, this can be canceled after the domain entry, and the corresponding state value for domain B can be simply restored from some of the physical registers of the processing component instead. Therefore, for relatively shallow abnormal exits and returns, using a lazy state preservation method helps to reduce the capacity of required memory accesses, thereby improving performance.

[0268] Fig.33 Shown with Fig.32 Another example of a domain exit 560 from domain B1 to the domain's parent domain A is performed in the same manner as in . However, at this point, domain A wishes to switch processing to a different child domain B2, rather than returning to the same domain. Therefore, the parent domain executes a flush command at step 570, which triggers the processing component to ensure that any remaining portion of the lazy state preservation process 562 is completed (i.e., all remaining architectural state storage operations are issued for the masked subsets that are still resident in the register file of the processing component). At step 572, the parent domain sets the domain identifier register and link register to indicate the domain ID and REC pointer for the target domain B2, and then executes an ERET instruction at step 574, which triggers a domain entry 566 to domain B2. If the flush command has not been executed before the ERET instruction is executed, the domain entry will fail. At step 578, state recovery is performed from the REC memory area of ​​domain B2 (again, this can be done lazily).

[0269] Thus, use of the flush command enables fast exception exits and slow flow out of the processor state into the REC of the previously exited domain, and also allows shallow exception exits and returns where the state remains in registers of the processing component and is not stored and reloaded from the REC.

[0270] Fig.34 shows the concept of a sub-domain that can be initialized by a parent domain. Fig.34As shown in , a given previous domain 600 operating at a specific exception level can initialize a sub-domain 602, which operates at the same exception level as the previous generation of the sub-domain. The full domain 600 corresponds to a given software process (or a set of two or more processes), but the sub-domain corresponds to a predetermined address range within the given software process. Because the full domain is the previous generation of the sub-domain, as discussed above, the sub-domain may have the authority to access data stored in a memory area owned by the previous generation full domain, but the sub-domain may have the authority of the previous generation full domain of the sub-domain to exclude data from accessing data stored in a memory area owned by the sub-domain 602. This can be used to allow a certain part of a given software process to be safer than other parts of the software process. For example, a part of the code for checking passwords in a mobile banking application or for processing other sensitive information can be assigned to a sub-domain to prevent other parts of the same application or operating system from accessing the sensitive information.

[0271] A sub-domain may generally be handled in the same manner as a full domain, with some differences as explained below. Entry to and exit from a sub-domain may be handled in the same manner as discussed above using exception return instructions and exception events. Thus, a sub-domain may have a child domain ID constructed in the same manner as a full child domain of the same ancestor, and may have a domain descriptor within a domain descriptor tree as discussed above. Entry to a sub-domain may be simply triggered by executing an ERET instruction which has placed the appropriate child sub-domain RID in the RID register prior to the execution of the ERET instruction. Thus, the same type of ERET instruction (of the second variant) may be used to trigger entry to either a full domain or a sub-domain.

[0272] One way that sub-realms may differ from full realms may be that sub-realms may not be allowed to initialize their own child realms. Thus, if the current realm is a sub-realm, a realm initialization command for initializing a new realm may be rejected. The RMU may use the realm type value in the realm descriptor of the current realm to determine whether the current realm is a full realm or a sub-realm. By disabling realm initialization when currently in a sub-realm, this simplifies the architecture because no additional status registers need to be provided for use by a sub-realm in initializing further realms.

[0273] Similarly, when currently in a sub-domain, the execution of domain entry instructions can be prohibited. This simplifies the architecture, because this means that some of the grouped registers such as ELR, SPSR, ESR and RID registers discussed above that are used to handle domain entry and exit (and exception entry and return) do not need to be grouped again for each sub-domain, otherwise this will be difficult to manage, because it may not be known at design time how many sub-domains a given process will create. Similarly, when the current domain is a sub-domain rather than a full domain, the exception return event that triggers the switch to the process operating at a lower privilege level can be prohibited. Although a single type of ERET instruction is used as both a domain entry instruction and an exception return instruction in the example discussed above, this is not necessary for all embodiments, and in the case of providing a separation instruction, both exception return instructions can be prohibited when the current domain is a sub-domain.

[0274] Similarly, when an exception occurs while in a sub-domain, the processing circuitry may trigger an exit from the sub-domain to the parent full domain that initialized the sub-domain before handling the exception, rather than taking the exception directly from the sub-domain. Therefore, the exception triggers a return to the parent full domain. The exception return to the parent full domain may include state masking, washing, and saving operations on REC, but by avoiding the exception going directly from the sub-domain to the domain at the higher exception level, this avoids the need to group exception control registers such as ELR, SPSR, and ESR again for the sub-domain, thereby simplifying the architecture.

[0275] For a sub-domain, the boundary exception level indicating the maximum privilege level of processing allowed for the domain is equal to the boundary exception level for the ancestor full domain of the domain. Conversely, for a child full domain, the boundary exception level is a less privileged exception level than the boundary exception level of the ancestor domain of the child full domain.

[0276] When a Realm is initialized by an Ancestor Realm, the Ancestor Realm can choose whether the new Realm will be a child Full Realm or a child Sub Realm, and can set the appropriate Realm Type parameter in the Realm Descriptor accordingly. Once a Realm is operational, the Ancestor Realm can no longer change the Realm Type, as modifications to the Realm Descriptor are blocked by the above instructions. Fig.18 The management domain lifecycle in question is prohibited.

[0277] In summary, the ability to introduce a sub-domain that is managed similarly to the full domain but where exception handling, domain initialization, and domain entry functionality are prohibited within the sub-domain enables smaller portions of code corresponding to a given address range within a software process within the full domain to be isolated from other portions of the software to provide additional security for certain segments of sensitive code or data.

[0278] As described above, a domain management unit (RMU) can control the transition of a memory region between multiple region states (or life cycle states). Available region states may include at least: an invalid state, in which the memory region is allowed to be reassigned to a different owner region; and a valid state, in which the memory region is assigned to the owner region, the owner region is accessible, and is prevented from being reassigned to a different owner domain. For a memory region that is converted from an invalid state to a valid state, the RMU may require that a scrubbing process be performed to set each storage location of the memory region to a value that is unrelated to the previous value of the memory in the memory location. For example, scrubbing may include writing zero to each location within the memory region that is scrubbed, or may include writing some other fixed non-zero value to each memory location, or writing a random value to a different memory location that is unrelated to the previously stored value. In any case, scrubbing ensures that any previous data stored in an invalid region when the region is owned by a different domain cannot be accessed by the new owner domain when the region becomes valid. The patrol clear process may be triggered by the RMU itself in response to a command requesting that the region transition from invalid to valid, or alternatively, the patrol clear may be triggered by a different command or series of commands (separate from the command indicating the transition from invalid to valid).

[0279] On the top Fig.21 and Fig. 22 In the example of , the invalid state and the valid state are the only states that a memory region can have (in addition to the RMU-private state). This means that in order for a given domain to obtain ownership of a non-RMU-private memory region, the memory region must be patrolled and cleared, which takes some time and causes the actual physical memory locations to be updated with the new data values, so the physical memory needs to be committed. In addition, once a region becomes valid, the RMU will not be able to distinguish whether the region has just been patrolled and cleared and therefore the data is not important, or whether at least one write request to write actual data to the region has occurred since the region became valid, so if an output command is executed, the data needs to be output to the backup storage device, and therefore space in the backup storage device will be consumed.

[0280] Below Figure 35 to Figure 39In the example discussed, an additional patrol clear-commit state is provided in which a memory region is allocated to an owner domain, but the memory region is not accessible by the owner domain until a patrol clear process has been performed on the memory region, and the memory region is prevented from being reassigned to a different owner domain. This means that it is not necessary to perform a patrol clear process in order for a memory region to be allocated to a particular owner domain. Thus, owned regions can be allocated to a domain in the patrol clear-commit state, and if the owner domain does not use all of these regions for some reason, the time and energy associated with performing a patrol clear process is not consumed unnecessarily.

[0281] In some examples, the patrol clear-commit state may be a zero-commit state in which the region is inaccessible to the owner domain until a patrol clear process has been performed to write a zero to each location of the memory region. Alternatively, the patrol clear-commit state may correspond to a patrol clear process that writes a non-zero value to each location.

[0282] Typically, a region in the patrol clear-commit state may not be accessible to the owner domain until a patrol clear process has been performed on the memory region. Therefore, it will be necessary to perform a patrol clear process before the region becomes valid and accessible to the owner domain. If the owner domain attempts to perform a memory access to a memory region in the patrol clear-commit state, the memory access circuitry may signal an abnormal condition (e.g., a fault). For example, the abnormality may trigger the parent domain or other management process to trigger one or more commands to perform a patrol clear process and convert the region state to valid.

[0283] As described above, although the RMU and the memory access circuit can implement the ownership rights of the memory area of ​​the first memory, the first memory may not have enough capacity to process all the data that may be needed, so sometimes some data may need to be output from the first memory to the second memory (for example, Figure 1). The RMU 20 and the memory access circuit 26 may not be able to protect the data while the data is in the second memory, so an output command is provided that triggers encryption of the data stored in the output target memory area specified by the output command, and writes the encrypted data to the second memory so that the output target memory area can then be converted from a valid state to an invalid state and reused for other data. When the RMU processes the output command, the RMU may generate metadata specifying at least one characteristic of the data stored in the output target memory area, and store the metadata to the first memory. For example, the metadata may include a hash of the original unencrypted data, or some other information that may allow the validity of the encrypted data in the second memory to be checked. The metadata may be stored in an area of ​​the first memory that is private to the RMU (i.e., one of the RMU private states discussed above, especially Fig. 22 The RMU private area may be inaccessible to the owner domain of the area storing the metadata (except by commands directed to the RMU). In response to an input command corresponding to the metadata, the domain management unit may trigger decryption of encrypted data read from the second memory, verify the integrity of the decrypted data using the metadata stored in the first memory, and when the integrity of the decrypted data has been verified, restore the decrypted data to the input target memory area and convert the input target memory area to a valid state. Thus, the metadata allows the encrypted data to be potentially tampered with or modified when stored in the second memory area to be identified, so that this does not compromise the ownership permissions of the owner domain of the area that previously stored the data in the first memory.

[0284] However, generating the encrypted data and metadata takes some time and involves some processing resources. In addition, outputting the data to the second memory consumes space within the second memory. By providing a patrol clear-commit state, memory areas can still be allocated to the owner domain, but they can be output to the second memory without actually generating any encrypted data and without having to write any data to the second memory. Alternatively, in response to an output command specifying an output target memory area in a patrol clear-commit state, the RMU can suppress encryption and writing to the second memory, and generate metadata specifying that the output target memory area is in a patrol clear-commit state. The target memory area can then be converted from the patrol clear-commit state to an invalid state. When an input command is executed and the corresponding metadata specifies that the target memory area is in a patrol clear-commit state, the RMU can simply convert the selected memory area from an invalid state to a patrol clear-commit state, and there is no need to read data from the second memory because there is no ciphertext associated with encryption.

[0285] Therefore, the child domain can be created and assigned many owned memory areas, so that from the perspective of the child domain, the child domain has a considerable available address space, so the child domain will not have to claim ownership of all these areas later, claiming ownership of all these areas may cause problems and conflicts with other owner domains. However, the child domain can be created using minimal committed memory, because the patrol clear-commit state means that the page can be output immediately without generating any ciphertext, where the metadata only indicates that the corresponding area is in the patrol clear-commit state. Therefore, when creating a domain, both the first memory and the second memory do not need to commit physical space immediately. This can improve performance in many cases. Some example usage models are discussed below.

[0286] Various RMU commands may be provided to trigger transitions between memory region lifecycle states. For example, a patrol clear-commit variant of a region add command that specifies a predetermined region (e.g., a variant of the zone group add command 232 discussed above), and a patrol clear-commit target memory region that is currently in an invalid state (e.g., by an ancestor domain of the predetermined region) may be used to control the RMU to allocate a target memory region for ownership of the predetermined region, and to convert the patrol clear-commit target memory region from an invalid state to a patrol clear-commit state. For example, the ancestor domain may directly transfer ownership of a currently invalid memory region owned by it to the child domain in the patrol clear-commit state, so that the child domain does not need to immediately commit the first or second memory space to these regions, but may ensure some of the owned regions.

[0287] Another example of an RMU command may be a patrol clear-commit command that specifies a patrol clear-commit target memory area that is valid and owned by the domain that issued the command. In response to the patrol clear-commit command, the RMU may convert the patrol clear-commit target memory area from a valid state to a patrol clear-commit state. Therefore, a given child domain may require that one of the areas it owns be converted to a patrol clear-commit state. For example, this can be used for a balloon driver that has variable memory usage and can therefore be allocated a relatively large amount of memory, but may later find that some areas are not necessary and can be returned for other purposes. By converting areas that are no longer needed to a patrol clear-commit state, this retains the following options: the child domain can easily return these areas to valid without having to go through the ownership claim process again later if the driver's memory requirements increase again (avoiding the risk that other domains may claim to own these pages during this period), but if the parent domain determines that some areas that are no longer needed should be reallocated for other purposes, the parent can safely remove them from the child domain by outputting these areas for reuse without consuming physical space in the second memory.

[0288] In order to convert the patrol clear-commit memory area to valid, a commit command may be executed by the RMU to trigger the patrol clear process to be performed. The command may be issued by the child domain that owns the area in the patrol clear-commit state, or may be issued by the parent domain of the owner domain of the area in the patrol clear-commit state. Therefore, the RMU may accept a commit command issued by the owner domain, or the parent domain of the owner domain of the commit target memory area.

[0289] Fig.35 An example of a set of memory region life cycle states that may be implemented in some examples is shown. Fig.35 include Fig.21 The Zero Commit state includes all states of the RMU, but additionally includes the Zero Commit (Patrol Clear-Commit) state, in which the memory region is not accessible to software, but is assigned to a specific owner domain and is therefore prevented from being reallocated to a different domain. The Zero Commit state is not an RMU private state. In the Zero Commit state, unlike the Invalid state, the region cannot transfer ownership to a different domain, but unlike the Valid state, the region is not accessible to software because the Patrol Clear process has not yet been performed. The transition from Zero Commit to Valid requires the Patrol Clear process to be performed.

[0290] like Fig.36 As shown, it can be expanded Fig. 22 The state diagram of the example includes the zero-commit state 800. For simplicity, Fig.36 middle, Fig. 22The various RMU private states 226, 228 shown in FIG. 1 are simply shown as a single state, but Fig.36 The example is still available Fig. 22 All transitions between the invalid state 220 and the various RMU private states 226, 228 shown in FIG. Fig.37 Shows Fig.23 An extended version of , in which a zero-commit state 800 is added, so that the parent domain can convert one of its invalid domains to the zero-commit state and assign one of the invalid domains to one of its children in the new state by executing a zero-commit variant 802 of the block group add command, and the active child can convert one of its valid regions to the zero-commit state 800 by executing a zero-commit command 804.

[0291] like Fig.36 and Fig.37 As shown, a number of commands are provided (in addition to those previously described) to handle transitions to the zero commit state, as follows:

[0292] Zone Group Add Command Patrol Clear-Commit (Zero-Commit) Variant (802)

[0293] Rmu.granule.add(rid,ZC,src,dst)

[0294] rid = the RID of the child domain to transfer ownership

[0295] ZC = parameter indicating that this is a zero-commit variant added for the block

[0296] src, dst: The addresses of the conversion areas in the address space of the previous generation domain and the next generation domain respectively

[0297] Similar to Fig.23 Block add command 232 (acceptable only if the specified child realm is in new state), but the parent may defer zero-filling to a later time. Realm measurements are updated for zero-filled blocks. Block state in RGTE (ownership table entry) is recorded as zero-committed.

[0298] Patrol Clear-Commit (Zero-Commit) Command 804

[0299] RMU.granule.zerocommit(rid,a)

[0300] Transitions the owning zone (memory region) to zero-commit (ZC) state

[0301] Called by the owner of the zone, i.e., rid will specify the current domain, and a will be zero - the address of the target zone to submit.

[0302] Patrol-clean-commit (zero-commit) variant of the clean command (810)

[0303] Called by the owner of an invalid owned block (memory region) to convert the owned block to zero-commit (ZC) state without actually performing a patrol clean. Rather than converting invalid blocks to valid or RMU-private as other variants for the clean command do, this variant converts invalid blocks to zero-commit.

[0304] Submit command 806

[0305] RMU.granule.commit(rid,a)

[0306] The patrol clears (eg, zero-fills) the contents of the block and sets the state to valid.

[0307] Reject if the block indicated by address a is not in the zero-commit state or the specified field is inactive.

[0308] Called by the owner domain or an ancestor of the owner domain.

[0309] Output Command

[0310] RMU.granule.export()

[0311] Output ZC zones will not produce target ciphertext, only metadata. The metadata generated for an output ZC zone indicates that the zone is a ZC zone and has no ciphertext.

[0312] Enter the command

[0313] RMU.granule.import()

[0314] The input ZC zone group has no input ciphertext, only MD. This causes the invalid zone group to be converted to ZC, but it will not be automatically patrolled and cleared (zero-filled) ZC zone group - a commit command will be issued to perform patrol and clear and convert to valid.

[0315] Note that for simplicity, input and output commands are not listed in Fig. 22 and Fig.36 As shown in , because the export command can be called for the memory region in any life cycle state to convert the export target region to invalid, and the import command can be called to convert the import target region to any other state (including invalid).

[0316] Fig.38To illustrate a processing flow chart of an output command in an embodiment, it includes a zero commit state 800 in a set of life cycle states that can be used for each memory region of the first memory 16. At step 820, the RMU 20 receives the output command. At step 821, the RMU 20 converts both the output target memory region (the address space page mapped to the on-chip memory 16 from which data is output) and the output destination memory region (the address space page mapped to the location in the external memory 6 to which the data is output) to the RMU-private state. During the processing of the output command, these regions remain RMU private.

[0317] In step 822, the RMU 20 checks the domain region group table (ownership table) 128 to determine the region life cycle state that the output target memory region had before receiving the output command (i.e., before the output target memory region was converted to the RMU private state at step 821).

[0318] If the output target memory area is valid, invalid, or RMU private (including Fig.35 ), then at step 824, the RMU 20 triggers the encryption unit 104 to encrypt the data stored in the output target memory area. For the area in the invalid state, instead of encrypting the actual data read from the physical memory, in step 824, a ciphertext is generated by encrypting virtual data that is not based on any actual stored data (because the invalid area has no actual stored data associated with the area of ​​the address space). For example, a ciphertext obtained by encrypting a random or pseudo-random value can be generated for an invalid page. Alternatively, for an invalid page, the encryption of the virtual data and the writing of the encrypted data to the second memory 6 can be omitted to save time and energy. However, by outputting encrypted virtual data for an invalid area even if there is no valid data, this prevents the parent domain of the child domain from trying to determine which areas are valid or invalid by issuing output commands for different areas to understand the operation of the child domain-from the perspective of the parent domain, both valid and invalid areas are treated the same (since encryption is performed regardless of whether the area is valid or invalid, the time used to perform the output operation is the same, so the timing associated with the output operation does not provide information about whether the area state is valid or invalid).

[0319] In step 826, the RMU generates metadata specifying at least one feature of the output data to allow subsequent validity checks on the input data. For example, the metadata may be a hash of the contents of the target memory region, which would allow modifications of the data in the second memory to be detected when it is imported. The metadata may also specify other information, such as the location of the second memory 6 to which the data will be exported. In addition, the metadata may specify the attributes of the domain zone group table entry associated with the output target memory region (such as the region life cycle state, mapping address, or visibility attributes) so that these attributes can be restored when the region is imported later. The previous domain software may be responsible for allocating or managing metadata for input and output commands, and tracking which metadata block corresponds to which encrypted page in the second memory (for example, by using software-defined metadata in the page table, or pointers in the metadata itself, to track the relationship between a given address in the address space of the child domain and the corresponding metadata and encrypted data in the memory). In step 828, the RMU triggers the writing of the encrypted data generated in step 824 to the second memory 6. In step 830, the RMU triggers the writing of the metadata to an RMU private area in the first memory 16, which is owned by the same owner domain as the output target memory region. It should be understood that Fig.38 The relative ordering of steps 824 to 830 in are examples only, and these steps may be completed in a different order (e.g., metadata may be generated in parallel with encryption, or may be performed before encryption, and the relative order of writing to the second and first memories may vary).

[0320] On the other hand, if the output target memory area is in a zero-commit state at step 822, then at step 832, metadata is generated that specifies that the output target memory area is in a zero-commit state. Similarly, the metadata of the zero-commit state may specify the attributes of the corresponding RGT entry. The RMU suppresses encryption of data stored in the memory area and writing the encrypted data to the second memory, so that it is not necessary to consume either the time and energy associated with performing lengthy encryption processing and generating metadata based on data characteristics (for example, hashing may take some time), and it is not necessary to consume memory within the second memory to store encrypted data. After step 832, in step 830, the metadata is again written to the RMU private area in the first memory. It should be noted that although omitting encryption processing for areas in the zero-commit state might theoretically allow the parent domain to determine that the output page is in the zero-commit state by analyzing the time taken to perform the output operation, in practice this is not a problem because the zero-commit areas of the child domain will typically be used in situations where the parent domain is allowed to know which areas are in the zero-commit state (either the parent domain created the zero-commit areas itself when creating the child domain, or the child has autonomously requested that areas be zero-committed so that the parent can take advantage of them and output them with reduced output time), so omitting encryption processing will not leak any undesired knowledge about the operations of the child domain to the parent domain.

[0321] Regardless of the output destination memory region state, after step 830 or step 834, the output destination memory region is converted to an invalid state so that, although any data may be retained by encrypting and exporting it to the backup memory, the physical area within the first memory may be reallocated for use by a different software process (once any patrol clearing has been performed to allow conversion to a valid state). In addition, the output destination memory region is converted to a valid state.

[0322] Therefore, by using a zero commit state, output can be made faster and memory commits can be avoided.

[0323] Fig.39The corresponding flow chart of the processing of the illustrated input command is shown. In step 840, the RMU 20 receives the input command. In response to the input command, in step 841, the RMU converts both the input source memory area (the page of the address space of the input data from the external memory 6) and the input target memory area (the page of the address space of the input data in the on-chip memory 16) to the RMU-private state. In step 842, the RMU accesses the previously stored metadata associated with the input command. For example, the input command may specify an address in the address space of the previous domain that issued the input command, and this can be used to index into the metadata tree to access the previously stored metadata. In step 844, the state of the previously output memory area indicated by the metadata is determined. If the state is in the zero commit state, then in step 846, the input target memory area is simply converted to the zero commit state, and no data needs to be read from the second memory 6 or any decryption or integrity verification is performed. The input target memory area can be any invalid area of ​​the first memory 16. When the area is converted to the zero commit state, ownership can also be assigned to the same domain that owns the corresponding output target memory area output by the previous output command. The ancestor field issuing the import command may specify the RID of the relevant child that will own the page after importing into the import command itself.

[0324] If the state of the previously output memory area is indicated as valid or RMU-private at step 844, then at step 848, the previously output encrypted data is read from the second memory 6. The location where the encrypted data is read may be specified by the metadata itself. At step 850, the encrypted data is decrypted, and at step 852, the integrity of the decrypted data is verified using the metadata (e.g., the hash is compared with the result of applying the same hash function to the decrypted data). If it is determined at step 854 that the verification is unsuccessful, then at step 856, an exception may be signaled or the input may be rejected so that the decrypted data is not written to the first memory to avoid compromising the ownership protection provided by the RMU 20 and the memory access circuit 26. If the verification is successful, then at step 858, the decrypted data is restored to the input target memory area, and at step 860, the input target memory area is converted to RMU-private or valid (depending on the state of the previously output memory area). In addition, the target memory area for the input may be selected as any invalid area of ​​the first memory and may be converted to be owned by the domain having the RID specified by the input command.

[0325] If it is determined in step 844 that the previously output memory area is in an invalid state, then in step 847, Fig.39The encrypted data is read from the input target memory area and decrypted in a manner similar to steps 848 and 850. Optionally, the integrity of the decrypted data can be checked for metadata in a manner similar to step 852, but this is not necessary for the invalid area because the decrypted data is virtual data for the invalid area, which is discarded without writing it to the input target memory area. Decryption of virtual data is performed in a manner similar to valid / RMU private pages, and the previous generation domain cannot obtain information about whether the page is valid or invalid from the time spent performing the input operation. In step 849, the input target memory area is converted to invalid.

[0326] Regardless of the state of the previously exported memory region determined at step 844, at step 862, the domain block group table entry for the input target memory region is restored based on the attributes specified by the metadata of the previously exported memory region. Since the data in the input source memory region is not modified during the import process, the input source memory region remains in a valid state after the import operation. In addition, after successfully importing the data, the metadata about the input source memory region can be destroyed to prevent repeated attempts to import the same "old" data.

[0327] The zero-commit state can be used in a range of usage models, including the following:

[0328] Realm creation:

[0329] Prefill memory completely. The parent realm creates the child realm normally. The parent then "pre-commits" the zero-filled memory region. A full MD tree is created for this using add(ZC) and export(ZC), using only one physical page (the RMU private page used to store metadata). When a page fault occurs for the ZC block group while the realm is running, the parent will commit the physical page to the child, enter the ZC into it, then commit() it, fix the MMU mappings and continue.

[0330] Memory allocation:

[0331] Reduces child bookkeeping requirements. Child asks parent for storage, parent provides and maps region of invalid block to child. Child claims immediate ownership of block. Child zero commits block for later use. Implicit contract of child doing this allows parent to choose ZC output. Child does not need to keep track of any additional state due to any complexity attached to parent. It is safe to let child take domain protection errors on ZC blocks and commit automatically.

[0332] Balloon Driver:

[0333] Software with variable memory usage. When memory usage drops, the driver will no longer need zero-commit (ZC) blocks. The parent can safely delete them from the child realm for reuse. Any child access to a previously zero-committed block will result in a page fault or realm protection fault.

[0334] As described above, the domain management unit (RMU) may maintain an ownership table specifying ownership entries, each of which defines an ownership attribute of a corresponding region of a given size of a memory. The ownership attribute specifies an owner domain of the corresponding region from a plurality of domains. The owner domain has the right to exclude other domains from accessing data stored in the corresponding region. The memory access circuit may control access to the memory based on the attributes defined in the ownership table.

[0335] In some instances, the RMU may perform a region fusion operation in response to a region fusion command that specifies a fusion target address, the fusion target address indicating multiple contiguous regions of memory that are to be fused into a fusion group of regions, the region fusion operation updating an ownership table to indicate that the ownership attributes of each region in the fusion group of regions are represented by a single ownership entry corresponding to a predetermined region of the fusion group. It may be relatively common that the same ownership attributes may need to be provided for multiple contiguous regions of memory, and in such a case, it may be more efficient to use a single ownership entry to represent the attributes of those regions, for example, if these entries are cached in a translation lookaside buffer or other cache structure by a particular microarchitecture implementation. Although the specific details of how such caching is implemented may be an implementation choice, by providing the RMU at the architectural level with the ability to respond to a region fusion command by updating the ownership table to indicate that the attributes of multiple contiguous regions may each be represented by a single ownership entry associated with one of the regions of the fusion group, this may improve performance. By caching a single entry representing the ownership attributes of the entire fusion group of regions, this frees up cache space to cache ownership entries associated with other regions of the memory address space. That is, by fusing groups of regions when possible, the portion of the total address space that can cache entries simultaneously may be increased, thereby improving performance.

[0336] This technique is particularly useful if the memory access circuit controls access to the memory based on both an ownership table and at least one translation table that provides address translation data for converting virtual addresses to physical addresses. The at least one translation data table can provide further access permissions for controlling access to the memory, which can provide an orthogonal layer of protection in addition to the ownership protection provided by the ownership table. For example, although the at least one translation table can implement top-down privilege-based access control (wherein a higher-privileged process can deny access to certain memory areas to a lower-privileged process), the ownership table can specify corresponding protections, which enables the owner domain to define a specific area of ​​the memory address space to set ownership attributes, which controls whether the higher-privileged domain can access the owned area. In a typical translation table, it is common to merge multiple virtual address pages into a single larger page, which can be represented by a single page table entry in a translation lookaside buffer or other cache structure. This can take advantage of the hierarchical nature of many translation tables, which can make it relatively easy for page table entries at a higher level to indicate that multiple lower entries have been combined. Thus, an operating system or other process that sets up the translation tables may expect that if it allocates memory so that multiple contiguous pages can each have their access permissions and address translation data represented by a single page table entry in the translation table, this should result in improved performance by improving the efficiency of managing the translation lookaside buffer or other cache structure used to cache information from the address cache table, thereby allowing more different pages to have their address translation data cached ethically within the TLB.

[0337] However, when access control is also based on the ownership table and the ownership entry of the ownership table is not merged or fused in a manner similar to the page table entry in the conversion table, then in fact this may hinder the performance improvement that can be expected by combining multiple conversion table entries. For example, in some micro-architecture embodiments, at least one translation lookaside buffer (TLB) can be provided, which caches information from both the address translation table and the ownership table. In some cases, the information from the address translation table and the ownership table can be combined into a single entry. Therefore, in this combined TLB, each entry can correspond to the minimum granularity of the memory area associated with the information from the address translation table or the information from the ownership table. Therefore, if the ownership entry remains unfused, even if the page table entry in the conversion table can be combined, this may not produce any efficiency improvement of TLB allocation. By providing RMU support for regional fusion commands, this enables multiple regions with corresponding ownership attributes to be fused into the fusion group of the region, wherein a single ownership entry can represent the ownership attribute, thereby improving the TLB allocation efficiency. It should be understood that not every micro-architecture can benefit from the potential performance improvement obtained by fusion, which depends on the specific implementation of the TLB. However, by providing architectural support for such region fusion commands, software can be written in such a way that those microarchitectures that provide TLB implementations that can benefit from fusion can realize these advantages.

[0338] Although combining different page table entries of a translation table by an operating system or other process managing the translation table writing updated page table entries to the translation table can be relatively simple to implement using an ownership table that defines different owners for different portions of the address space (where the owners are responsible for controlling which other domains can access data in the corresponding regions), this can make fusing regions associated with the ownership table more complex. Therefore, in contrast to translation table updates (where a single process responsible for managing the entire translation table can simply overwrite the entries to be updated), with region fusion in the ownership table, the RMU can be responsible for receiving a region fusion command from other processes requesting region fusion, and the RMU determines whether this region fusion command can be acted upon, and if so, performs a region fusion operation to update the ownership table to indicate that the attributes of each region in the fused group of regions can be represented by a single ownership entry. Therefore, there may be a separation between the following: the process requesting region fusion by issuing a region fusion command, and the RMU determining whether this region fusion command can be accepted (if so, controlling the region fusion operation to be performed). The RMU can be a dedicated hardware unit for controlling the management of ownership permissions, or it can be domain management software executed on the same processing circuit that also executes some software programs corresponding to the various domains.

[0339] Region merge commands may be allowed to be issued by different processes. In some cases, the owner domain that is designated in the ownership table as the owner of the contiguous regions to be fused may itself issue a region merge command to trigger those regions to be fused into a fused group of regions. For example, when setting ownership attributes for multiple contiguous regions, the owner domain may realize that those regions will have the same attributes and therefore may trigger a region merge command so that the common attributes of each region may be represented by a single entry in the ownership table. Thus, the TLB of some microarchitecture implementations may be able to cache a single ownership entry as a representation of the attributes of the entire fused group of regions, rather than requiring caching individual entries for each individual region.

[0340] However, the RMU may also allow a region fusion operation to be performed in response to a region fusion command triggered by a domain other than the owner domain specified in the ownership table of the contiguous region to be fused. For example, it may be useful to allow a software process involved in setting a translation table to request the fusion of regions defined in the ownership table. For example, when the operating system sets the translation table so that multiple pages of the address space have the same translation attributes, it may also issue a region fusion command to request that the corresponding regions be fused (if allowed by the RMU). The actual owner domain associated with those regions of the address space may not yet know that all regions have the same properties in the translation table, and may therefore not yet have chosen to fuse those regions. On the other hand, the operating system may not yet know whether the ownership attributes of those regions are the same, and if they are different, it may not be appropriate to fuse the regions, but if the RMU does approve the region fusion command, this can improve performance when using the operating system's translation table. Therefore, by allowing different processes to request fusion but providing the RMU to verify whether fusion is allowed, this can simplify the writing of software compared to only the owner domain can trigger fusion.

[0341] The RMU may verify whether or not it is appropriate to act on a region fusion command to prevent a situation where, for example, another process may issue a region fusion command, but the attributes set by the owner domain indicate that it is not appropriate to fuse those regions, for example because they may have different ownership attributes defined. Thus, in response to a region fusion command, the RMU may determine whether the region fusion command passes at least one verification check, and when at least one verification check fails, reject the region fusion command. When passing at least one verification check, the RMU may then perform the region fusion operation.

[0342] Typically, the at least one validation check may be such that the region merge command may pass the at least one validation check only if merging the specified regions does not result in a change in the effective ownership attributes of any of those regions. This means that whether or not the regions are merged does not affect the correctness of the program logic or the security of the ownership table implementation, but may only be a performance enhancement measure (which may or may not be selected to be acted upon by the RMU). From the perspective of the software issuing the region merge command, whether or not this region merge command passes the validation check has no effect on the correct operation of this software, but if it does pass the at least one validation check, this may achieve better performance.

[0343] For example, the RMU may determine that at least one validation check has failed when different ownership attributes are specified in the ownership entries for any two of the multiple contiguous regions to be fused. Thus, if the respective owners of any two specified contiguous regions are different or the owners have defined different ownership attributes (e.g., attributes that define which other processes can access these regions or indicate the status of a particular region (valid, invalid, patrol clear-commit, etc., as described above)), the validation check may fail, and any region fusion commands for those regions with different ownership attributes may be rejected accordingly. If the region fusion command is rejected, the ownership table remains unchanged, and therefore multiple separate ownership entries are still required to represent the attributes of the contiguous regions.

[0344] In addition to the ownership attributes that define the owner domain and any other access permissions, another form of validation checking may involve a mapping address that may be specified in each entry. Each ownership entry may correspond to a physically addressed memory region. The mapping address specified in a given ownership entry may identify the address to which the physical address of the corresponding region is mapped when the ownership attribute of the region is set in the ownership table. The mapping address may be a virtual address, an intermediate physical address, or a physical address, depending on the level of authority of the owner domain associated with the region. Specifying such a mapping address in an ownership entry may be used to avoid the security protection provided by the owner attribute being compromised when a process with higher authority than the owner domain of the corresponding memory region remaps the translation table to change which addresses are mapped to the physical address of the memory region after the owner attribute for this region has been defined in the owner table. As described above, when accessing memory, a partial security check that is performed to determine whether to allow memory access may compare the mapping address in the ownership entry of the physically addressed region of the desired memory with the corresponding address of this physically addressed region currently mapped to the memory, and deny memory access when these addresses do not match. When merging multiple regions into a fused group of regions that can be represented by a single ownership entry, if those contiguous regions do not specify a contiguous mapping address group, this may result in protections associated with checking mapping addresses being bypassed if only a single ownership entry is provided to record ownership attributes for the entire fused group. Therefore, when performing a validation check of a region merge command, the RMU may determine that at least one validation check has failed when the ownership entries of the contiguous regions specify a non-contiguous mapping address group.

[0345] As described above, each ownership entry may specify one of a plurality of region states associated with the corresponding memory region, which may include at least an invalid state and a valid state, in which the memory region is allowed to be reallocated to a different owner domain, and in which the memory region is allocated to a given owner domain and is blocked from being reallocated to a different owner domain. There may also be other states. In one instance, when the ownership entry of any continuous region to be fused specifies that the region is in any state other than a valid state, at least one verification check may fail. The transition of the region from an invalid state to a valid state may require certain measures to be performed to maintain security. For example, before the region can be transitioned to a valid state, the RMU may require that a patrol clearing process be performed to set each storage location of the region to a value that is not related to the previous value stored in the storage location. This can prevent data leakage from a region that was previously valid when it was reused and reallocated to a different owner domain. By requiring all continuous regions to be fused to be currently valid to implement the region fusion operation, this can ensure that the fused region cannot bypass such security measures before the region becomes valid, for example to avoid the need to patrol clear data from each fused region.

[0346] Typically, the translation table may be implemented as a hierarchical table involving multiple levels of sub-tables that are traversed in order to find the entry of interest for a given address, where data indexed at one level of the table structure is used to identify the relevant entry at the next level of the hierarchy. This can be used to allow information shared for a larger range of addresses to be specified in shared higher-level entries, rather than requiring this information to be copied for each region, and to allow entries corresponding to relatively large, sparsely populated address spaces to be compressed into a smaller space. Using a hierarchical table, it may be relatively straightforward to set an indication that multiple pages are to be combined, for example via a higher-level page table entry indicating that all lower-level entries below it are to be represented using common attributes.

[0347] In contrast, the ownership table may comprise one or more linear tables. In a linear table, the desired entry for a given address can be accessed via a single index into the table structure, rather than multiple jumps through the hierarchy as with a translation table. In some instances, the ownership table may comprise more than one linear table, for example, if multiple memory groups are provided, a separate linear table may be provided for each group, where a portion of the address selects which group's table to look up, and the remainder of the address provides a single linear index into the table for that group. A linear table may be faster for lookup performance, as it means that only one memory access is sufficient to obtain the desired ownership entry for a given memory.

[0348] In some implementations, a region merge command may specify that any number of regions are to be merged into a merge group represented by a single ownership entry.

[0349] However, for linear tables, efficiently handling the fusion of multiple regions so that they can be represented by a single ownership entry within the TLB or other cache structure can be more complex because there is no path into multiple entries of the table via shared higher-level entries as there is with a hierarchy of translation tables. Therefore, while it may be desirable to support the fusion of fused groups of multiple regions of different sizes, it may also be desirable to limit how many ownership entries must be updated when performing such fusions in operation, and to limit the granularity at which regions can be fused, to simplify the process of looking up the ownership tables and handling region fusion commands.

[0350] Therefore, in one example, the region fusion command may be a command in the form of a group size increment, which specifies an indication of the target fusion group size. The target fusion group size may be specified from a plurality of fusion group sizes supported by the RMU. The region fusion operation performed in response to the command in the form of a group size increment may include updating the ownership table to indicate that a plurality of continuous regions will be fused into a fusion group having a target fusion group size, each of which is associated with a fusion group having an expected current fusion group size, which is the next minimum fusion group size after the target fusion group size. By providing a command that increments the fusion group size to the next level, rather than enabling a single command to arbitrarily fuse any number of regions into the fusion group, this may make memory access for updating ownership entries to indicate the new fusion group size more efficient, as described below. In addition, if the fusion group is constrained to be the size of certain levels of the hierarchy (e.g., certain powers of 2 of the region), this may simplify conventional ownership table lookups, because the location of a single ownership entry representing the attributes of the entire fusion group may be an entry corresponding to an address aligned with a specific group size. This may make the micro-architecture implementation of the memory access circuit and the RMU more efficient.

[0351] In some cases, a region fusion command in the form of a group size increment may specify a target fusion group size directly. Alternatively, the target fusion group size may be implicit in some other information specified by the command. For example, the command may specify a desired current fusion group size that is expected to be associated with the contiguous region identified by the command, and in this case, the target fusion group size may be inferred from the desired current fusion group size to the next highest fusion group size among the supported fusion group sizes.

[0352] The minimum fusion group size among the supported fusion group sizes may correspond to a predetermined size of a single region. Thus, when regions are indicated as having the minimum fusion group size, this may effectively indicate that they are not part of any fusion group. Other fusion group sizes may indicate a fusion group comprising two or more fusion regions.

[0353] For region fusion commands in the form of group size increments, another form of validation check may be to check that the specified contiguous regions to be fused are currently associated with a current fusion group size, which is the next minimum fusion group size compared to the target fusion group size. That is, the RMU may check whether the actual current fusion group size of the specified regions matches the expected current fusion group size of the region fusion command. If any of the specified contiguous regions are associated with a current fusion group size (rather than the next minimum fusion group size compared to the target fusion group size), the validation check may fail and the command may be rejected. This may be useful because, as described above, a different software process may have issued a region fusion command, and therefore another process may have already fused the regions to form a fusion group having a target fusion group size or larger, and therefore in this case, the region fusion command does not have to be taken because the desired effect has already occurred.

[0354] In response to a region merge command in a group size incremental form, the region merge operation may include updating a subset of ownership entries associated with the contiguous regions to be merged. The subset selected may depend on an indication of a target merge group size specified by the region merge command. Thus, one advantage of providing the command in an incremental form is that it is not necessary to update every single ownership entry associated with every contiguous region in a fused group that is fused to the target fused group size. If multiple region merge commands are executed in succession to skip two or more steps of the fused group size hierarchy, the subsequent command may build on the updates to the table already made by the previous command to avoid the need to update all entries of the larger fused group.

[0355] For example, when the desired current fusion group size is the minimum fusion group size among multiple fusion group sizes (i.e., the specified region has not yet been fused into the fusion group), then the subset of entries to be updated may be all entries associated with the contiguous regions to be fused into the fusion group having the target fusion group size. On the other hand, when the desired current fusion group size is a fusion group size other than the minimum fusion group size, the subset of entries may be less than all entries associated with the contiguous regions to be fused. Specifically, when the desired current fusion group size is greater than the minimum size, then the selected ownership entries to be updated may include the first ownership entry of each fusion group that has been fused by a previous region fusion command, and thus it is not necessary to update ownership entries associated with subsequent regions in the same fusion group that are further fused by another region fusion command. For example, the subset of ownership entries updated in response to a region fusion command may be entries associated with regions whose addresses are offset by an amount corresponding to the desired current fusion group size associated with those regions.

[0356] In some cases, each level of the region merge commands in size increments may be associated with the fusion of a predetermined number of regions or fused groups of regions into a larger fused group size. In some cases, the number of regions or fused groups fused by a given command specifying a group size for a given level for a target fused group size may be the same for each level. In this case, the subset of entries selected for update may include the same number of ownership entries regardless of which fused group size is the target fused group size. Although the selected entries may be separated by different offsets depending on the target group size, this may limit the memory access overhead for performing the merge operation to a certain amount for each level of fused group size incremental processing.

[0357] However, in other instances, a command that specifies one fusion group size as a target fusion group size may combine a first predetermined number of regions or fused groups into a larger fusion group size, while a command that specifies a different target fusion group size may combine a different number of regions or fusion groups into a larger fusion group size. In this case, a different number of ownership entries may need to be updated depending on the target fusion group size.

[0358] Note that the subset of entries of the ownership table updated in response to a region merge command may also be the same subset that is looked up to verify whether the current fused group size is the next minimum fused group size compared to the target fused group size to determine whether to perform a region merge operation in response to the region merge command.

[0359] Each ownership entry may specify an indication of a current fused group size associated with the corresponding region. However, when only a subset of the entries are updated when processing a region merge command, this may mean that the effective fused group size associated with a given region may be indicated by the current fused group size indicated in an ownership entry associated with a region different from the given region. Therefore, when looking up a region table to allocate a new entry for a given region to the TLB, the TLB or RMU may need to attempt to read the current fused group size of multiple different ownership entries, each at an address boundary corresponding to a different candidate fused group size into which the desired region may have been fused, in order to determine the actual fused group size for this region, and thereby determine which ownership entry represents the attribute associated with this region.

[0360] In a corresponding manner, a region split command specifying a split target address may also be provided, the split target address indicating a region fusion group to be split into a subset of one or more regions. In response, the RMU may perform a region split operation to update the ownership table to indicate that the ownership attributes of the corresponding subset of the region are now represented by different ownership entries of the ownership table. Therefore, when the attributes of different subsets of regions within the fusion group now need to be set to different values, a region split command may be issued to signal that different ownership entries need to be cached in the TLB or other cache structure for those region subsets next. The subset of regions into which the fusion group is split may be a separate region, or may be a smaller fusion region group. For example, in some embodiments, the region split command may be a decremental form command that reduces the size of the fusion group by one level in the fusion group size hierarchy in a complementary manner to the incremental form region fusion command that increases the size of the fusion group by one level in the hierarchy. Alternatively, another form of region split command may simply split a fusion group of any size into separate regions. For similar reasons as discussed above for the incremental form region fusion command, the decremental form command may be constructed more efficiently in the microarchitecture.

[0361] Thus, for a decremental form of a region split command, the region split command may specify an indication of a target fused group size that is expected to be the next smallest fused group size compared to the current fused group size associated with the region fused group to be split. The RMU may verify that the actual current fused group size matches the expected fused group size, and if not, reject the region split command. Likewise, only a subset of ownership entries may be updated in response to a decremental form of a region split command, where the ownership entries updated are selected at an offset according to the indication of the target fused group size.

[0362] In some examples, a region split operation performed by the RMU may include triggering a lookaside buffer that caches information from the ownership table to invalidate any information associated with the fused region group indicated by the split target address. This may provide safety by ensuring that the TLB cannot continue to retain old information about the entire fused region group, so that if the owner domain of any of the split region subsets subsequently changes ownership attributes of those regions, the new attributes will be accessed because the previously defined attributes of the entire fused region group are no longer accessible from the TLB.

[0363] Alternatively, rather than triggering a TLB invalidation in response to a region split operation, a TLB invalidation may be triggered in response to a first update of information in one of the ownership entries associated with one of the previously fused region groups after the region split operation has been performed. This recognizes that the fused entry may be allowed to remain in the TLB as long as no changes to any ownership attributes of the previously fused region group have occurred after processing the split command. Since any change to the ownership attributes may be accompanied by a TLB invalidation in any case to ensure that the old attributes are not still cached in the TLB, this approach may avoid the need to perform an additional TLB invalidation in response to a region split command.

[0364] In some instances, the region fusion operation performed in response to the region fusion command may also include such TLB invalidation of any information associated with the new region fusion group. This may ensure that if any TLB entries associated with the respective fusion entries exist in the TLB, these entries are discarded so that the next access to any of these regions will trigger the loading of a single combined ownership entry, thereby allowing a greater number of other memory regions to also have entries of their ownership tables cached in the TLB. However, with the region fusion operation, TLB invalidation may be expected to achieve performance gains, but is not necessary for security and may therefore be omitted.

[0365] In some instances, during a region fusion operation, the RMU may lock ownership entries to be updated in the region fusion operation to prevent those ownership entries from being updated by other processes until the region fusion operation is completed. Similarly, ownership entries updated during a region split operation may also be locked until the region split operation is completed. This avoids unpredictable and potentially unsafe results that may occur if another process updates one of the related ownership entries midway through a region fusion operation or a region split operation, which may, for example, mean that verification checks may be bypassed or that incorrect ownership attributes may be indicated for some regions. By locking the related ownership entries at the beginning of an update process associated with a region fusion or split operation, and then unlocking these entries once all related updates are completed, a region fusion operation or a region split operation may be performed atomically. This means that any subsequently received command can only see the results produced by a complete region fusion or split operation. Any technique may be used to implement locking. For example, a bit may be specified in each entry that indicates whether the entry is locked by the RMU.

[0366] When a single target region is part of a region fusion group, commands that are serviced by the RMU that specify operations to be performed on a single target region of a predetermined size of memory may be rejected. For example, if the specified region is part of a fusion group, a command to change the region lifecycle state in the ownership table, a command to change the visibility attribute that controls which processes other than the owner domain can access the memory region, or a command to output data from a single target region to a backup storage device may be rejected. As described above, since region fusion commands can be issued by multiple processes, the process that issues the single region command may not be aware that the region has been fused, so it is useful for the RMU to check whether the target region is in a fusion group and reject such single region operations if so. If a single region RMU command is rejected, a fault handling routine in the software that requested the RMU command, or in an exception handler, may respond, for example, by issuing a region split command and then reissuing a single region RMU command.

[0367] Fig.40 An example of a hierarchical table structure for a translation table is schematically shown, which may be the level one page table 120-1 or the level two page table 120-2 discussed above. A translation table (page table) is used to describe virtual to physical address translation, memory type, and access permissions defined by a top-down approach, in which a higher privileged process responsible for managing the table defines in the table information that controls how a lower privileged process can access a corresponding memory area. A translation table is typically used to describe memory at a 4KB granularity. Logically, at each CPU memory access, the virtual input address will be checked against the translation table. In practice, these checks are cached in the TLB 100 for a range of addresses. The TLB hit (or miss) rate is an important contributor (influencer) to system performance.

[0368] The translation table is hierarchical in that multiple steps of indexing in different levels of the table are required to access the required information. Fig.40 An example with 4 levels of tables (levels 0 to 3) is shown, where the first portion of the address indexes into the level 0 table, and the index entry then specifies the base address of the corresponding level 1 table. The second portion of the address indexes into an entry in the level 1 table, which provides the base address of the level 2 table. The third portion of the address indexes into an entry in the level 2 table, which provides the base address of the level 3 table. The fourth portion of the address indexes into an entry in the level 3 table, which provides the actual address mapping and other access permission data required for the target address.

[0369] To improve TLB efficiency, the MMU architecture may allow larger areas of memory to be described, and these large areas can be cached in the TLB. For example, this can be done using block entries at earlier levels of the translation table, e.g., for a 4K byte translation table, the level 3 entry will describe a 4K byte page, and the level 2 entry will describe an area corresponding to 2M bytes. The level 2 entry can specify attributes for all level 3 entries below, so all individual level 3 entries do not have to be cached. Alternatively, consecutive entries within the current level of the table can specify that they will be combined into one, e.g., 16 aligned 4K entries can describe a 64K byte area. By using larger translations, software performance can be improved by a measurable percentage (1-5%). Real-world software such as Linux and Hypervisors can perform behind-the-scenes operations to align virtual and physical addresses to allow the use of larger pages.

[0370] On the contrary, Fig.41 As shown, the domain group table (ownership table) 128 can be implemented as one or more linear tables that are indexed based on a single index derived from the entity address. Each RGTE can identify multiple ownership attributes, including the owner domain, domain status, and visibility as described above, and can also specify Fig.19 , RGTE may specify additional parameters indicating the fusion level (fusion group size) as described below. For any given address, the desired entry in the linear table structure may be accessed with a single memory access simply by indexing into a single table based on the physical address. In some cases, multiple linear tables may be required (e.g., if covering regions in multiple memory groups), but still in such cases, the desired table is selected based on the address and the desired entry read from a single access to this table, rather than using information derived from one index entry of a table to then locate another entry at the next level of the hierarchy, as in Fig.40 Using such a linear table, it is not so simple to merge multiple regions so that their attributes can be represented by a single entry in the TLB. If regions with the same attributes cannot be merged, then Fig.25 In the microarchitectural implementation of the TLB 100 in the form shown (where a single combined entry caches information from both the translation table and the RGT), the TLB would have to allocate separate entries for different pages of the address space even if the translation table represented these pages using a single page table entry. In contrast, by supporting the fusion of regions represented in the RGT so that a single ownership entry can represent the attributes of a larger region, more efficient level 3 lookups can be achieved in the TLB.

[0371] Page fusion allows a single RGTE to represent a group of contiguous pages for a more efficient level 3 RPU (TLB). Fused pages can restore TLB performance with larger pages on the MMU. Without fusion, the TLB can only hold references to 4K mappings even with larger MMU mappings.

[0372] Use the following commands to fuse groups of pages together and to split (unfuse) them:

[0373] Region fusion command: RMU.Granule.Fuse(addr,level)

[0374] Region splitting command: RMU.Granule.Shatter(addr,level)

[0375] Merge and split can be applied recursively to create and destroy larger fused groups. The fused group size is defined to match the TT larger region size.

[0376] Valid pages can be merged. Invalid, zero-commit (patrol-clear commit), and RMU_private pages cannot be merged.

[0377] Pages to be fused are required to be contiguous and address aligned to the new fusion group size. A fusion command will be rejected unless the pages to be fused are first claimed and cleared with the same type, attributes, and permissions.

[0378] In addition, if the pages to be fused are not continuous in the mapping address and the physical address PA, the region fusion command is rejected:

[0379] EL0 pages require contiguous VA and PA (large TT mappings may also require contiguous IPA)

[0380] EL1 pages require consecutive IPA and PA

[0381] EL2 and EL3 pages require continuous PA

[0382] All pages must physically exist to be fused. This is enforced by requiring the corresponding pages to be in a valid state in the RGT. Fused pages cannot be exported (page exported), they need to be split first.

[0383] RMU commands operating on a single page return an error if a fused page is provided as input. The fused page will first need to be split and the command retried (otherwise the state of the pages within the fused group may be different).

[0384] Fusion is a performance optimization that can be performed by the software that owns the pages, or by higher-level software in coordination with the management of large page tables.

[0385] Failure to fuse pages affects TLB performance but does not affect program logic correctness or security.

[0386] Fusion level (fusion group size)

[0387] The fuse group state is stored within the RGTE as a "Fuse Level". The minimum fuse level 0 is the default level when the page is not part of a fuse group. Additional fuse levels may be defined corresponding to certain larger fuse groups, e.g. level 1 = 64K, level 2 = 2MB. It may be useful to choose these sizes depending on the size of the area covered by the various levels of the translation table hierarchy.

[0388] Therefore, to fuse 16×4K pages into a single 64K fused group, software can call RMU.Granule.Fuse(addr,FuseLevel=1). After successfully completing from the 64K aligned address (addr), the 16 physically consecutive pages increase their RGTE.FuseLevel values ​​to FuseLevel1. Similarly, RMU.Granule.Shatter(addr) reduces the fusion level of the 16 pages back to FuseLevel0.

[0389] To create a 2MB fused group, first all 512 individual 4K pages are fused into a 64K fused group. Then these 32 groups are fused again into a 2MB group.

[0390] When fusing to a higher level, only the fuse level of the first RGTE of each lower group is updated to the new fuse level. Thus, RGTEs aligned to a 64K address will have RGTE.FuseLevel=FuseLevel2. Other RGTEs not aligned to 64K will have RGTE.FuseLevel=FuseLevel1. This limited update reduces the amount of RGTEs that need to be modified for each Fuse / Shatter command.

[0391] In a linear RGT, updating the fused level at a larger page-block aligned address can be viewed as flattening the two-dimensional tree into a one-dimensional table.

[0392] For Fig.24In the level 3 RMU lookup shown, the MMU 26, when accessing the RGT 128 to identify the attributes of a given memory region, can directly access the RGTE of this region and check whether its fusion level is greater than zero, and if so, walk up the aligned region group addresses to find the actual size of the region fusion group associated with the desired memory region, and thereby find the RGTE at one of the aligned addresses that specifies the combined attributes of this fusion group. If the fusion level is zero, the attributes in the RGTE of the desired region can be simply returned. Alternatively, upon receiving a translation table traversal that results in a larger mapping, the MMU 26 can directly try the aligned RGTE for the fusion group size corresponding to the larger mapping to see if subsequent pages are fused, and if not, walk down the aligned addresses to find a match and store the best result in the TLB.

[0393] After the RMU.Granule.Shatter command completes, the RMU issues a TLB invalidate command specifying the aligned physical address and size of the fused group under consideration. This maintains safety by ensuring that if the attributes of each of them associated with a previously fused group are subsequently updated, then stale values ​​previously shared by all regions of the fused group cannot still be accessed from the TLB. On the other hand, TLB invalidation for RMU.Granule.Fuse is desirable to gain performance gains, but is not necessary for safety.

[0394] Fig.42 The concept of fusion level (fusion group size) is shown. Fig.42 As shown on the left side of , initially when a region (region group) is assigned to a particular owner, the corresponding ownership entries (RGTEs) of the ownership table (RGT) 128 can each be defined as having a fusion level of 0, which is the default level when the page is not part of any fusion group. Fusion level 0 can be viewed as indicating a minimum fusion group size, corresponding to the size of a single memory region represented by one RGTE, e.g., 4kB. Therefore, if a memory access is made to one of these regions, the TLB caches information from the single RGTE corresponding to the accessed region, regardless of any entries associated with other regions in this portion of the address space. For example, each region can have a different owner field and / or different ownership (visibility) attributes defined for this region.

[0395] like Fig.42 As shown in the middle part of FIG, the process then issues a regional fusion command to the RMU, specifying the target fusion level 1 and the identifier N L1 The target address of block 900 of a continuous 4K region. L1 It can be implicit. For example, the architecture can define the number of regions to be fused via the level 1 region fusion command so that this does not need to be explicitly indicated in the command. In this example, NL1 =16. RMU 20 verifies whether the command can be operated. For example, RMU 20 checks whether each region of block 900 to be fused has the same owner domain, the same visibility attribute, is in a valid state, and has a continuous mapping address. In addition, RMU 20 checks whether the fusion level specified in each RGTE associated with block 900 meets the expected fusion level, which is one level lower than the target fusion level - that is, fusion level = 0 is checked for the 16 RGTEs associated with block 900.

[0396] If the region fusion command passes the verification, then N L1 The contiguous regions are fused to form a single fused group of 64KB, and the RMU increments the fusion level specified by each fused region to 1. This means that when a memory access is made to any region within the 64KB fused group, the RGTE ( Fig.42 The shaded part in the figure) reads the attribute, namely the RGTE of the first region associated with the fusion group.

[0397] Similar level 1 region fusion commands can be issued to fuse other 64KB groups at different addresses. Therefore, within each 64KB fusion group, each RGTE specifies fusion level 1, and the ownership attributes of all 16 memory regions of the same fusion group are indicated by the predetermined RGTE of the group, such as Fig.42 In this example, the predetermined entry is the first entry associated with the first region of the fusion group.

[0398] Then a Level 2 Region Fusion command may be issued specifying a target fusion level = 2, which triggers N L2 The fusion of level 1 fusion groups to form a larger level 2 fusion group. In addition, N L2 It can be implicit in the architecture, for example in this example N L2 =32, so that the level 2 fused group corresponds to 2MB. In addition, the RMU verifies that the attributes of each level 1 fused group are the same (only checking the N at the alignment address of each level 1 fused group). L2 shadow RGTEs), the desired fusion level of each of these RGTEs is 1 (one less than the target fusion level), and these RGTEs define consecutive mapping addresses (64K offsets in this example).

[0399] If the Level 2 Region Merge command is verified, the RMU updates the table to indicate N L2 *N L1 All attributes of a region are indicated by a single RGTE, which is Fig.42 The shaded entry in the right-hand diagram of is located at an address aligned with the start of the 2MB level 2 fusion group.

[0400] Note that when executing a zone group merge command that specifies a target merge level of 2 or higher, not all RGTEs associated with the merged region have their merge levels updated. Instead, only the merge level of the first RGTE in each smaller merged group (e.g., level 1) is increased. Fig.42 In the example, Fig.42 The fusion level of the 32 RGTEs shown shaded in the middle portion of the is increased to 2, but the remaining RGTEs in each of those level 1 fusion groups still indicate a fusion level of 1. By only updating the first RGTE of each lower fusion group size when the fusion level is increased, this avoids the need to make as many memory accesses, thereby improving performance. When the MMU accesses the regions associated with one of the non-incremental RGTEs, the actual fusion level associated with these regions can be determined from the RGTEs associated with the alignment addresses that are aligned to the boundaries corresponding to the larger fusion region sizes. Therefore, when the MMU accesses data from the domain region group table (ownership table), the MMU may need to traverse up and down to access different alignment addresses corresponding to different possible fusion group sizes (fusion levels) in order to find the actual fusion group size and attributes associated with a given region. After fusion, a single TLB entry can store information that can be looked up when accessing any fusion region group.

[0401] like Fig.42 As shown, corresponding level 2 and level 1 region splitting commands may also be provided to reverse the effects of corresponding level 2 and level 1 region merging commands. Fig.42 As shown at the bottom of , a single global split command can break up any size fused group into separate 4KB regions without the need to selectively reverse each level of fusion one step at a time. However, the reduced form of the region split command (in Fig.42 1 or 2) can be implemented more efficiently in the microarchitecture.

[0402] Fig.43 is a flow chart illustrating a method for processing an issued region fusion command. At step 920, the RMU 20 receives a region fusion command. The region fusion command may be issued by any software process, including processes outside the owner domain of the fusion region. The region fusion command specifies an address and a target fusion level (FL) indicating the size of the fusion group to be formed in response to the region fusion command. In this example, the target fusion level FL is explicitly indicated in the command, but other examples may implicitly identify the target fusion level FL, such as by instead specifying the desired current fusion level, i.e., FL-1.

[0403] At step 922, the RMU 20 lo...

Claims

1. A device for data processing, comprising: processing circuitry that performs data processing in response to one or more software processes; a domain management unit that maintains an ownership table that specifies a plurality of ownership entries, each ownership entry defining an ownership attribute for a corresponding region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the corresponding region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one of the software processes, and the owner domain has the right to exclude other domains from accessing data stored in the corresponding region; and a memory access circuit that controls access to the memory based on the ownership table; wherein: the domain management unit performs a region merging operation in response to a region merging command specifying a merging target address, the merging target address indicating a plurality of contiguous regions of the memory to be fused into a fused group of regions, the region merging operation updating the ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group; and The domain management unit is configured to allow the region merging operation to be performed in response to a region merging command triggered by a domain other than an owner domain specified for the plurality of continuous regions in the ownership table.

2. The device according to claim 1, wherein: The memory access circuitry is configured to control access to the memory based on both the ownership table and at least one translation table that provides address translation data for translating virtual addresses into physical addresses.

3. The apparatus of claim 2, comprising at least one translation lookaside buffer for caching information from the address translation table and the ownership table.

4. The device according to any one of claims 1 to 3, wherein: In response to the region fusion command, the domain management unit is configured to: determine whether the region fusion command passes at least one verification check, reject the region fusion command when the at least one verification check fails, and perform the region fusion operation when the at least one verification check passes.

5. The device according to claim 4, wherein: The domain management unit is configured to determine that the at least one authentication check fails when different ownership attributes are specified in the ownership entry for any two areas of the plurality of contiguous areas.

6. The device according to claim 4, wherein: Each ownership entry corresponds to a physically addressable region of the memory and specifies a mapping address, the mapping address being an address to which a physical address identifying the corresponding region is mapped when an ownership attribute of the corresponding region is set in the ownership table; and The at least one validation check fails when ownership entries of the plurality of contiguous regions specify a non-contiguous group of mapped addresses.

7. The device according to claim 4, wherein: The ownership attribute of each ownership entry specifies one of a plurality of region states associated with the corresponding memory region, the region states comprising at least an invalid state in which the memory region is permitted to be reallocated to a different owner domain and a valid state in which the memory region is allocated to a given owner domain and is prevented from being reallocated to a different owner domain; and The at least one validation check fails when an ownership entry for any region of the plurality of contiguous regions specifies that the region is in a state other than the valid state.

8. The device according to any one of claims 1 to 3, wherein: The ownership table includes one or more linear tables.

9. The device according to any one of claims 1 to 3, wherein: In response to a region fusion command in the form of a group size increment, the region fusion operation includes updating the ownership table to indicate that multiple consecutive regions are to be fused into a fusion group having a target fusion group size, wherein the region fusion command in the form of a group size increment specifies an indication of the target fusion group size, each of the multiple consecutive regions is associated with a fusion group having an expected current fusion group size, wherein the expected current fusion group size is the next smallest fusion group size among multiple fusion group sizes supported by the domain management unit compared to the target fusion group size.

10. The device according to claim 9, wherein: A minimum fusion group size among the plurality of fusion group sizes corresponds to the predetermined size of a single region.

11. The device according to claim 9, wherein: The domain management unit is configured to reject the region merge command in the group size increment form when the ownership table indicates that at least one region of the plurality of contiguous regions is associated with a current fused group size other than the next smallest fused group size compared to the target fused group size.

12. The device according to claim 9, wherein: In response to the region merge command in the group size increment form, the region merge operation includes updating a subset of ownership entries associated with the plurality of contiguous regions, the subset selected according to the indication of the target merge group size.

13. The device according to claim 12, wherein: When the expected current fused group size is the minimum fused group size among the plurality of fused group sizes, the subset of ownership entries includes ownership entries associated with all of the plurality of contiguous regions to be fused into the fused group having the target fused group size; and When the expected current fused group size includes a fused group size other than the minimum fused group size, the subset of ownership entries includes ownership entries associated with less than all of the plurality of contiguous regions to be fused into the fused group.

14. The device according to any one of claims 12 and 13, wherein: The subset includes ownership entries associated with regions whose addresses are offset by an amount corresponding to the expected current fused group size.

15. The device according to any one of claims 12 and 13, wherein: No matter which fused group size is the target fused group size, the subset includes the same number of ownership entries.

16. The device according to any one of claims 1 to 3, wherein: The domain management unit performs a region split operation in response to a region split command that specifies a split target address, wherein the split target address indicates a fusion group of regions to be split into subsets consisting of one or more regions, and the region split operation updates the ownership table to indicate that ownership attributes of corresponding subsets of regions are represented by different ownership entries in the ownership table.

17. The apparatus of claim 16, comprising a translation lookaside buffer for caching information from the ownership table; wherein: The region split operation includes triggering the translation lookaside buffer to invalidate information associated with a fused group of the region indicated by the split target address.

18. The device according to any one of claims 1 to 3, wherein: During the region merging operation, the domain management unit is configured to lock ownership entries to be updated in the region merging operation to prevent the ownership entries from being updated by other processes until the region merging operation is completed.

19. The device according to any one of claims 1 to 3, wherein: The owner realm of a given memory region has the authority to prevent processes executing at a higher privilege level than the owner realm from accessing the given memory region.

20. The device according to any one of claims 1 to 3, wherein: The domain management unit includes one of the following items: Hardware units; and Processing circuitry that executes domain management software.

21. A device for data processing, comprising: processing circuitry that performs data processing in response to one or more software processes; a domain management unit that maintains an ownership table that specifies a plurality of ownership entries, each ownership entry defining an ownership attribute for a corresponding region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the corresponding region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one of the software processes, and the owner domain has the right to exclude other domains from accessing data stored in the corresponding region; and a memory access circuit that controls access to the memory based on the ownership table; wherein: the domain management unit performs a region merging operation in response to a region merging command specifying a merging target address, the merging target address indicating a plurality of contiguous regions of the memory to be fused into a fused group of regions, the region merging operation updating the ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group; and The domain management unit is configured to reject a command specifying an operation to be performed on the single target region of memory of a predetermined size when the single target region is part of a fused group of regions.

22. The device according to claim 21, wherein The owner realm of a given memory region has the authority to prevent processes executing at a higher privilege level than the owner realm from accessing the given memory region.

23. The device according to claim 21, wherein The domain management unit includes one of the following items: Hardware units; and Processing circuitry that executes domain management software.

24. A method for data processing, comprising: maintaining an ownership table specifying a plurality of ownership entries, each ownership entry defining an ownership attribute for a respective region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the respective region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one software process processed by a processing circuit, and the owner domain has the right to exclude other domains from accessing data stored in the respective region; controlling access to the memory based on the ownership table; and performing a region merge operation in response to a region merge command specifying a merge target address indicating a plurality of contiguous regions of the memory to be merged into a fused group of regions, the region merge operation updating the ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group; and The region merging operation is allowed to be performed in response to a region merging command triggered by a domain other than an owner domain specified for the plurality of continuous regions in the ownership table.

25. A storage medium storing a computer program for controlling a host data processing device to simulate processing of one or more software processes on a target data processing device, the computer program comprising: processing program logic that controls the host data processing device to perform data processing in response to object code representing the one or more software processes; domain manager logic that maintains an ownership table that specifies a plurality of ownership entries, each ownership entry defining an ownership attribute for a respective region of a predetermined size of a memory, the ownership attribute specifying an owner domain of the respective region from a plurality of domains, wherein each domain corresponds to at least a portion of at least one of the software processes, and the owner domain has authority to exclude other domains from accessing data stored in the respective region; and a memory access program logic that controls access to the memory based on the ownership table; wherein: the domain manager logic performing a region merge operation in response to a region merge command specifying a merge target address, the merge target address indicating a plurality of contiguous regions of the memory to be merged into a fused group of regions, the region merge operation updating the ownership table to indicate that ownership attributes of each region in the fused group of regions are represented by a single ownership entry corresponding to a predetermined region of the fused group; and The domain manager logic is configured to enable the region merge operation to be performed in response to a region merge command triggered by a domain other than an owner domain specified in the ownership table for the plurality of contiguous regions.

Images