Input / output memory management unit

Abstract

An IOMMU comprises address translation circuitry to obtain a translation result in response to a given translation request specifying a target address and a security state identifier. The translation result depends on address translation information located using a selected set of MMU configuration information selected from among sets of MMU configuration information respectively associated with different security states. When the security state identifier of the given translation request specifies a less secure security state and MMU configuration selection circuitry determines, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, that the given translation request should be treated as the redirected translation request, the MMU configuration selection circuitry selects a more secure set of MMU configuration information associated with a more secure security state as the selected set of MMU configuration information.

Description

[0001] INPUT / OUTPUT MEMORY MANAGEMENT UNIT

[0002] The present technique relates to the field of input / output memory management units (lOMMUs).

[0003] A data processing apparatus may have a memory management unit (MMU) for managing accesses to memory. The MMU may be responsible fortranslating a virtual address specified for a memory access into a physical address which directly identifies a location to access in memory. The MMU may also control whether a device is allowed to access the requested address based on access permissions set for regions of the address space. A processing element capable of instruction execution, such as a central processing unit (CPU), may have its own MMU for managing access to memory in response to memory access transactions issued by the processing element. However, a processing system may also have input / output (I / O) devices which are provided with direct memory access to the memory system shared with one or more processing elements. Such I / O devices do not typically have their own MMU. Nevertheless, supporting address translation and other memory management functions, such as access permissions checking, for input / output memory access transactions (e.g. read / write transactions) issued by I / O devices can be helpful to avoid exposing physical memory directly to devices. This can be beneficial both for supporting virtual memory (allowing fragmentation of the memory used by a device across discontiguous physical memory regions), and for security reasons (allowing access permissions checks to be imposed so that devices cannot compromise data in memory not allocated for the device). Hence, it can be useful to provide an input / output memory management unit (IOMMU), also referred to as a system memory management unit (SMMU), which provides memory management functions including address translation for I / O memory access transactions originating from I / O devices.

[0004] At least some examples of the present technique provide an input / output memory management unit (IOMMU) comprising: address translation circuitry configured to obtain a translation result in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request, wherein the translation result depends on address translation information located using a selected set of memory management unit (MMU) configuration information selected for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; and MMU configuration selection circuitry configured to control selection of the selected set of MMU configuration information; in which: when the security state identifier of the given translation request specifies a less secure security state, the MMU configuration selection circuitry is configured to: determine, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration informationassociated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; and in response to determining that the given translation request should be treated as the redirected translation request, select the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

[0005] At least some examples of the present technique provide a system comprising: the IOMMU described above, implemented in at least one packaged chip; at least one system component; and a board, wherein the at least one packaged chip and the at least one system component are assembled on the board.

[0006] At least some examples of the present technique provide a chip-containing product comprising the system described above, wherein the system is assembled on a further board with at least one other product component.

[0007] At least some examples of the present technique provide computer-readable code for fabrication of an IOMMU as described above. The computer-readable code can be stored on a computer-readable storage medium. The storage medium may be a non-transitory storage medium.

[0008] At least some examples of the present technique provide a method for processing a given translation request received by an input / output memory management unit (IOMMU), the method comprising: in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request: selecting a selected set of memory management unit (MMU) configuration information for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; and controlling address translation circuitry to obtain a translation result for the given translation request depending on address translation information located using the selected set of MMU configuration information; in which: the selecting comprises, in response to determining that the security state identifier of the given translation request specifies a less secure security state: determining, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; and in response to determining that the given translation request should be treated as the redirected translation request, selecting the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation circuitry to obtain the translation result for the given translation requestdepending on address translation information located using the more secure set of MMU configuration information.

[0009] At least some examples provide a computer program comprising instructions which, when executed on a host data processing apparatus, control the host data processing apparatus to simulate an input / output memory management unit (IOMMU), the computer program comprising: address translation program logic configured to obtain a translation result in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request, wherein the translation result depends on address translation information located using a selected set of memory management unit (MMU) configuration information selected for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; and MMU configuration selection program logic configured to control selection of the selected set of MMU configuration information; in which: when the security state identifier of the given translation request specifies a less secure security state, the MMU configuration selection program logic is configured to: determine, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; and in response to determining that the given translation request should be treated as the redirected translation request, select the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation program logic to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

[0010] At least some examples of the present technique provide a storage medium storing the computer program described above.

[0011] Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

[0012] Figure 1 illustrates an example of a data processing system comprising an IOMMU; Figure 2 illustrates an example of a processor supporting security states each associated with a respective physical address space;

[0013] Figure 3 illustrates an example of address translation into respective physical address spaces;

[0014] Figure 4 illustrates an example of a point of physical aliasing;Figure 5 illustrates an example of an IOMMU comprising address translation circuitry and MMU configuration selection circuitry;

[0015] Figure 6 illustrates a method for processing a given translation request using the IOMMU; Figure 7 illustrates redirection of a given translation request specifying a security state identifier identifying a less secure security state to cause address translation to be controlled based on a more secure set of MMU configuration information associated with a more secure security state;

[0016] Figure 8 illustrates steps for selecting MMU configuration information;

[0017] Figure 9 illustrates steps for performing address translation based on a selected set of MMU configuration information;

[0018] Figure 10 illustrates a specific example in which a given set of MMU configuration information comprises a stream table data structure accessed using a base address obtained from a stream table base address register;

[0019] Figure 11 illustrates an example of entries of a translation lookaside buffer (TLB);

[0020] Figure 12 illustrates steps for processing a given translation request;

[0021] Figure 13 illustrates an example of steps for TLB lookup;

[0022] Figure 14 illustrates an example of steps for stream table lookup;

[0023] Figure 15 illustrates an example of steps for performing a page table walk operation; Figure 16 illustrates an example of steps for allocating an entry into the TLB;

[0024] Figure 17 illustrates a system and a chip-containing product; and

[0025] Figure 18 illustrates a simulation example.

[0026] An input / output memory management unit (IOMMU) comprises address translation circuitry configured to obtain a translation result in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request. The translation result depends on address translation information located using a selected set of memory management unit (MMU) configuration information. The selected set of MMU configuration information is selected for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states. MMU configuration selection circuitry is provided to control selection of the selected set of MMU configuration information.

[0027] Hence, two or more sets of MMU configuration information are supported, each associated with a respective security state. The MMU configuration information can identify various parameters influencing how address translation is performed, but at least specifies information used to locate the address translation information for obtaining the translation result for the target address specified by the given translation request (e.g. each set of MMU configuration information may specify a base address of a data structure used to locate the address translation information). Supporting multiple alternate MMU configurations associated with different security states can behelpful to enable assignment of an I / O device to a trusted execution environment for which a different set of MMU configuration information is desired compared to the MMU configuration to be used for untrusted translation requests not associated with that trusted execution environment.

[0028] Hence, when a given translation request is received, MMU configuration selection circuitry controls selection of a selected set of MMU configuration information. In a typical IOMMU supporting multiple security states, the selected set of MMU configuration information would simply be the set of MMU configuration information that is associated with the security state specified by the security state identifier of the given translation request. However, the inventors recognised that, while for most use cases this approach can be acceptable, there can be some use cases where it can cause a significant amount of additional overhead for software developers writing software for a system comprising the IOMMU. For example, while a given I / O device is undergoing a device assignment process for assigning the given I / O device to a trusted execution environment, the given I / O device may still be considered untrusted (so will generate translation requests with the security state identifier specifying a less secure security state) but nevertheless may need to access some memory system resources which it will later also access once the device assignment process is complete and the device is now considered trusted (and at that point the device will generate translation requests specifying a more secure security state which target the same memory system resources that were previously accessed in the less secure security state). If each security state has its translation requests translated based on different MMU configuration, then this may require a software developer to configure two separate sets of translation table structures for use by the I / O device to access the same resources at different points in the device’s life cycle. For example, in addition to the main set of translation table structures used once the device is fully operational in the more secure security state, the software developer may establish a shadow set of translation table structures (e.g. page tables) used solely for the limited time period when the I / O device is undergoing the device assignment process and so cannot yet generate more secure translation requests with the security state identifier specifying the more secure security state. This duplication of effort in maintaining multiple sets of page tables for accessing the same resources is wasteful for both memory utilisation and software development effort.

[0029] In contrast, in the examples discussed below, when the security state identifier of the given translation request specifies a less secure security state, the MMU configuration selection circuitry is configured to: determine, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state. In response to determining that the given translation request should be treated as the redirected translation request, the MMUconfiguration selection circuitry selects the more secure set of MMU configuration information as the selected set of MMU configuration information, to control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

[0030] With this approach, if the less secure set of MMU configuration information has been set to indicate that the given translation request should be treated as a redirected translation request, it becomes possible for the more secure set of MMU configuration information to be used to control address translation for the given translation request, even though the given translation request specifies a security state identifier indicating the less secure security state. This might seem counter-intuitive, as one might think that the security guarantees associated with the provision of different sets of MMU configuration information associated with the respective security states might be broken if a more secure set of MMU configuration information is used to control address translation for a less secure translation request associated with the less secure security state. However, the inventors recognised that such security concerns can be overcome, and that by allowing (in a controlled manner controlled based on a redirection control provided by the less secure set of MMU configuration information) some reuse of the more secure set of MMU configuration information for controlling translation in response to less secure translation requests, this can greatly alleviate the significant software development overhead by reducing the need to maintain shadow sets of page tables for handling the limited phase of device lifetime when the device is undergoing a process for becoming trusted so that it can subsequently issue requests associated with the more secure security state. Hence, an IOMMU architecture supporting the “redirection” feature (by which a given translation request specifying the less secure security state can be treated a redirected translation request which should use the more secure set of MMU configuration information for translation control), can greatly simplify software development in comparison to alternative IOMMU architectures not supporting the redirection feature.

[0031] When the address translation circuitry obtains the translation result in response to a given translation request, the translation result could be obtained in different ways. For example, the translation result could be obtained from a translation lookaside buffer (TLB), and / or obtained based on a page table walk operation performed to obtain address translation information from page table structures stored in memory. Hence, while the address translation information is locatable using the more secure set of MMU configuration information, this does not necessarily imply that the address translation information would need to be located based on the more secure set of MMU configuration information each time a translation request is processed. At the time of processing the given translation request, it may be that the translation result indirectly depends on the address translation information located using the more secure set of MMU configuration information, in the sense that at a previous time the address translation information was located (e.g. by performing a page table walk operation) using the more secure set of MMU configurationinformation and cached in a TLB, and so when processing the given translation request a lookup may be performed in the TLB and if the required address translation information is already available in the TLB then it is not necessary to perform the page table walk operation again. Nevertheless, the address translation circuitry may have page table walk circuitry which is configured to use the MMU configuration information to locate address translation information required for translating a target address for a given translation request, with that page table walk circuitry being used on occasions when the address translation information is not already available in the TLB.

[0032] In some examples, in response to the given translation request when treated as the redirected translation request, the address translation circuitry is configured to determine whether to allow the given translation request to proceed based on the translation result obtained for the given translation request based on the address translation information located using the more secure set of MMU configuration information, depending on whether that translation result indicates that the target address corresponds to a more secure memory system resource prohibited from being accessed based on a request associated with the less secure security state. Hence, the address translation information located using a given set of MMU configuration information may indicate whether a memory system resource corresponding to a given address is a more secure memory system resource that cannot be accessed based on a request associated with the less secure security state. This information can be used to police whether the given translation request can proceed, so that the isolation of more secure memory system resources from access based on requests associated with the less secure security state can still be enforced even when the more secure set of MMU configuration information is being used to control address translation of a given translation request which is treated as a redirected translation request despite being associated with the less secure security state.

[0033] In response to the given translation request when treated as the redirected translation request, the address translation circuitry may abort processing of the given translation request in response to determining that the translation result obtained for the given translation request based on the address translation information located using the more secure set of MMU configuration information indicates that the target address corresponds to the more secure memory system resource. This prevents the more secure memory system resource becoming accessible in response to a less secure translation request, even when the more secure set of MMU configuration information is used to locate the address translation information for the less secure translation request being treated as the redirected translation request.

[0034] When the processing of the given translation request is aborted, this could mean simply ignoring the translation request without completing a remaining part of the translation process for the translation request. Alternatively, when the given translation request is aborted, a rejection response may be returned to the requester that issued the translation request. It is also possible to signal a fault or exception to a processor when the given translation request is aborted due tothe target address being detected as corresponding to a more secure memory system resource when the request is treated as a redirected translation request.

[0035] The translation result could indicate whether or not a given address corresponds to a more secure memory system resource in a number of ways. However, in some examples, the translation result comprises a physical address and physical address space (PAS) identifying information indicative of a selected physical address space (PAS) in which the physical address is to be accessed. The selected PAS is one of a plurality of physical address spaces (PASs) for which data assigned to a given physical address space is isolated from being observable by an observer prohibited from accessing that given physical address space. This approach providing isolation of respective PASs (typically each associated with a respective one of the security states) can be helpful for supporting trusted execution environments. In an implementation supporting multiple PASs, the address translation circuitry may determine that the target address corresponds to the more secure memory system resource in response to determining that the PAS identifying information of the translation result indicates that the selected PAS is a more secure PAS corresponding to the more secure security state. Note that the PAS identifying information could specify the selected PAS directly, or could specify the selected PAS indirectly (e.g. providing one or more bits of information which, possibly in combination with other information such as a current security state associated with the given translation request, can be used to deduce which PAS is the selected PAS).

[0036] In some examples, the MMU configuration selection circuitry is configured to determine, based on redirection consent information specified by the more secure set of MMU configuration information, whether use of the more secure set of MMU configuration information to control translation in response to the redirected translation request is permitted. The MMU configuration selection circuitry may abort processing of the given translation request in response to detecting that the redirection consent information of the more secure set of MMU configuration information specifies that use of the more secure set of MMU configuration information to control translation in response to the redirected translation request is not permitted.

[0037] Hence, redirection consent information can be specified by the more secure set of MMU configuration information, to police whether a given translation request can be treated as the redirected translation request. Although not essential, supporting the redirection consent information in the more secure set of MMU configuration information can be useful to support greater defence-in-depth against bugs which may accidentally cause the redirection control in the less secure set of MMU configuration to be set to treat a less secure translation request as a redirected translation request even though it was not intentional to enable the more secure MMU configuration to be used for controlling handling of the given translation request. Hence, the combination of the redirection control in the less secure set of MMU configuration information and the redirection consent information in the more secure set of MMU configuration information can offer greater control to restrict the reuse of the redirection functionality. Having two orthogonalcontrols to gate whether the redirection function is used makes errors much less likely, as the probability of simultaneous errors in both the redirection information and the redirection consent information is much lower than the probability of an error for the redirection information alone.

[0038] However, other examples may not support the redirection consent information, and in that case can simply use the redirection control in the less secure set of MMU configuration information to control whether to use the more secure set of MMU configuration information for handling translations in response to a less secure translation request.

[0039] In some examples, the IOMMU comprises a plurality of stream table base address registers each corresponding to a respective security state, and the MMU configuration selection circuitry is configured to access, using a stream table base address stored in a given stream table base address register corresponding to a given security state, the set of MMU configuration information associated with the given security state. Hence, by providing different base address registers corresponding to the respective security states, entirely different stream table structures stored in memory can be used to define orthogonal MMU configurations associated with the respective security states.

[0040] When the security state identifier of the given translation request specifies the less secure security state, the MMU configuration selection circuitry may perform a first stream table lookup to select, based on a requester identifier specified by the given translation request, a selected stream table entry of a less secure stream table accessed using a less secure stream table base address stored in a less secure stream table base address register corresponding to the less secure security state. Using the selected stream table entry selected in the first stream table lookup, the MMU configuration selection circuitry can obtain the redirection information specifying whether the given translation request should be treated as the redirected translation request. Hence, by providing a stream table which provides respective stream table entries associated with different requester identifiers, this allows translation requests from different requester devices (or associated with requester identifiers distinguishing multiple contexts associated with the same device) to select stream table entries offering different settings for the redirection control, so that some requesters can cause their less secure translation requests to be treated as redirected translation requests while other requesters do not make use of the redirection functionality. This allows more targeted control over whether, for a given translation request specifying a given requester identifier, the redirection feature discussed above should be used.

[0041] Note that there could be a number of ways of using the selected stream table entry to obtain the redirection information. In some examples, the selected stream table entry specifies the redirection information directly. In other examples, the selected stream table entry specifies a pointer which can be used to derive a memory address from which the redirection information can be obtained (either directly, or indirectly by following a trail of one or more further pointers). Also, in some implementations the first stream table lookup may be performed in memory, by accessing a memory location having an address derived from the less secure stream table baseaddress and the requester identifier. However, it is also possible for the IOMMU to include a stream table cache structure used to cache information previously obtained from memory in such stream table lookups, so in some cases the stream table lookup may be performed in the stream table cache and if a cache hit is detected, there may be no need to perform another access to the memory location from which the cached stream table information was obtained. Hence, there can be a number of ways in which the stream table lookup can be performed, and in which the selected stream table entry can be used to locate the redirection information.

[0042] In some examples, in response to determining that the given translation request should be treated as the redirected translation request, the MMU configuration selection circuitry may perform a further stream table lookup to select a further stream table entry of a more secure stream table accessed using more secure stream table base address stored in a more secure stream table base address register corresponding to the more secure security state, and control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information (e.g. a page table entry) located using the further stream table entry (again, that address translation information could be located either directly or indirectly using the further stream table entry, e.g. being located using a pointer stored in the further stream table entry itself, or by following a trail of multiple pointers starting from a pointer in the further stream table entry). Hence, the stream table lookup may be repeated for the redirected translation request, but on the second attempt of looking up the stream table, the more secure MMU configuration is used instead of the less secure MMU configuration.

[0043] The MMU configuration selection circuitry may perform the further stream table lookup to select the further stream table entry from the more secure stream table based on the same requester identifier used to select the selected stream table entry from the less secure stream table in the first stream table lookup. Hence, there is no need for multiple requester identifiers to be associated with the same translation request to handle the first and further stream table lookups respectively. The first and further stream table lookups can reuse the same requester identifier, but may look up different stream table structures corresponding to respective less secure and more secure stream table base addresses. This avoids needing to expand the size of buses used to convey the given translation request to the IOMMU and / or to re-design an I / O device that issues the given translation request, as the same requester identifier can be used across both the first stream table lookup and the further stream table lookup.

[0044] In some examples, the IOMMU comprises a translation lookaside buffer (TLB) comprising a plurality of TLB entries configured to cache address translation information, wherein a given TLB entry is tagged with a security state tag to be compared in a tag lookup with a security state identifier of a translation request to determine whether the translation request hits against the given TLB entry. To support TLB entries allocated in response to a redirected translation request being available for use in handling subsequent translations for translation requests from the same requester specifying the security state identifier indicating the more secure security state, it canbe helpful to implement TLB allocation such that, when a new TLB entry is allocated for address translation information obtained in response to the redirected translation request, the new TLB entry is tagged with the security state tag specifying the more secure security state even though the security state identifier for the given translation request that caused the TLB allocation specifies the less secure security state. Hence, the TLB allocation treats the redirected translation request as if it is a more secure request for the purposes of TLB allocation, so that subsequent requests specifying the more secure security state can hit against the same entry and do not need to perform an additional page table walk to locate the required translation information previously used when handling the redirected translation request. This approach can improve IOMMU throughput by reducing the frequency with which page table walks are required.

[0045] Similarly, when performing the tag lookup for the given translation request when treated as the redirected translation request, the TLB may treat the security state identifier of the given translation request as indicating the more secure security state for purposes of the tag lookup, even though the security state identifier for the given translation request specifies the less secure security state. Again, this helps reduce frequency of page table walks by enabling the redirected translation request to hit against a translation entry previously assigned to the TLB in response to a more secure translation request or another redirected translation request, hence improving IOMMU throughput and hence improving overall memory system performance.

[0046] In response to detecting a tag match for a particular TLB entry in the tag lookup performed for the redirected translation request when the address translation information cached in the particular TLB entry indicates that the target address corresponds to a more secure memory system resource prohibited from being accessed based on a request associated with the less secure security state (e.g. because the PAS identifying information identifies that the target address corresponds to the more secure PAS as described above), the TLB may prevent the redirected translation request proceeding based on the address translation information cached in the particular TLB entry. This prevents the redirected translation request hitting in the TLB becoming a route by which a less secure translation request can cause a memory access to be performed to a more secure memory system resource based on address translation information located using the more secure set of MMU configuration information.

[0047] There may be a number of techniques which could be used by the TLB to prevent the redirected translation request proceeding based on the address translation information cached in the particular TLB entry. In some examples, if a redirected translation request hits against an entry which corresponds to a more secure memory system resource, the processing of the given translation request being treated as the redirected translation request could be aborted, to prevent any translation result being returned in response to the (less secure) given translation request which could be used to enable a memory access to be performed to the more secure memory system resource.However, in some examples, the TLB could prevent the redirected translation request proceeding based on the address translation information cached in the particular TLB entry, simply by treating the tag lookup as missing in the TLB despite the tag match being detected. If the TLB lookup is treated as missing (despite the tag match being detected), then this can prompt a page table walk operation to be performed and it can then be detected during the page table walk operation whether the redirected translation request corresponds to a page table entry indicating a more secure memory system resource, and then the redirected translation request could be aborted at the point of performing the page table walk operation. Hence, it is not essential to implement circuitry for triggering an abort of the redirected translation request at the point of performing the TLB lookup. In some cases, circuit implementation of the IOMMU may be simpler if the abort control is associated with the page table walk processing. Nevertheless, by implementing a check to determine whether a redirected translation request causing a lookup in the TLB hits against an entry assigned for a more secure security state which specifies an access to a more secure memory system resource, so that a miss in the TLB is returned if the hit entry indicates that the target address corresponds to a more secure memory system resource, this maintains the security isolation guarantees for the more secure memory system resource to prevent it becoming accessible in response to a less secure translation request.

[0048] Specific examples are now set out with reference to the drawings.

[0049] Figure 1 schematically illustrates an example of an apparatus (e.g. a data processing system, integrated circuit or system on chip, or collection of interconnected chiplets) having at least one processor 4. In this example, only one processor 4 is shown, namely a CPU (Central Processing Unit). However, other examples could have more than one processor and could include types of processors other than a CPU (e.g. a GPU, Graphics Processing Unit). A given processor 4 may have at least one cache 5, and a memory management unit (MMU) 6 which functions as address translation circuitry for translating virtual addresses specified by instructions executed by the processor into physical addresses identifying locations within memory 10. The MMU 6 may have at least one TLB (translation lookaside buffer, not shown in Figure 1 for conciseness) for caching address translation information which depends on translation table data from translation table structures (also known as page table structures) stored in the memory system. The page table structures define address mappings between virtual and physical addresses and may also define memory access permissions which specify any restrictions on how the memory locations associated with particular addresses can be accessed (e.g. specifying whether the location is writable or read-only, whether data from that location is cacheable, etc.).

[0050] In addition to a processor 4 capable of instruction execution which has its own internal MMU, the system may also include one or more input / output (I / O) devices 12 which may not have an internal MMU but nevertheless have direct memory access (DMA) to the memory 10 used by the processor 4, and so for memory permission control and address translation functionality, such devices 12 may communicate with the rest of the system via an input / output memorymanagement unit (IOMMU) 14, also referred to as a system memory management unit (SMMLI). The IOMMU 14 includes address translation circuitry which controls address translation and applies memory permissions based on translation data defined in page table structures in memory (the page table structures being programmable by software executing on the CPU 4). Again, while not explicitly shown in Figure 1, the IOMMU 14 may have one or more TLBs for caching information derived from the page table structures. The I / O devices 12 which access memory via the IOMMU 14 can include cached devices which include an internal cache and uncached devices which do not have any cache. Many different types of devices 12 could be provided. For example, a given device 12 could be a display controller for controlling display of image frames on a display screen, a network controller for controlling input or output of data via a network, a storage controller for transferring data to or from external data storage, a user interface controller for controlling a user interface component such as a keyboard, mouse or touchpad, or many other types of devices.

[0051] The processor(s) 4 and devices 12, collectively referred to as memory access requesters, communicate with each other via an interconnect 8 which is responsible for routing transactions between the memory access requesters and memory 10. The interconnect 8 may also be responsible for managing coherency between data cached in respective caches of the system, which may include private caches 5 (private to a particular memory access requester) within a processor 4 or device 12, and one or more shared caches 9, such as a cache associated with the interconnect 8, which is shared between multiple memory access requesters 4, 12. It will be appreciated that Figure 1 is a simplified diagram and the system may have many other components not shown in Figure 1 for conciseness.

[0052] The MMU 6 of a given processor 4 has a set of MMU configuration registers for defining MMU configuration information associated with a current execution context for which instructions are executed by the processor 4. Those MMU configuration registers may specify information for controlling page table walk operations to obtain address translation information from a page table structure stored in the memory 10. For example, the MMU configuration information may include a base address of the page table structure, as well as information indicating table configuration, e.g. information used for controlling which portions of address bits are used to derive table index values for computing addresses of a page table entry to be accessed for a given address at a given level of the page table structure. Software executing on the processor 4 may switch the contents of the MMU configuration registers when there is a change of execution context at the CPU 4, so that the MMU configuration for the MMU 6 is directly associated with the current execution context being executed by the processor 4.

[0053] In contrast to the processor’s MMU 6 which generally handles address translations for a single context at a time (that context being the context associated with the instructions currently executed on the processor 4), the IOMMU 14 may be handling device-initiated translation requests for a number of different execution contexts simultaneously, as devices 12 maypreviously have been configured by the processor 4 to carry out functions on behalf of a number of different execution contexts. Therefore, the IOMMU 14 may have access to a stream table or other structure defining MMU configuration information associated with a number of different translation contexts (the MMU configuration information providing, at least, information for locating the address translation structures providing address mappings and memory access permissions). The IOMMU 14 may use a requester identifier specified by a translation request received from a given device 12 to select which entry to read from the stream table to obtain the MMU configuration information to be used for controlling page table walks in response to that translation request. The translation request from the device 12 could be a demand translation request indicating that an address translation should be performed and a read / write memory access should then be performed based on the translated memory address, or could be an advance translation request sent ahead of the time when the memory access is actually needed, to request that a translation is performed for a given virtual address and that the translation result (e.g. providing a translated address and associated access permissions or attributes) is returned to the device 12. The device 12 can cache the translation response locally and then subsequently use the translated address for a subsequent memory access at a later time (with this approach, the potentially long latency of the address translation can be incurred off the critical path, at an earlier time than the time when the corresponding memory access is actually needed, to reduce risk of critical memory accesses being delayed due to slow page table walks and / or contention for IOMMU bandwidth from multiple devices 12).

[0054] In addition to supporting respective stream table entries defining different MMU configuration information associated with respective requester identifiers relating to different address translation contexts, the IOMMU 14 also supports defining respective sets of MMU configuration information (e.g. multiple different stream table structures) associated with respective security states. This is useful to support use cases requiring confidential computing, where operations and data associated with a more trusted workload are to be isolated from being observable by a less trusted workload executing on the same hardware platform.

[0055] Figure 2 illustrates features of a processor 4 for supporting such confidential computing. The processor 4 includes instruction fetch circuitry 22 for fetching instructions from an instruction cache or memory 10, instruction decoding circuitry 24 for decoding the fetched instructions, processing circuitry 26 for performing data processing operations in response to the decoded instructions, and registers, including control registers 28 for storing control state information (although not shown in Figure 2, the registers may also include other types of registers such as general purpose registers used for general purpose instruction operands and results, a program counter register for tracking a current point of program flow, vector registers for storing vector operands comprising multiple independent data elements in one register, etc.). As mentioned above, the processor 4 includes a memory management unit (MMU) 6, comprising a translation lookaside buffer (TLB), for controlling access to memory by the processor 4 based on addresstranslation mappings and access permissions information defined in translation table structures stored in the memory 10. The TLB caches translation table information derived from the translation table structures (page table structures). The control registers 28 in this example are shown as including an indication of a current security state 30 and a current exception level 32, but can also include many other items of control state, including the MMU configuration information (e.g. translation table base address and configuration settings) mentioned earlier.

[0056] The processor 4 also includes requester-side access control circuitry (also known as granule protection check, GPC, circuitry) 20 for performing access control functions based on physical address space region assignment information defined in a granule protection table (GPT) which associates each physical address described by the table with a corresponding physical address space selected from among multiple architectural physical address spaces supported in the ISA supported by the processor 4.

[0057] As shown in Figure 3, the processor 4 supports multiple distinct architectural physical address spaces 44 which can be used to address the memory system. Data processing systems may support use of virtual memory, where address translation circuitry (e.g. the MMU 6) is provided to translate a virtual address specified by a memory access request from a virtual address space 40 into a physical address associated with a location in a memory system to be accessed. The mappings between virtual addresses and physical addresses are defined in one or more page table structures. The page table entries within the page table structures can also define some access permission information which may control whether a given software process executing on the processing circuitry is allowed to access a particular virtual address. For some translation regimes, the translation may involve two stages of address translation. If a two-stage translation is used then mapping from a virtual address space 40 to a physical address space 44 is via an intermediate address space 42 based on two separate sets of translation table structures, one for stage 1 (virtual-to-intermediate address translation) and one for stage 2 (intermediate-to-physical address translation). The intermediate address used to identify an address within the intermediate address space can be referred to as an “intermediate physical address” (I PA) since from the point of view of an operating system that controls the stage 1 page tables, the operating system considers the I PA to identify physical memory, and is unaware that its IPAs are being mapped in the stage 2 translations to physical addresses under control of the stage 2 page tables controlled by a hypervisor.

[0058] In some processing systems, all virtual addresses may be mapped by the address translation circuitry 6 onto a single physical address space which is used by the memory system to identify locations in memory to be accessed. In such a system, control overwhether a particular software process can access a particular address is provided solely based on the page table structures used to provide the virtual-to-physical address translation mappings. However, such page table structures may typically be defined by an operating system (for stage 1) and / or a hypervisor (for stage 2). If the operating system or the hypervisor is compromised then this maycause a security leak where sensitive information may become accessible to an attacker, as the attacker could then control the translation mappings to give access to physical memory that the attacker should not have access to.

[0059] Therefore, for some systems where there is a need for certain processes to execute securely in isolation from other processes, the system may support operation in a number of security states, and a number of distinct architectural physical address spaces 44 may be supported, where for at least some components of the memory system (e.g. caches 5, 9, interconnect 8, devices 12, IOMMU 14, etc.), memory access requests whose virtual addresses are translated into physical addresses in different architectural physical address spaces 44 are treated as if they were accessing completely separate addresses in memory, even if the physical addresses in the respective physical address spaces actually correspond to the same location in memory. By isolating accesses from different security states into respective distinct physical address spaces as viewed for some memory system components, this can provide a stronger security guarantee which does not rely on the page table permission information set by an operating system or hypervisor.

[0060] In this example, the processing circuitry 26 of the processor 4 can execute instructions in one of four security states: a non-secure security state, a secure security state, a realm security state and a root security state. The current security state indication 30 in the control registers 28 of the processor 4 (in some cases, in combination with the current exception level 32) designates which security state is currently being used. For example, the current security state can be the root security state when the current exception level is EL3 (a most privileged execution state) and can be one of the other three security states indicated by the current security state indication 30 when the current exception level is EL2, EL1 or ELO (EL2, EL1, ELO being execution states intended for execution of code with hypervisor-level privilege, operating-system-level privilege and application-level privilege respectively). Each of the four security states is associated with a corresponding architectural physical address space (PAS) 44. Hence, as shown in Figure 3 there are four architectural PASs: a non-secure PAS, secure PAS, realm PAS and root PAS.

[0061] The root security state is the most privileged (and most trusted) state, and is used for executing software which controls transitions to / from the other security states. The root state is able to have its virtual addresses translated from the virtual address space 40 to any of the four architectural physical address spaces 44 (note that although Figure 3 for conciseness shows only the options of selecting the realm PAS and root PAS for memory accesses from the root security state, it is also possible for memory accesses from the root security state to be translated into a physical address in the non-secure PAS or secure PAS). Information (NSE, NS) specified in the page table structures used to control the virtual address (VA) to physical address (PA) mapping is used to control which architectural PAS is selected for a given memory access request issued in the root security state (e.g. two bits of state, NSE, NS, specified in a given page table entry used to provide the root state VA to PA mapping may select between the four architectural PASs).The non-secure security state is the least trusted security state, and its memory accesses are translated by default into physical addresses in the non-secure PAS (potentially via two stages of address translation from virtual address space 40 to intermediate address space 42 and from intermediate address space to the non-secure physical address space 44). Instructions executed in the non-secure state are not allowed to cause access requests to be generated specifying physical addresses in the secure PAS, realm PAS and root PAS.

[0062] The secure security state and realm security state are orthogonal security states which are not able to access each other’s physical address spaces or the root physical address space, but which are able to select whether they access their own respective PAS (realm PAS for the realm state and secure PAS for the secure state) or whether they should access the non-secure PAS. Hence, information (NS) specified in the page table structures used to control address translation can be used to select whether a given memory access request has its address translated into the non-secure or secure PAS (when the request is issued from the secure security state) or into the non-secure or realm PAS (when the request is issued from the realm security state).

[0063] Note that while Figure 3 shows an example of an architecture supporting four security states each associated with a corresponding architectural PAS 44, it is not essential for all of these security states to be supported in a given system implementation, and some implementations may only support a subset of these security states and PASs 44 (e.g. some implementations may not support the Realm and / or Root security state).

[0064] As shown in Figures 1 and 4, the memory system may include a point of physical aliasing (PoPA) 16, which is a point within the memory system at which aliasing physical addresses from different architectural physical address spaces 44 which correspond to the same memory system resource are mapped to a single physical address uniquely identifying that memory system resource in a hardware physical address space 46 (shown in Figure 3) used by downstream memory system components (e.g. memory controllers and memory storage 10). Although more complicated mappings between aliasing addresses are possible (e.g. based on a mapping table tracking which address values in the architectural PASs 44 map to the same hardware physical address), it can be simplest if the addresses of the respective architectural PASs 44 which are considered to alias to the same location in the hardware physical address space 46 are those addresses which have the same physical address value (e.g. PA=X in the secure PAS and PA=X in the non-secure PAS are considered aliasing addresses which map to the same underlying hardware location corresponding to PA=X in the hardware physical address space 46). The location of the PoPA 16 could vary, e.g. it could be either upstream or downstream of a memory system interconnect 8 used to implement a coherency protocol for maintaining coherency of cached data held at respective processors 4. In the example of Figure 1, the PoPA 16 is downstream of the interconnect (and upstream of memory controllers corresponding to particular memory storage units) so that a shared system cache 9 (a cache shared between multipleprocessors 4 and / or devices 12) is prior to the PoPA, but other examples could provide the PoPA 16 upstream of the interconnect 8. In the example of Figure 4, at least one further shared cache 52 is provided downstream of the PoPA 16, but this is not essential and other examples may not have any further caches downstream of the PoPA 16.

[0065] Pre-PoPA memory system components, such as caches 5, 9 in the example of Figure 4 (or other cache-like structures such as a translation lookaside buffer within the MMU 6 of the processor 4 or the IOMMU 14), may treat aliasing physical addresses of different PASs 44 as if they correspond to different memory system resources, even if they ultimately map to the same memory system location in the system physical address space 46 used by underlying memory 10 beyond the PoPA 16. For example, the pre-PoPA caches 5, 9 may cache data, program code or address translation information for the aliasing physical addresses in separate entries, so that if the same memory system resource is requested to be accessed from different physical address spaces, then the accesses will cause separate cache or TLB entries to be allocated. Also, the pre-PoPA memory system component could include home node circuitry and / or a snoop filter of a coherency interconnect, which may separately track coherency states of data held at respective caching agents for the aliasing addresses in different architectural physical address spaces 44. Hence, the aliasing physical addresses are treated as separate addresses for the purpose of maintaining coherency even if they do actually correspond to the same underlying memory system resource.

[0066] As shown in Figure 4, one way to ensure that aliasing addresses from different architectural PASs 44 are treated as separate addresses can be to include a PAS identifier (PASID), which distinguishes which architectural PAS 44 is associated with a given memory access request, as additional address bits in the representation of physical addresses used to look up these pre-PoPA memory system components. Also, a PAS tag value 50 identifying the architectural PAS associated with a given cache entry may be specified in the given cache entry, and lookups of pre-PoPA caches may depend on a comparison of the PASID associated with a memory access request causing the cache lookup with a PAS tag 50 of a cache entry (derived from the GPT information associated with the corresponding physical address).

[0067] Regardless of the form of the pre-PoPA memory system component, it can be useful for such a PoPA memory system component to treat the aliasing physical addresses of the respective architectural address spaces 44 as if they correspond to different memory system resources, as this provides hardware-enforced isolation between the accesses issued to different physical address spaces so that information associated with one domain cannot be leaked to another domain by features such as cache timing side channels or side channels involving changes of coherency triggered by the coherency control circuitry.

[0068] In contrast, once requests pass beyond the PoPA 16, the aliasing addresses from the respective architectural PASs 44 are mapped to a single unique physical address in the hardware PAS 46. For example, if the aliasing physical addresses in the architectural PASs 44 are simplythose addresses having the same physical address value, the mapping to the hardware PAS (system PAS) 46 can be carried out simply by stopping using the PASID as additional address bits when looking up storage structures. As shown in Figure 4, for example, a post-PoPA cache 52 may, for its lookups, no longer use the PASID as part of the address lookup information and no longer tag its cache entries with a PASID 50, unlike the pre-PoPA caches 5, 9 which do use the PASID 50 for address lookups and cache tagging.

[0069] As shown in Figure 3, the hardware physical address space 86 may be partitioned to enable access to certain physical memory system locations only within certain architectural PASs. This could be based either on a static mapping (e.g. memory regions assigned to certain devices 12 could be statically reserved only to be accessible to a certain architectural PAS) for some regions of the system physical address space. However, for other regions a dynamic mapping can be defined in a granule protection table (GPT) looked up by the GPC circuitry 20 of a processor 4, IOMMU 14 or other memory access requester to determine whether, for a memory access request which has caused translation of the virtual address specified by the request into a particular target physical address in a target architectural PAS 44, that target physical address is allowed to be accessed from within that target architectural PAS 44. Each entry of the GPT may specify, for a given region of physical addresses, which of the architectural PASs is assigned to that physical address as being allowed to give access to that physical address (some examples may also support GPT settings which permit more than one, or even all, of the architectural PASs to enable access to the corresponding physical address in the system physical address space).

[0070] As shown in Figure 2, the GPC circuitry 20 may have one or more caches for caching portions of the GPT (or information derived from the GPT). While Figure 2 shows such GPT caches as separate from the corresponding TLBs in the MMU 6, in other examples a combined caching structure could cache information from both the page tables (translation table structures) used for address translation and the GPT used for the granule protection check. Similarly, while the MMU 6 and requester-side access control circuitry 20 are shown as separate in Figure 2, in other examples a single circuit unit could perform both functions.

[0071] The use of multiple architectural PASs 44 for addressing some pre-PoPA memory system components such as caches 5, 9 can be useful for improving security for some use cases, to enable software operating in the Realm or Secure state to be isolated (by a hardware-enforced mechanism) from untrusted software running in the Non-Secure state.

[0072] Returning to discussion of Figure 1, each memory access requester 4, 12 capable of issuing requests to access memory 10 has a corresponding instance of GPC circuitry 20 for checking, based on the PASID identifying a target PAS for the memory access and the GPT entry associated with the target physical address of the memory access, whether that physical address is allowed to be accessed within the specified PAS. For example, the processor 4 and the IOMMU 14 may each have a corresponding instance of GPC circuitry 20. It is possible to share a singleinstance of GPC circuitry 20 among two or more components. It will be appreciated that the particular locations of the GPC circuitry instances can vary depending on system design choice.

[0073] When software executing on the processor 4 executes within hardware-isolated security states (e.g. Realm state, Non-secure state), the software on the processor 4 may need to interact with various I / O devices 12, and so it can be useful to also assign a device 12 to a given security state and for the address translation requests sent by a device 12 to the IOMMU 14 to specify a security state identifier (SEC_SID) which distinguishes which security state is associated with a given translation request. In some examples, the security state identifier SEC_SID could distinguish between the same set of security states supported by the processor 4, e.g. Nonsecure, Secure, Realm and Root as discussed above. In other examples, the set of security states supported for a device 12 may be more limited than the set of security states supported for the processor 4, and there may be a mapping between the security states identified for a particular device and corresponding security states defined according to the processor architecture supported by the processor 4.

[0074] For example, a device 12 coupled to the host system via a PCIe interface may support a protocol such as the TEE Device Interface Security Protocol (TDISP) which provides an architecture for trusted I / O device virtualisation, supporting the assignment of a device to a given trusted execution environment (TEE) executed on the host system. In the TDISP protocol, a given transaction issued by the I / O device 12 to the host system specifies a “trusted” bit T which indicates whether the transaction is considered trusted or untrusted (e.g. T=1 denoting a trusted transaction and T=0 denoting an untrusted transaction). Another protocol that can be used to define untrusted and trusted transactions is the CXL-TSP (Compute Express Link -TEE Security Protocol). Hence, in some examples the SEC_SID for the IOMMU 14 may be derived from the trusted identifier T (or other information denoting whether an I / O device’s translation request is generated in a trusted or untrusted state of the device 12), and the mapping between the security states of the device 12 and the security states of the host system may be such that trusted transactions (e.g. with T=1) may map to the Realm security state and untrusted transactions (e.g. with T=0) may map to the Non-secure security state. In this example, is not essential for the IOMMU 14 to support the ability for I / O devices to issue transactions associated with the Root security state or Secure security state.

[0075] To ensure that the data and addresses accessed by trusted transactions are fully isolated from observation by untrusted processes, the IOMMU 14 may support multiple sets of MMU configuration information (e.g. multiple stream table structures) each associated with a respective security state. For example, when I / O transactions specify a SEC_SID specifying one of the Realm and Non-secure security states, there can be a Realm stream table structure used to provide MMU configuration information to be used for trusted I / O transactions associated with the Realm security state and a Non-secure stream table structure used to provide MMU configuration information to be used for untrusted I / O transactions associated with the Non-Secure securitystate. Each set of MMU configuration information may specify a respective translation table base address for locating the address translation tables used to provide address mappings and memory access attributes.

[0076] In examples where the SEC_SID distinguishes between the Realm security state and the Non-Secure security state, the Realm security state may be an example of a more secure security state and the Non-Secure security state an example of a less secure security state. The Realm security state is considered more secure than the Non-secure security state because the Realm security state has greater access rights (as shown in Figure 3, accesses from the Realm security state can access both Non-Secure and Realm PAS, while accesses from the Non-Secure security state cannot access the Realm PAS and can only access the Non-Secure PAS). However, it will be appreciated that the security model discussed with reference to Figure 3 is just one example and other examples may have a different security model, and so more generally the security states specified by SEC_SID may have security states with differing levels of security / trust and may in general comprise at least a more secure security state and a less secure security state, which do not necessarily need to be the Realm security state and Non-Secure security state used in this example.

[0077] Figure 5 illustrates an example of an IOMMU 14 comprising address translation circuitry 60 and MMU configuration selection circuitry 62.

[0078] The IOMMU 14 receives a given translation request specifying a virtual address (VA) to be translated, a security state identifier SEC_SID identifying a security state associated with the given translation request, and a requester identifier identifying the requester context associated with the request (e.g. different devices 12 and / or processing contexts handled by a given device 12 may be assigned different requester identifiers).

[0079] The address translation circuitry 16 includes TLB lookup circuitry 64 to perform a lookup of one or more TLBs 65 to identify whether the TLB 65 holds cached address translation information corresponding to the specified combination of VA, SEC_SID and Requester ID. If the relevant translation information is available in the TLBs 65, a translation response can be returned based on the matching TLB entry and there is no need to consult the MMU configuration selection circuitry 62 to identify MMU configuration information, and no need to perform a page table walk operation.

[0080] However, if a miss is detected in the TLBs 65, then the parameters of the given translation request are forwarded to the MMU configuration selection circuitry 62 to control selection of a selected set of MMU configuration information which is to be used to control address translation in response to the given translation request. The MMU configuration selection circuitry 62 includes a number of MMU configuration base address registers 68 corresponding to respective security states (e.g. a more secure MMU configuration base address register and a less secure MMU configuration base address register corresponding to more secure and less secure security states respectively). The combination of security state indicated by SEC_SID and the requesteridentifier can be used to locate MMU configuration information to be used to control subsequent page table walk operations (the security state influencing which base address register 68 is selected, and the requester identifier influencing which entry is selected from a table structure accessed via the address indicated in the selected base address register 68). An MMU configuration cache 69 may be provided to cache previously obtained MMU configuration information, so sometimes it may not be necessary to actually access the table structure in memory to locate the required MMU configuration, but if there is a miss in the MMU configuration cache 69 (or there is no such cache 69 at all), then the required MMU configuration information can be obtained from memory itself.

[0081] Hence, the MMU configuration selection circuitry 62 is responsible for controlling issuing of memory accesses for obtaining MMU configuration information. When such memory accesses are issued by the MMU configuration selection circuitry 62, the addresses specified by such accesses are derived from the base address selected from one of the MMU configuration base address registers 68 (as well as depending on other information such as the requester identifier and / or table pointers obtained from previous accesses to MMU configuration structures). For MMU configuration memory accesses associated with the more secure security state (e.g. Realm), those accesses specify as the selected PAS, for purposes of carrying out the GPC check using GPC circuitry 20, the PAS associated with that more secure security state (e.g. Realm PAS). Similarly, MMU configuration memory accesses associated with the less secure security state (e.g. Non-Secure) specify as the selected PAS the PAS associated with that less secure security state (e.g. Non-Secure PAS). This isolates the stream table accesses associated with the Realm security state from observation by Non-Secure observers.

[0082] Having selected and accessed the relevant set of MMU configuration information, the MMU configuration selection circuitry 62 provides the selected set of MMU configuration information to page table walk control circuitry 62 of the address translation circuitry, for use in controlling a page table walk operation for obtaining address translation information from page table structures stored in the memory 10. The selected set of MMU configuration information provides information for locating those page table structures, e.g. defining a base address of an initial level of page table structure from which further table pointers can be obtained. The MMU configuration information can also identify other table configuration information, e.g. information defining the page sizes, number of table levels, and other aspects of table structure that may influence the way in which the page table walk control circuitry 66 generates addresses for page table walk memory accesses to locate the required address translation information. The page table walk memory accesses generated by the page table walk control circuitry 66 may specify the PAS that is associated with the security state whose set of MMU configuration information was used to control address translation (hence, if MMU configuration information accessed based on the Realm MMU configuration base address register 68 is used to control the page table walk, the page table walk memory accesses may specify the Realm PAS, and if MMU configurationinformation accessed based on the Non-Secure MMU configuration base address register 68 is used to control the page table walk, the page table walk memory accesses may specify the Non-Secure PAS).

[0083] Once the required address translation information has been located in the page table walk operation, that address translation information provides an address mapping for translating the virtual address to a translated address (e.g. intermediate or physical address), and can also provide memory access attributes which control how a corresponding memory access can be performed. The page table walk control circuitry 66 returns a translation response providing the required translated address and access control attributes. That translation response could be used to control a memory access request to be issued to the memory system of the host apparatus 2 as a direct response to the given translation request, or alternatively the translation response could be returned to the device 12 that issued the given translation request, so that the device 12 can cache the translation response and use it at a subsequent time to request access to the host memory 10. As well as returning the translation response in response to the given translation request, TLB allocation circuitry 70 can allocate a new valid entry of the TLBs 65 for caching address translation information obtained from memory in the page table walk operation, so that subsequent translation requests can reuse the same address translation information from the TLB 65 and so can be processed faster based on a TLB hit. While extremely beneficial to performance, the TLBs 65 are not essential and other examples could omit the TLBs 65, TLB lookup 64 and TLB allocation circuitry 70.

[0084] Figure 6 shows steps for processing a given translation request. At step 100, a given translation request is received from a device 12, specifying at least a target address to be translated and a security state identifier indicating one of a set of security states. At step 102, in response to the given translation request, the MMU configuration selection circuitry 62 selects a set of MMU configuration information from among multiple sets of MMU configuration information associated with respective security states. At step 104, the address translation circuitry 60 is controlled, based on the selected set of MMU configuration information, to obtain a translation result for the given translation request which depends on address translation information located using the selected set of MMU configuration information.

[0085] Figure 7 schematically illustrates selection of the selected set of MMU configuration information using the MMU configuration selection circuitry 62. The MMU configuration selection circuitry 62 selects, based on the security state identifier, SEC_SID, associated with a given translation request, between a less secure set of MMU configuration information (Non-Secure MMU configuration information) and a more secure set of MMU configuration information (Realm MMU configuration information). The selected set of MMU configuration information specifies, at least, translation table locating information (e.g. a base address of a first-level translation table) 84, 86, with the two sets of MMU configuration information having different instances of such translation table locating information 84, 86 so that separate sets of translation tables can belocated for controlling address translation for the requests associated with the respective security states.

[0086] In a typical IOMMU supporting MMU configurations associated with respective security states, the selected set of MMU configuration information would simply be the set of MMU configuration information associated with the security state identified by the security state identifier SEC_SID of the translation request, with no ability to select a set of MMU configuration information associated with any security state other than the security state identified by SEC_SID.

[0087] However, the inventors recognised that, before a device 12 can be assigned to a Trusted Execution Environment (TEE) so as to be able generate translation requests specifying a SEC_SID corresponding to a more secure security state such as the Realm security state, the device 12 may have to undergo a trusted assignment procedure which may take some time to complete, but nevertheless the device 12 may still be issuing translation requests while that procedure is in progress. There may be some less secure memory system resources (accessed via the Non-Secure PAS) that may need to be accessed by the device 12 both during the early untrusted phase of the device’s lifecycle before the trusted assignment procedure is complete, and by the device during its subsequent trusted phase of its lifecycle after the trusted assignment procedure is complete. However, if the MMU configuration is entirely separate for both more secure and less secure security states (Realm and Non-Secure), this means software developers would be forced to maintain two sets of translation table structures in memory for handling the accesses to those less secure resources at the different phases of the device’s lifecycle, including both a main set of translation table structures accessed using the Realm MMU configuration information for the regular part of the device lifecycle, and a shadow set of translation table structures accessed using the Non-Secure MMU configuration information which are used temporarily during the early part of the device lifecycle when the TEE assignment procedures are not yet complete. This duplication of page table maintenance is onerous for software and makes software development more complex, as well as harming processing performance in occupying processing time maintaining the second set of page tables and reducing efficiency of memory and TLB utilisation since less capacity in memory 10 and TLBs 65 will be available for storing information other than the shadow page tables.

[0088] As shown in Figure 7, these issues can be mitigated by providing an IOMMU architecture which supports a redirection feature by which a less secure translation request specifying SEC_SID corresponding to a less secure security state can be treated as a redirected translation request for which address translation is controlled based on a more secure set of MMU configuration information associated with a more secure security state. For example, a Non-Secure translation request may have its translation controlled based on the Realm MMU configuration information. In this way, the Realm translation table structures can be reused to handle less-secure translations for a device 12 that has not yet completed its trusted assignmentprocedure, to avoid the added software overhead of maintaining a second set of shadow page tables for the Non-Secure state.

[0089] To support this redirection feature, the less secure set of MMU configuration information specifies a redirection indicator 80 which specifies whether a given request associated with the less secure (Non-Secure) security state should be treated as the redirected request to be controlled based on the more secure (Realm) MMU configuration information. This redirection indicator 80 could be specified separately per Requester identifier, so that less secure translation requests from some requester contexts can be treated as redirected translation requests which are to reuse the more secure MMU configuration information, while less secure translation requests from other requester contexts can be treated as regular less secure translation requests which are to be controlled based on the less secure MMU configuration information.

[0090] Optionally, the more secure set of MMU configuration information may also specify redirection consent information 88 indicating whether that redirection of the less secure translation request to use the more secure MMU configuration can be accepted. Again, that redirection consent information can be specified separately per requester identifier, so that a specific redirection consent or non-consent setting can be specified for each requester identifier. Although not essential, providing the redirection consent information 88 can provide defence in depth against coding errors, as it means that even if the redirection indicator 80 has erroneously been set to indicate a redirection is required, that error can be detected if the corresponding redirection consent indicator 88 in the more secure set of MMU configuration information has not been set to consent to the redirection (compared to the probability of an error occurring in just one of the redirection control parameters 80, 88 in the respective sets of MMU configuration information, it may be much less likely that simultaneous errors in both parameters 80, 88 would occur).

[0091] One might think that reuse of the Realm MMU configuration information to handle translations for a less secure transaction would cause a security risk, as the realm translation table structures may provide access to the Realm PAS which should be inaccessible to requests from a non-secure security state according to the security model described with reference to Figure 3. However, the inventors recognised that this can be mitigated against by introducing an additional check at the point when a translation response is returned for a redirected translation request, to prevent the translation response for the redirected translation request being used to enable access to memory if the translation response indicates that the specified target address corresponds to a more secure memory system resource assigned to the Realm PAS.

[0092] With this approach, the Realm translation table structures accessed based on the Realm MMU configuration can be used to provide access to Non-secure PAS resources in response to Non-Secure translation requests issued by a non-yet-trusted device 12, without needing the software developer to maintain a second set of shadow page tables accessible via the Non-Secure MMU configuration information, but the security guarantees provided by the security state model can still be respected because there is still no way that more-secure (Realm PAS) memorysystem resources can be accessed in response to the Non-Secure translation requests. Hence, an IOMMU architecture supporting the redirection functionality shown in Figure 7 provides a better balance between security and usability for software developers than an alternative IOMMU architecture not supporting the redirection functionality.

[0093] Figure 8 illustrates steps for selecting MMU configuration information at step 102 of Figure 6, in an approach supporting the redirection functionality. At step 110, the MMU configuration selection circuitry 62 determines which security state is specified by the security state identifier of the given translation request. If the security state identifier indicates a more secure security state (e.g. Realm), then at step 112, the MMU configuration selection circuitry 62 selects the more secure set of MMU configuration information as the selected set of MMU configuration information.

[0094] If the security state identifier indicates a less secure security state (e.g. Non-Secure), then at step 114, the MMU configuration selection circuitry 62 obtains redirection information from the less secure set of MMU configuration information. In some examples, the redirection information may be selected, based on the requester identifier, from a number of items of redirection information specified by the less secure set of MMU configuration information corresponding to respective requester identifiers. At step 116, the MMU configuration selection circuitry 62 determines whether the redirection information specifies that the given translation request should be treated as a redirected translation request. If the given translation request is not to be treated as a redirected translation request, then at step 118 the selected set of MMU configuration information is the less secure set of MMU configuration information (e.g. Non-Secure MMU configuration information).

[0095] If the redirection information specified by the less secure set of MMU configuration information specifies that the given translation request is to be treated as a redirected translation request, then a number of options are possible:

[0096] • in implementations not supporting the redirection consent information 88, the more secure set of MMU configuration information is selected as the selected set of MMU configuration information at step 112.

[0097] • in implementations supporting the redirection consent information 88, then at step 120 the MMU configuration selection circuitry 62 checks whether the redirection consent information 88 specified by the more secure set of MMU configuration information indicates that use of the more secure set of MMU configuration information to control translation in response to a redirected translation request is permitted, and if this is permitted then again at step 112 the more secure set of MMU configuration information is selected as the selected set of MMU configuration information. If the redirection consent information 88 indicates that use of the more secure set of MMU configuration information to control translation in response to a redirected translation request is not permitted, then at step 122 processing of the given translation request is aborted (e.g. a rejectionresponse is returned to the device 12 that requested the translation request), as this can be an indication that a coding error has occurred in setting the respective less secure and more secure sets of MMU configuration information.

[0098] Figure 9 illustrates steps for controlling address translation at step 104 of Figure 6. At step 130 the address translation circuitry 60 obtains a translation result for the given translation request depending on address translation information located based on the selected set of MMU configuration information selected at step 102. Step 130 could comprise either obtaining the translation result from the TLBs 65 (in which case, that translation result indirectly depends on the selected set of MMU configuration information, which was used at a previous time to obtain the corresponding address translation information from memory and allocate that information into the TLBs 65, so it is not necessary to actually access the MMU configuration information at the time of the TLB lookup), or could comprise performing a page table walk operation to locate the required address translation information for generating the translation result, with that address translation information being obtained from a translation structure located using selected set of MMU configuration information. Either way, at the time of address translation the translation result depends on address translation information located (either at this time, or at a previous time) based on the selected set of MMU configuration information.

[0099] At step 132, the address translation circuitry 60 determines whether the given translation request is being treated as a redirected translation request and the translation result indicates that the target address corresponds to a more secure memory system resource (e.g. a resource associated with the Realm PAS). If the given translation request is a redirected translation request and corresponds to a translation result specifying a more secure memory system resource, then at step 134 a fault is reported and the processing of the given translation request is aborted, since a less secure translation request should not be allowed to enable access to a more secure memory system resource.

[0100] Also, if any other cause of an address translation fault is detected based on the translation response at step 136 (e.g. a write request to a read-only region of memory is detected), then again a fault is reported and the processing of the given translation request is aborted at step 134. While steps 132 and 136 are shown sequentially in Figure 9, they could also be performed in parallel or in the opposite order.

[0101] If the given translation request is not a redirected translation request (less secure translation request being processed based on the more secure MMU configuration information) or the translation result obtained for the given translation request does not indicate that the target address corresponds to a more secure memory system resource, and no other cause of address translation fault has been detected, then at step 140 the address translation circuitry allows successful processing of the given translation request based on the translation result obtained at step 130 (e.g. a successful translation response is returned to the requesting device 12, or amemory access request is issued to the memory system based on the translated address and access attributes returned in the translation response).

[0102] Figure 10 illustrates a more detailed example illustrating an example structure for a set of MMU configuration information corresponding to a given security state. As mentioned earlier, the respective security states supported by the IOMMU (e.g. in some cases, the Realm and Non-Secure security states only, as the IOMMU may not support I / O devices issuing requests in the Secure or Root security states) may each have an associated stream table base address register 68 for pointing to the base of a corresponding stream table structure 141 stored in the memory system. Hence, each of the supported security states has a separate stream table structure 141, located via the corresponding base address register 68.

[0103] The stream table structure 141 for a given security state is organised as a set of stream table entries, and at least part of the requester identifier is used as a Stream identifier (StreamID) to select a corresponding stream table entry 142 from the stream table. In this example, while MMU configuration information used to control stage 2 translations from an intermediate address to a physical address is specified directly in the stream table entry 142 itself, MMU configuration information used to control stage 1 translations from a virtual address to an intermediate address is specified in a separate context descriptor 143 accessed using a stage 1 context pointer 144 stored in the stream table entry 142. That context descriptor 143 could be at an address directly indicated by the stage 1 context pointer 144, or could be accessed from an address computed based on the stage 1 context pointer 144 and a further part of the requester identifier used as a Sub-Stream identifier (SubStreamID) - use of sub-stream IDs to distinguish different stage 1 contexts corresponding to the same stage 2 context can be helpful to reduce the number of stream table entries 142 needed. However, it will be appreciated that use of a separate context descriptor 143 to define stage 1 context control information is not essential, and in other examples the information specified in the context descriptor 143 could instead be specified in the stream table entry 142 itself.

[0104] Hence, a given stream table entry 142 specifies:

[0105] a stage 1 context pointer 144 for locating the corresponding context descriptor 143; a stage 2 context identifier (e.g. virtual machine identifier, VMID) which can be used to differentiate different stage 2 translation contexts;

[0106] a stage 2 translation table base address (S2TTB) for accessing a first-level table of a set of stage 2 translation tables associated with this stage 2 translation contexts (a walk of the stage 2 translation tables performed for a given intermediate address may be performed to return a corresponding translated physical address and one or more stage- 2 translation attributes defined by the stage 2 translation table entry corresponding to that given intermediate address).

[0107] other configuration attributes associated with the stream ID used to select this stream table entry. These attributes include the redirection information 80 and (if supported) theredirection consent information 88 described earlier, for use in controlling redirection of less secure translation requests to reuse the more secure stream table for controlling address translation.

[0108] o The redirection information 80 is included in the stream table entry for the less secure (Non-Secure) stream table structure accessed via the less secure stream table base address register 68.

[0109] o If supported, the redirection consent information 88 is included in the stream table entry for the more secure (Realm) stream table structure accessed via the more secure stream table base address register 68.

[0110] o Since any given stream table structure only needs to specify one of the redirection information 80 and the redirection consent information 88, a common field of the stream table entry format could be reused for both pieces of information, with that field being interpreted as the redirection information 80 when accessing the less secure stream table and being interpreted as the redirection consent information 88 when accessing the more secure stream table. Alternatively, separate fields could be assigned to the redirection information 80 and redirection consent information 88 respectively.

[0111] On the other hand, a given context descriptor 143 specifies:

[0112] at least one stage 1 translation table base address (e.g. TTBO, TTB1) used to access a corresponding set of stage 1 translation tables used to translate virtual addresses into corresponding intermediate addresses. In some examples, more than one stage 1 translation table base address may be supported, e.g. with the table structure accessed via TTBO being used for translating virtual addresses with a most significant bit of 0 and with the table structure accessed via TTB1 being used for translating virtual addresses with a most significant bit of 1 (this can be helpful to enable separate sets of translation tables to be used for operations associated with application-level and kernel-level functionality respectively, which may be assigned address pointers in different ranges of the address space). When a translation is performed using a given set of stage 1 translation tables, a corresponding translation table entry located from the stage 1 tables based on the virtual address to be translated returns a corresponding intermediate address (I PA), address space selection information (NS) used to select whether the access is made to a more secure PAS (Realm PAS) or less secure PAS (Non-Secure PAS), and any stage-1 memory access attributes used to control servicing of the corresponding memory access request to the corresponding memory system resource represented by that translation table entry.

[0113] a stage 1 context identifier (e.g. address space identifier, ASID) which can be used to differentiate different stage 1 translation contexts;memory attribute indirection register settings (MAIR), which provide information for selecting which attribute combinations are represented by particular encodings of the stage-1 attributes in a given translation table entry.

[0114] other configuration information, e.g. for adjusting how to compute addresses of page table walk memory accesses depending on the translation table base address TTB0 / TTB1, the virtual address to be translated and any intermediate table pointers obtained at higher levels of the multi-level stage 1 translation table structure.

[0115] The S2TTB, TTBO, TTB1 may collectively be considered an example of the translation table base addresses 84, 86 mentioned earlier for Figure 7.

[0116] Hence, during a two-stage address translation, the overall translation result may provide the translated physical address (PA) corresponding to the virtual address (VA) provided by a translation request (that VA-PA mapping depending on the VA-IPA mapping provided by a stage 1 translation and the IPA-PA mapping provided by a stage 2 translation), a selected PAS dependent on the security state identifier (SEC_SID) of the translation request and, if the SEC_SID indicates the Realm security state, the NS bit returned from the stage 1 and / or stage 2 translation table walk, and one or more memory access attributes dependent on the stage 1 attributes returned from the stage 1 translation table walk and / or the stage 2 attributes returned from the stage 2 translation table walk.

[0117] As shown in in Figure 11, such translation results can be cached in a TLB 65, which provides TLB entries each comprising a tag portion 146 used for looking up the TLB 65 and a data portion 147 which provides an associated translation response (comprising the PA, PAS indication and attributes as mentioned in the previous paragraph) to be returned for a given translation request having parameters matching those indicated by the tag portion 146 of the corresponding TLB entry. For example, the tag portion 146 of a given TLB entry may indicate a valid indicator V indicating whether the entry is valid, and a virtual address tag, security state identifier and requester identifier corresponding to the VA, SEC_SID and requester identifier specified by the translation request which caused the translation response indicated in the data portion 147 of the corresponding TLB entry to be returned by the address translation circuitry 60 when that translation request was previously processed.

[0118] Figure 12 illustrates a more detailed example method for processing a given translation request in an implementation supporting TLBs 65 and use of a stream table structure as the set of MMU configuration information corresponding to a given security state.

[0119] At step 150, in response to the given translation request, the TLB lookup circuitry 64 of the address translation circuitry looks up the TLBs 65 to check whether the TLBs 65 contain a valid entry corresponding to the VA, security state identifier and requester identifier specified by the given translation request. If a TLB hit is detected at step 152 (there is a valid TLB entry corresponding to the specified combination of VA, security state identifier and requester identifier), then at step 154 the translation result for the given translation request is obtained basedon the hit TLB entry. If a TLB miss is detected at step 152, then at step 156 the MMU configuration selection circuitry performs a stream table lookup based on the requester identifier and the security state identifier SEC_SID. This lookup could be in a stream table cache 69, which if containing a valid cache entry providing the required stream table information can be used to locate the required information without needing further memory accesses to be performed, or if missing in the stream table cache 69 or there is no such cache 69 at all, then the stream table lookup can be in a memory-based structure, based on computing an address of the relevant stream table entry from the base address stored in the corresponding base address register 68 corresponding to the specified security state indicated by SEC_SID and the requester identifier. During the stream table lookup performed for a given translation request which is a less secure translation request specifying SEC_SID = less secure (Non-Secure), the MMU configuration selection circuitry 62 determines, based on the redirection indicator 80 indicated in a corresponding less secure (Non-Secure) stream table entry, whether the given translation request which should be treated as a redirected translation request which is to reuse the more secure MMU configuration. If the given translation request is to be treated as the redirection translation request, then the method returns to step 150 to perform a further TLB lookup (and if required following a TLB miss, a further stream table lookup from the more secure stream table at step 156), but this time treating the request as if it specified the SEC_SID indicating the more secure (Realm) security state.

[0120] If the given translation request is not a redirected translation request, or is a redirected translation request for which the further stream table lookup in the more secure stream table structure has been performed at step 156, then at step 160 a page table walk operation is performed by the page table walk control circuitry 66 based on the selected set of MMU configuration information obtained in the stream table lookup. That selected set of MMU configuration information can be the less secure set of MMU configuration information, for a given translation request specifying {SEC_SID = less secure} that is not a redirected translation request, or can be the more secure set of MMU configuration information, for a given translation request specifying {SEC_SID = more secure} or a given translation request specifying {SEC_SID = less secure} that is being treated as a redirected translation request. If a fault is detected in the page table walk operation, then at step 162 the fault is reported and processing of the given translation request is aborted. If no fault is detected, then at step 164 the translation result obtained based on the page table walk operation is returned as a response to the given translation request, and at step 166 a new TLB entry can be allocated in the TLBs 65 based on the translation result obtained in the page table walk operation.

[0121] Figure 13 illustrates steps showing the TLB lookup process at step 150 in more detail. At step 170, the TLB lookup control circuitry 64 determines whether this TLB lookup is being performed for a redirected translation request (a translation request specifying {SEC_SID = Less secure} which is being treated as if it is more secure due to the redirection indicator 80 being setto specify that it should be treated as a redirected translation request). If the given translation request is not a redirected translation request, then at step 172 a tag lookup is performed based on the VA, SEC_SID and Requester identifier (ID) of the given translation request, to perform a tag comparison between the tag portions 146 of one or more TLB entries of the TLB 65 and the VA, SEC_SID and requester ID parameters of the given translation request. If a tag match is detected at step 174 in this comparison, then at step 178 a TLB hit is detected and the PA, PAS and memory attributes specified in the data portion 147 of the TLB entry having the matching tag portion 146 are returned as a translation result for the given translation request. If no tag match is detected for any valid TLB entry, then a TLB miss is detected at step 176.

[0122] On the other hand, if the TLB lookup is being performed for a redirected translation request, then at step 180 the tag look up is performed based on the VA and Requester ID of the given translation request but with the SEC_SID used for the tag comparison indicating the Realm (more secure) security state even though the given translation request actually specified SEC_SID indicating the Non-Secure (less secure) security state. If the TLB at step 182 detects that no tag match occurs for any valid TLB entry, then again a TLB miss is detected at step 176. However, in the case of a hit TLB entry having a matching tag portion 146 corresponding to the VA, Requester ID and SEC_SID = Realm, an additional check is performed at step 184 (that is not required for non-redirected translation requests), to check whether the hit TLB entry specifies a PAS indicator indicating the Realm PAS (to denote that this TLB entry corresponds to a more secure memory system resource that should not be accessible to requests specifying {SEC_SID = Non-secure}). If the hit TLB entry does specify a PAS indicator indicating the Realm PAS, then at step 188 the address translation circuitry 60 prevents the redirected translation request proceeding based on the information from the hit TLB entry. This could be achieved in different ways, e.g. by treating the TLB lookup as returning a TLB miss (even though there was an entry having a matching tag portion 146) or by aborting processing of the given translation request and signalling a fault. Either way, this ensures that the redirection function cannot result in a translation request associated with the less secure (Non-Secure) security state enabling access to be provided to a more secure memory system resource accessed via the Realm PAS. On the other hand, if the hit TLB entry is detected at step 184 as specifying a PAS indicator indicating the less secure (Non-Secure) PAS, then at step 186 a TLB hit can be detected and the PA, PAS and memory attributes indicated by the data portion 147 of the hit TLB entry can be returned as the translation result for the given translation request being treated as the redirected translation request.

[0123] Figure 14 shows an example providing more detailed steps for implementing the stream table lookup step 156 of Figure 12, in a case where there is no cached stream table information available to obtain the MMU configuration selection information required for controlling a page table walk in response to a given translation request (if there is cached stream table informationavailable in the stream table cache 69 then the page table walk can be controlled based on the cached information and the process shown in Figure 14 is not needed).

[0124] At step 190, the MMU configuration selection circuitry 62 determines whether the current stream table lookup is for a given translation request that has already been identified as a redirected translation request. If the given translation request which prompted this stream table lookup is not already identified as a redirected translation request, then at step 192 the MMU configuration selection circuitry 62 selects the stream table base address register 68 which corresponds to the security state identifier SEC_SID specified by the given translation request. At step 193, the MMU configuration selection circuitry 62 computes the address of a selected stream table entry based on a stream identifier derived from the requester identifier of the given translation request and the base address obtained from the base address register 68 selected at step 192. At step 194, the MMU configuration selection circuitry 62 issues a memory access request to read the selected stream table entry from memory 10, and once the selected stream table entry has been returned from memory 10, determines at step 196 whether the selected stream table entry specifies redirection information 80 indicating that the given translation request is to be treated as a redirected translation request. If the given translation request is to be treated as a redirected translation request, then at step 198 the MMU configuration selection circuitry 62 signals that the given translation request is to be treated as a redirected translation request, to control a fresh TLB lookup to be performed at step 150 for the redirected translation request, this time assuming that the SEC_SI D for the request indicates the more secure (Realm) security state whereas the previous TLB lookup would have been based on SEC_SID indicating the less secure (Non-Secure) security state. If the selected stream table entry obtained from the less secure stream table at steps 192 to 194 indicates that the given translation request is not to be treated as a redirected translation request, then at step 200 no further TLB / stream table lookup is needed as the given translation request can continue to be treated as a non-redirected translation request, and the MMU configuration information encoded in, and / or located using (e.g. from a corresponding context descriptor 143) the selected stream table entry 142 is returned for use in controlling a subsequent page table walk operation.

[0125] If at step 190 the current stream table lookup is detected as being lookup performed for a given translation request that has already been identified as a redirected translation request, then at step 202 the more secure (Realm) stream table base address register is selected and at step 204 an address of a selected stream table entry 142 is computed based on the base address obtained from the more secure base address register 68 and the stream identifier (ID) derived from the requester identifier specified by the given translation request being treated as the redirected translation request. Hence, this stream table lookup is now from the Realm MMU configuration structures, not the Non-Secure MMU configuration structures. At this point, this will be the second stream table lookup performed for this given translation request, since the same translation request will already have had a first stream table lookup performed following steps 192to 198 before it was identified that the request should be treated as a redirected translation request. The stream ID used in the second stream table lookup at step 204 to select a stream table entry from the more secure (Realm) stream table 141 is the same as the Stream ID used in the first stream table look up at step 193 to select a stream table entry from the less secure (Nonsecure) stream table 141. At step 206, the selected stream table entry is read from a memory system location corresponding to the address computed at step 204. At step 208, if the redirection consent indicator 88 is supported by the IOMMU architecture, then the MMU configuration selection circuitry determines whether the selected stream table entry read at step 206 specifies redirection consent information 88 indicating that the realm stream table entry is not allowed to be used to control address translation for a (actually Non-secure) redirected translation request, and if such reuse of the Realm stream table entry for controlling handling of a Non-Secure translation request is indicated as not allowed, then at step 210 processing of the given translation request is aborted. Steps 208, 210 are omitted in implementations that do not support the redirection consent indicator 88. If step 208 is omitted, or step 208 is performed but the redirection consent information 88 in the selected stream table entry read at step 206 indicates that the Realm stream table entry is permitted to be used for controlling address translation for redirected Non-secure translation requests, then at step 212 the processing of the given translation request can continue, and the MMU configuration selection circuitry 62 returns a selected set of MMU configuration information encoded in, and / or located using, the selected stream table entry.

[0126] Figure 15 shows an example providing more detailed steps for implementing the page table walk operation 160 of Figure 12. At step 230, the page table walk circuitry 66 of the address translation circuitry 60 performs the page table walk operation based on the virtual address (VA) specified by the given translation request and the translation table base address 84, 86 (e.g. TTB0, TTB1, S2TTB) provided by the selected set of MMU configuration information obtained in the stream table lookup at step 156 (e.g. the information returned at step 200 or 212 of Figure 14 as discussed above). At step 232, the page table walk circuitry 66 detects whether this page table walk is being performed for a redirection translation request and the translation result from the page table walk operation indicates that the corresponding physical address is to be accessed in the more secure (Realm) PAS. If both of these conditions are satisfied, then at step 234 a fault is reported and processing of the given translation request is aborted, to prevent a redirected Non-Secure translation request enabling access to a resource assigned to the Realm PAS. Similarly, if any other cause of address translation fault is detected at step 236 (e.g. no valid page table entry being specified corresponding to the VA, or a violation of read / write access permissions or other permissions defined by the S1 or S2 attributes obtained in the page table walk process), then again at step 234 a fault is reported and processing of the given translation request is aborted. If no fault is detected at either step 232 or step 236, then the translation result obtained in the page table walk operation can be returned to be provided as a response to the given translation request. Hence, for redirected translation requests, then provided the translationresult indicates an access to the Non-Secure PAS, it is possible to obtain a translation result based on the Realm translation table structures accessed via the Realm MMU configuration, so that it is unnecessary for software developers to maintain a second set of shadow Non-Secure page tables corresponding to a device context which will later access the same Non-Secure PAS memory resources using trusted address translation requests specifying T=1 1 SEC_SID = Realm.

[0127] Figure 16 shows an example providing more detailed steps for allocating a new TLB entry at step 166 of Figure 12. At step 250, the TLB allocation circuitry 70 selects a victim TLB entry to be allocated with the information based on the translation result returned by the page table walk operation at step 160 of Figure 12. Any known victim selection algorithm can be used to select the victim TLB entry (e.g. least recently used, round robin, etc.). At step 252 the TLB allocation circuitry 70 determines whether this TLB allocation is for a redirected translation request or a non-redirected translation request. If the TLB allocation is for a non- redirected translation request, then at step 254 the new TLB entry is allocated with the security state tag value corresponding to the security state identifier SEC_SID specified by the given translation request that caused the corresponding translation result to be obtained by a page table walk operation. If the TLB allocation is for a redirected translation request, then at step 256 the new TLB entry is allocated with the security state tag value specifying SEC_SID = more secure (Realm) security state, even though the redirected translation request corresponds to a given translation request which actually specified SEC_SID = less secure (Non-secure). Either way, at step 258 the TLB allocation circuitry 70 updates the victim TLB entry to be valid, with the new entry specifying, in the tag portion 146, a VA tag and requester identifier tag corresponding to the VA and requester identifier of the given translation request that caused the TLB allocation to occur and the security state tag set as specified at step 254 or 256 of Figure 16. The data portion 147 of the new valid TLB entry is set to specify the translation result obtained in the page table walk operation performed at step 160.

[0128] Hence, by allocating a more secure (Realm) TLB entry for a redirected translation request even though that translation request is really associated with the less secure (Non-Secure) security state, this means that later in the device’s lifecycle when the device has transitioned to the more secure security state, subsequent accesses from that device 12 specifying the same combination of VA and requester ID can hit against a TLB entry previously allocated to the TLB 65 when the device 12 was still issuing less secure (Non-secure) transactions treated as redirected translation request. The Realm PAS access check at step 184 of Figure 13 will ensure that the newly allocated Realm TLB entry cannot be used to enable access to Realm PAS memory system resources in response to translation requests specifying a SEC_SID indicating the Non-Secure security state.

[0129] Concepts described herein may be embodied in a system comprising at least one packaged chip. The IOMMU 14 described earlier is implemented in the at least one packaged chip (either being implemented in one specific chip of the system, or distributed over more thanone packaged chip). The at least one packaged chip is assembled on a board with at least one system component. A chip-containing product may comprise the system assembled on a further board with at least one other product component. The system or the chip-containing product may be assembled into a housing or onto a structural support (such as a frame or blade).

[0130] As shown in Figure 17, one or more packaged chips 400, with the IOMMU 14 described above implemented on one chip or distributed over two or more of the chips, are manufactured by a semiconductor chip manufacturer. In some examples, the chip product 400 made by the semiconductor chip manufacturer may be provided as a semiconductor package which comprises a protective casing (e.g. made of metal, plastic, glass or ceramic) containing the semiconductor devices implementing the IOMMU 14 described above and connectors, such as lands, balls or pins, for connecting the semiconductor devices to an external environment. Where more than one chip 400 is provided, these could be provided as separate integrated circuits (provided as separate packages), or could be packaged by the semiconductor provider into a multi-chip semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multi-layer chip product comprising two or more vertically stacked integrated circuit layers).

[0131] In some examples, a collection of chiplets (i.e. small modular chips with particular functionality) may itself be referred to as a chip. A chiplet may be packaged individually in a semiconductor package and / or together with other chiplets into a multi-chiplet semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multilayer chiplet product comprising two or more vertically stacked integrated circuit layers).

[0132] The one or more packaged chips 400 are assembled on a board 402 together with at least one system component 404 to provide a system 406. For example, the board may comprise a printed circuit board. The board substrate may be made of any of a variety of materials, e.g. plastic, glass, ceramic, or a flexible substrate material such as paper, plastic or textile material. The at least one system component 404 comprise one or more external components which are not part of the one or more packaged chip(s) 400. For example, the at least one system component 404 could include, for example, any one or more of the following: another packaged chip (e.g. provided by a different manufacturer or produced on a different process node), an interface module, a resistor, a capacitor, an inductor, a transformer, a diode, a transistor and / or a sensor.

[0133] A chip-containing product 416 is manufactured comprising the system 406 (including the board 402, the one or more chips 400 and the at least one system component 404) and one or more product components 412. The product components 412 comprise one or more further components which are not part of the system 406. As a non-exhaustive list of examples, the one or more product components 412 could include a user input / output device such as a keypad, touch screen, microphone, loudspeaker, display screen, haptic device, etc.; a wireless communication transmitter / receiver; a sensor; an actuator for actuating mechanical motion; athermal control device; a further packaged chip; an interface module; a resistor; a capacitor; an inductor; a transformer; a diode; and / or a transistor. The system 406 and one or more product components 412 may be assembled on to a further board 414.

[0134] The board 402 or the further board 414 may be provided on or within a device housing or other structural support (e.g. a frame or blade) to provide a product which can be handled by a user and / or is intended for operational use by a person or company.

[0135] The system 406 or the chip-containing product 416 may be at least one of: an end-user product, a machine, a medical device, a computing or telecommunications infrastructure product, or an automation control system. For example, as a non-exhaustive list of examples, the chipcontaining product could be any of the following: a telecommunications device, a mobile phone, a tablet, a laptop, a computer, a server (e.g. a rack server or blade server), an infrastructure device, networking equipment, a vehicle or other automotive product, industrial machinery, consumer device, smart card, credit card, smart glasses, avionics device, robotics device, camera, television, smart television, DVD players, set top box, wearable device, domestic appliance, smart meter, medical device, heating / lighting control device, sensor, and / or a control system for controlling public infrastructure equipment such as smart motorway or traffic lights.

[0136] Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein.

[0137] For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts.

[0138] Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuitcomponents may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly.

[0139] The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated.

[0140] Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept.

[0141] Figure 18 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the hostprocessor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63.

[0142] To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable.

[0143] The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features.

[0144] In the context of a simulation program 710 which simulates a system comprising an IOMMU 14 as discussed earlier, the simulator code 710 may include address translation program logic 712 and MMU configuration information selection program logic 714, which controls the host hardware 730 to emulate the hardware functionality provided by the address translation circuitry 60 and MMU configuration selection circuitry 62 described earlier for the IOMMU 14 (e.g. see Figure 5). Hence, when simulated translation requests from simulated I / O devices are detected, the MMU configuration information selection program logic 714 selects a set of MMU configuration information to be used for controlling address translation, including support for the redirection function described above where a less secure translation request is treated as if it is a more secure translation request if the less secure MMU configuration includes the redirection control indication 80 indicating that the translation request is to be redirected. The address translation program logic 712 translates the virtual address specified by the translation request to a physical address based on address translation information located using the selected set of MMU configuration information. Any control registers of the IOMMU (e.g. the MMU configuration base address registers 68) can be simulated by the simulation program 710 by mapping them to corresponding host storage locations (e.g. host memory) provided by the host hardware 730, so that any operations which would have referenced those registers in a hardware embodimentinstead reference the corresponding mapped location in the host storage provided by host hardware 730.

[0145] In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

[0146] In the present application, lists of features preceded with the phrase “at least one of” mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination.

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

Claims

1. CLAIMS1. An input / output memory management unit (IOMMU) comprising:address translation circuitry configured to obtain a translation result in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request, wherein the translation result depends on address translation information located using a selected set of memory management unit (MMU) configuration information selected for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; andMMU configuration selection circuitry configured to control selection of the selected set of MMU configuration information; in which:when the security state identifier of the given translation request specifies a less secure security state, the MMU configuration selection circuitry is configured to:determine, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; andin response to determining that the given translation request should be treated as the redirected translation request, select the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

2. The IOMMU according to claim 1, in which:in response to the given translation request when treated as the redirected translation request, the address translation circuitry is configured to determine whether to allow the given translation request to proceed based on the translation result obtained for the given translation request based on the address translation information located using the more secure set of MMU configuration information, depending on whether that translation result indicates that the target address corresponds to a more secure memory system resource prohibited from being accessed based on a request associated with the less secure security state.

3. The IOMMU according to claim 2, in which in response to the given translation request when treated as the redirected translation request, the address translation circuitry is configured to abort processing of the given translation request in response to determining that the translation result obtained for the given translation request based on the address translation information located using the more secure set of MMU configuration information indicates that the target address corresponds to the more secure memory system resource.

4. The IOMMU according to any of claims 2 and 3, in which the translation result comprises a physical address and physical address space identifying information indicative of a selected physical address space in which the physical address is to be accessed, the selected physical address space being one of a plurality of physical address spaces for which data assigned to a given physical address space is isolated from being observable by an observer prohibited from accessing that given physical address space; andthe address translation circuitry is configured to determine that the target address corresponds to the more secure memory system resource in response to determining that the physical address space identifying information of the translation result indicates that the selected physical address space is a more secure physical address space corresponding to the more secure security state.

5. The IOMMU according to any preceding claim, in which the MMU configuration selection circuitry is configured to determine, based on redirection consent information specified by the more secure set of MMU configuration information, whether use of the more secure set of MMU configuration information to control translation in response to the redirected translation request is permitted.

6. The IOMMU according to claim 5, in which the MMU configuration selection circuitry is configured to abort processing of the given translation request in response to detecting that the redirection consent information of the more secure set of MMU configuration information specifies that use of the more secure set of MMU configuration information to control translation in response to the redirected translation request is not permitted.

7. The IOMMU according to any preceding claim, comprising a plurality of stream table base address registers each corresponding to a respective security state, wherein the MMU configuration selection circuitry is configured to access, using a stream table base address stored in a given stream table base address register corresponding to a given security state, the set of MMU configuration information associated with the given security state.

8. The IOMMU according to claim 7, in which when the security state identifier of the given translation request specifies the less secure security state, the MMU configuration selection circuitry is configured to:perform a first stream table lookup to select, based on a requester identifier specified by the given translation request, a selected stream table entry of a less secure stream table accessed using a less secure stream table base address stored in a less secure stream table base address register corresponding to the less secure security state; andusing the selected stream table entry selected in the first stream table lookup, obtain the redirection information specifying whether the given translation request should be treated as the redirected translation request.

9. The IOMMU according to claim 8, in which, in response to determining that the given translation request should be treated as the redirected translation request, the MMU configuration selection circuitry is configured to perform a further stream table lookup to select a further stream table entry of a more secure stream table accessed using more secure stream table base address stored in a more secure stream table base address register corresponding to the more secure security state, and to control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information located using the further stream table entry.

10. The IOMMU according to claim 9, in which the MMU configuration selection circuitry is configured to perform the further stream table lookup to select the further stream table entry from the more secure stream table based on the same requester identifier used to select the selected stream table entry from the less secure stream table in the first stream table lookup.

11. The IOMMU according to any preceding claim, comprising a translation lookaside buffer (TLB) comprising a plurality of TLB entries configured to cache address translation information, wherein a given TLB entry is tagged with a security state tag to be compared in a tag lookup with a security state identifier of a translation request to determine whether the translation request hits against the given TLB entry; andwhen a new TLB entry is allocated for address translation information obtained in response to the redirected translation request, the TLB is configured to tag the new TLB entry with the security state tag specifying the more secure security state even though the security state identifier for the given translation request being treated as the redirected translation request specifies the less secure security state.

12. The IOMMU according to claim 11 , in which, when performing the tag lookup for the given translation request when treated as the redirected translation request, the TLB is configured to treat the security state identifier of the given translation request as indicating the more secure security state for purposes of the tag lookup, even though the security state identifier for the given translation request specifies the less secure security state.

13. The IOMMU according to any of claims 11 and 12, in which in response to detecting a tag match for a particular TLB entry in the tag lookup performed for the redirected translation request when the address translation information cached in the particular TLB entry indicates that the target address corresponds to a more secure memory system resource prohibited from being accessed based on a request associated with the less secure security state, the TLB is configured to prevent the redirected translation request proceeding based on the address translation information cached in the particular TLB entry.

14. The IOMMU according to claim 13, in which the TLB is configured to prevent the redirected translation request proceeding based on the address translation information cached in the particular TLB entry, by treating the tag lookup as missing in the TLB despite the tag match being detected.

15. A system comprising:the IOMMU of any preceding claim, implemented in at least one packaged chip; at least one system component; anda board,wherein the at least one packaged chip and the at least one system component are assembled on the board.

16. A chip-containing product comprising the system of claim 15, wherein the system is assembled on a further board with at least one other product component.

17. Computer-readable code for fabrication of an IOMMU according to any of claims 1 to 14.

18. A storage medium storing the computer-readable code of claim 17.

19. A method for processing a given translation request received by an input / output memory management unit (IOMMU), the method comprising:in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request:selecting a selected set of memory management unit (MMU) configuration information for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; and controlling address translation circuitry to obtain a translation result for the given translation request depending on address translation information located using the selected set of MMU configuration information;in which:the selecting comprises, in response to determining that the security state identifier of the given translation request specifies a less secure security state:determining, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; andin response to determining that the given translation request should be treated as the redirected translation request, selecting the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation circuitry to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

20. A computer program comprising instructions which, when executed on a host data processing apparatus, control the host data processing apparatus to simulate an input / output memory management unit (IOMMU), the computer program comprising:address translation program logic configured to obtain a translation result in response to a given translation request specifying a target address to be translated and a security state identifier identifying which of a plurality of security states is associated with the given translation request, wherein the translation result depends on address translation information located using a selected set of memory management unit (MMU) configuration information selected for the given translation request from among a plurality of sets of MMU configuration information respectively associated with the plurality of security states; andMMU configuration selection program logic configured to control selection of the selected set of MMU configuration information; in which:when the security state identifier of the given translation request specifies a less secure security state, the MMU configuration selection program logic is configured to:determine, based on redirection information specified by a less secure set of MMU configuration information associated with the less secure security state, whether the given translation request is to be treated as a redirected translation request for which the selected set of MMU configuration information should be a more secure set of MMU configuration information associated with a more secure security state even though the security state identifier for the given translation request specifies the less secure security state; andin response to determining that the given translation request should be treated as the redirected translation request, select the more secure set of MMU configuration information as the selected set of MMU configuration information to control the address translation program logic to obtain the translation result for the given translation request depending on address translation information located using the more secure set of MMU configuration information.

21. A storage medium storing the computer program of claim 20.

Images