Partition Identifier Space Selection

Abstract

The processing circuitry (310) processes instructions in one of at least three regions each associated with a corresponding physical address space and issues memory access requests to the memory system, the memory access requests including a partition identifier (selected based on programmable partition identifier selection information associated with a current software execution environment that caused the memory access request to be issued) and a multi-bit partition identifier space indicator indicative of a selected partition identifier space (selected from among the at least three partition identifier spaces based on a current region of the processing circuitry). The selected partition identifier space and the partition identifier (332, 334) together represent information for selecting parameters in a memory system component for controlling allocation of or managing contention for resources for processing the memory access request, or for selecting whether to update performance monitoring data in response to the memory access request.

Description

[Technical Field]

[0001] The present technique relates to the field of data processing.

[0002] Two or more software execution environments, such as applications or virtual machines, may execute in the same data processing system with access to a common memory system shared among the software execution environments. In some systems, it may be important that the performance of one software execution environment is not degraded due to another software execution environment making heavy use of resources in the shared memory system. This problem may be referred to as the "noisy neighbor" problem, and may be particularly important for, for example, enterprise networking or server systems.

[0003] At least some embodiments include an apparatus comprising: processing circuitry for processing instructions in one of at least three regions each associated with a corresponding physical address space, and issuing memory access requests to the memory system specifying a target address indicating a target memory system location; a partition identifier selection circuit that selects a partition identifier based on programmable partition identifier selection information associated with the current software execution environment that caused the memory access request to be issued; a partition identifier space selection circuit that selects a selected partition identifier space from among the at least three partition identifier spaces based on a current region of the processing circuit; the selected partition identifier space and the partition identifier together represent information for selecting, in a memory system component of the memory system, a set of one or more memory system resource control parameters for controlling allocation of resources to process memory access requests or for managing contention for resources, or for selecting, in the memory system component, whether to update performance monitoring data in response to a memory access request; An apparatus is provided in which a processing circuit is configured to issue a memory access request to a memory system, the memory access request specifying a partition identifier and a partition identifier space indicator comprising a plurality of bits indicating a selected partition identifier space selected by a partition identifier space selection circuit.

[0004] At least some embodiments include a memory system component comprising: a memory access request receiving circuit for receiving a memory access request, the memory access request specifying a target address indicating a target memory system location within the memory system, a partition identifier space indicator including a plurality of bits indicating a selected partition identifier space selected from among at least three partition identifier spaces, and a partition identifier associated with a current software execution environment that caused the memory access request to be issued; at least, a resource control circuit that selects a set of one or more memory system resource control parameters based on the partition identifier space indicator and the partition identifier, and controls allocation of resources for processing memory access requests or manages contention for resources based on the selected set of memory system resource control parameters; and / or a performance monitoring control circuit that controls whether to update performance monitoring data in response to a memory access request based on the partition identifier space indicator and the partition identifier; and one of:

[0005] At least some embodiments include a method, processing instructions in one of at least three regions each associated with a corresponding physical address space; selecting a partition identifier based on programmable partition identifier selection information associated with the current software execution environment that caused the memory access request to be issued; selecting a selected partition identifier space from among the at least three partition identifier spaces based on a current region of the processing circuit; Issuing a memory access request to a memory system specifying a target address indicating a target memory system location, a partition identifier, and a partition identifier space indicator including a plurality of bits indicating a selected partition identifier space; at least, selecting a set of one or more memory system resource control parameters based on the partition identifier space indicator and the partition identifier, and controlling resource allocation or managing contention for resources for processing memory access requests based on the selected set of memory system resource control parameters; and / or and controlling whether to update performance monitoring data in response to a memory access request based on the partition identifier space indicator and the partition identifier. [Brief explanation of the drawings]

[0006] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, which should be read in conjunction with the accompanying drawings. [Figure 1] 1 is a diagram illustrating an example of a data processing system including a memory system. [Figure 2] 1 is a diagram illustrating an example of partitioning control of memory system resources depending on partition IDs assigned to software execution environments associated with memory transactions and partition ID space indicators. [Figure 3] 1 is a schematic diagram illustrating an example of an apparatus having a processing circuit, a partition ID selection circuit, and a partition ID space selection circuit. [Figure 4] FIG. 2 illustrates some areas in which a processing circuit may operate. [Figure 5] FIG. 1 illustrates a schematic diagram of aliasing of several physical address spaces on a system physical address space that identifies locations within a memory system. [Figure 6] FIG. 1 illustrates an example of partitioning the effective hardware physical address space whereby different architectural physical address spaces have access to respective portions of the system physical address space. [Figure 7] FIG. 1 is a flow diagram illustrating a method for controlling the issuance of memory access requests. [Figure 8] FIG. 1 is a flow diagram illustrating selecting a physical address space for a given memory access request. [Figure 9] FIG. 10 is a flow diagram illustrating a physical address space filter check based on information specified in a granule protection table entry corresponding to an accessed physical address. [Figure 10] FIG. 10 is a diagram illustrating an example of a control register for controlling selection of a partition ID and a partition ID space for a memory access request. [Figure 11] FIG. 2 illustrates an example of a discovery register for providing discovery information indicative of functionality implemented in a processing system. [Figure 12] FIG. 11 illustrates in more detail some of the control registers shown in FIG. 10. [Figure 13A] 10A and 10B illustrate partition ID selection for data access and instruction fetch access, respectively. [Figure 13B] 10A and 10B illustrate partition ID selection for data access and instruction fetch access, respectively. [Figure 14] FIG. 10 is a flow diagram illustrating partition ID space selection. [Figure 15] FIG. 15 is a flow diagram illustrating in more detail the steps of FIG. 14 for selecting whether to use a primary partition ID space or an alternate partition ID space. [Figure 16] FIG. 1 illustrates some of the memory system components. [Figure 17] FIG. 1 is a flow diagram illustrating the processing of memory access requests in memory system components. [Figure 18] FIG. 1 illustrates an example of a processing system that includes bridge circuits at the boundaries between areas of a device that support different numbers of partition ID spaces. DETAILED DESCRIPTION OF THE INVENTION

[0007] The apparatus may include processing circuitry for processing instructions and issuing memory access requests to the memory system that specify a target address indicating a target memory system location. A partition ID selection circuit may be provided for selecting a partition identifier (ID) based on programmable partition ID selection information associated with a current software execution environment that caused the memory access request to be issued. The selected partition ID may be used by memory system components of the memory system to select a set of one or more memory system resource control parameters for controlling allocation of resources for processing the memory access request or for managing contention for resources, or to select whether performance monitoring data is updated at the memory system components in response to the access request. Thus, the partition ID may be presented as a label for the memory access request that can be used to distinguish between different software that issued the memory access request, thereby allowing resources in the memory system to be divided among the software execution environments to prevent one software execution environment from taking over more than its fair share of the resources and addressing the noisy neighbor problem described above, and / or allowing performance monitoring of different software or subsets of software associated with different partition IDs to be performed at the memory system components to gather more accurate information regarding the performance perceived by the different software. Either way, this may help address the noisy neighbor problem.

[0008] The processing circuitry can process instructions in one of at least three regions, each associated with a corresponding physical address space. While physical addresses can be used in a data processing system to point to locations in a memory system, the processing system can support the use of virtual memory, in which address translation circuitry can be used to translate virtual addresses specified by instructions executing on the processing circuitry into corresponding physical addresses associated with the locations to be accessed and the memory system. The mapping between virtual addresses and physical addresses can be defined in one or more page table structures. Page table entries in the page table structures can also define certain access permission information that can control whether a given software process executing on the processing circuitry can access a particular virtual address.

[0009] In some processing systems, all virtual addresses may be mapped by address translation circuitry onto a single physical address space that is used by the memory system to identify locations in memory to be accessed. In such systems, control over whether a particular software process can access a particular address is provided based on a page table structure used to provide the virtual-to-physical address translation mapping. However, such page table structures may typically be defined by the operating system and / or hypervisor. Compromise of the operating system or hypervisor could result in a security breach that could allow an attacker to access sensitive information.

[0010] Thus, in some systems where certain processes need to be executed securely in isolation from other processes, the system may support operation in several regions, and several separate physical address spaces may be supported, and for at least some components of the memory system, memory access requests where a virtual address is translated to a physical address in a different physical address space are treated as if they were accessing an entirely different address in memory, even if the physical addresses in the respective physical address spaces actually correspond to the same location in memory. Isolating accesses to the separate physical address spaces from different operating regions of the processing circuitry, as seen by some memory system components, can provide stronger security guarantees that are not dependent on page table permission information set by an operating system or hypervisor.

[0011] Some systems that support separate physical address spaces in this manner may support only two regions, each associated with a corresponding physical address space, allowing secure software running in a secure region to be isolated from less secure software running in a less secure region. However, it is increasingly desirable to provide a secure computing environment that limits the need for software providers to trust other software providers associated with other software running on the same hardware platform. There may be several applications, for example, in areas such as mobile payments and banking, implementing anti-fraud or anti-piracy mechanisms, security enhancements for secure virtual machine hosting in cloud systems, confidential computing, etc., where a provider of software code may be unwilling to trust another provider of software code running on the same physical platform. Such situations may also increasingly arise between two or more separate parties that each desire to be provided with a secure computing environment isolated from the less secure environment associated with normal application-level code, but who do not trust each other; therefore, it may be useful to be able to support three or more separate regions, each associated with a corresponding physical address space.

[0012] In some examples, there may be more than four regions, and therefore the processing circuitry may support selection between at least four different physical address spaces.

[0013] In the embodiment described below, a partition ID space selection circuit is provided for selecting a selected partition ID space from among at least three partition ID spaces based on a current region of the processing circuit. The selected partition ID space, together with the partition ID of the memory access request, is used as information for selecting a set of memory system resource control parameters or for selecting whether to update performance data in response to the memory access request, as described above, to enable performance partitioning and performance monitoring of memory resources. When a memory access request is issued by the processing circuit to the memory system, the memory access request specifies both a partition ID and a partition ID space indicator including a plurality of bits that indicates the selected partition ID space selected by the partition ID space selection circuit.

[0014] By supporting at least three partition ID spaces that can be selected based on the current region of the processing circuit, the same partition ID can be used in separate regions, but requests specifying the partition IDs can be distinguished as corresponding to different sets of memory system resource control parameters or for purposes of performance monitoring by memory system components. An alternative would be to support fewer partition ID spaces than the number of regions and physical address spaces supported by the processing circuit, which is a valid design choice, but can have the disadvantage that if software in two or more different regions need to share the same partition ID space, the software managing the assignment of partition IDs in the separate regions may need to be coordinated with each other to ensure there is no aliasing of partition IDs used in another region that would affect performance guarantees required by software in a given region through the use of partition IDs. Requiring software for the separate regions to be developed in coordination can increase software development costs.

[0015] The following example supports at least three partition ID spaces corresponding to at least three regions supported by the processing circuit, selects from at least three partition ID spaces based on the current region, and prevents improper aliasing of partition IDs by allowing software in separate regions to coordinate with each other by using a partition ID space indicator in memory access requests containing two or more bits to distinguish between the three or more partition ID spaces. Software development is simplified by maintaining uncoordinated partition ID managers. Software in each region has the freedom to select any partition ID it chooses, since it does so without concern for whether software in another region may be using a conflicting partition ID.

[0016] In summary, the embodiments described below provide a processing circuit for processing instructions in one of at least three regions each associated with a corresponding physical address space and issuing a memory access request to a memory system, the memory access request including a partition ID (selected based on programmable partition ID selection information associated with a current software execution environment that caused the memory access request to be issued) and a multi-bit partition ID space indicator indicating a selected partition ID space (selected from among the at least three partition ID spaces based on a current region of the processing circuit). The selected partition ID space and the partition ID together represent information for selecting parameters in a memory system component for controlling allocation of or managing contention for resources for processing the memory access request, or for selecting whether to update performance monitoring data in the memory system component in response to the memory access request.

[0017] The current region of the processing circuit may not be the only information used to select the selected partition ID space to use for a given memory access request. In some embodiments, the selected partition ID space may be selected based on both the current region of the processing circuit and programmable control information. For example, control states in one or more registers may be used to select the selected partition ID space. The programmable control information may be software programmable and influence which partition ID space is selected for a given memory access request. While it may be useful in hardware to support each region with a corresponding partition ID space, not all software may need to use a separate partition ID space for each region. In some cases, it may be desirable for software in separate regions to operate using a common partition ID space, such as when running legacy software designed for a system with a smaller number of partition ID spaces, or when running software provided by a single provider that includes subcompartments operating in separate regions, allowing the software in the separate regions to trust the common software to manage the assignment of partition IDs for those subcompartments. In this case, it may be desirable to simplify management of partition IDs by using a federated partition ID manager software component. Therefore, providing support for varying which partition ID space is selected for a given region based on programmable control information can be useful to support different software usage models.

[0018] The programmable control information can be defined in a variety of different ways, and in some implementations it may be possible to select any of the supported partition ID spaces as the selected partition ID space to be used for a given region. Thus, because some systems may desire to support free choice as to which partition ID space to use for a given access, the programmable control information can include partition ID space selection information, which can indicate that any one of the supported partition ID spaces can be selected.

[0019] However, in other embodiments, the available options may be more limited, such that for at least some regions it may not be possible to select all available partition ID spaces supported in hardware, and thus the partition ID space choices may be more limited in at least some regions. Restricting the options available for selection may be useful for several reasons, such as avoiding less secure states and selecting a partition ID space associated with a more secure state, and / or reducing hardware complexity and the amount of control state required, thereby reducing processor circuit area and power costs.

[0020] In some examples, the partition ID space selection circuit may select, based on programmable control information, whether the selected partition ID space should be the primary partition ID space associated with the current region or the alternate partition ID space associated with the current region. For at least one of the at least three regions, the alternate partition ID space may be the primary partition ID space associated with another region. Thus, in this approach, each region may have its own primary partition ID space, but programmable support may exist for selecting an alternate partition ID space for use with one region that is the same as the primary partition ID space associated with another region, thereby allowing two regions to be programmed to use the same partition ID space. The definition of which particular partition ID space is the alternate partition ID space for a given region may vary depending on its particular architecture implementation. In general, supporting a primary partition ID space and an alternate partition ID space for each region may be sufficient to support expected software usage models and may be a less complex option to implement than supporting a wider range of partition ID space choices.

[0021] The primary partition ID space for a given region may be fixed for that region, independent of programmable control information. For some regions, the alternate partition ID space may also be fixed, making it impossible to change which partition ID space is the alternate partition ID space for that region; the programmable control information simply selects whether to use the primary or alternate partition ID space.

[0022] However, in some embodiments for at least one region, the alternate partition ID space associated with that region may be a partition ID space that is variably selected according to programmable control information, which allows a wider selection of partition ID spaces to be selected as the alternate partition ID space, which may be useful for some regions, such as a root region (e.g., the root region may be for executing code to switch processing circuitry between other regions), which may be able to monitor other regions and for which it may be useful to support a wider selection of alternate partition ID spaces.

[0023] The processing circuitry can support processing of instructions at one of several different privilege levels, and for at least one privilege level, at least a portion of the programmable control information controlling selection of a selected partition ID space for memory access requests issued at the at least one privilege level is programmable at a more privileged privilege level than the at least one privilege level. Thus, more privileged software can set the programmable control information that constrains which partition ID space should be selected for less privileged software.

[0024] In some scenarios, it may be useful for software at a lower privilege level to have visibility into which partition ID space has been selected for that privilege level based on programmable control information programmable at a higher privilege level. Thus, in some implementations, for at least a subset of at least one privilege level, the processing circuitry may make accessible, for at least one instruction executed at the privilege level of the subset, a constraint space that indicates information indicating the partition ID space selected for that current privilege level based on programmable control information programmable at the higher privilege level. For example, software at a given privilege level (e.g., an operating system privilege level) may be permitted to assign partition IDs but may not change the partition ID space selected for requests issued at that given privilege level or at a lower privilege level. However, it may be useful for the software to determine whether the partition ID space is the partition ID space for the current region or an alternate partition ID space, as this may affect how partition IDs are assigned by the software (e.g., whether cooperation with another software execution environment may be required).

[0025] In some examples in which the processing circuit supports processing of instructions at one of two or more different privilege levels, the programmable control information may include hierarchical control enable information programmable at a first privilege level and space selection control information programmable at a second privilege level that is less privileged than the first privilege level, wherein if the hierarchical control information has a first value, the partition ID selection circuit is configured to select the selected partition ID space in response to the space selection control information programmable at the second privilege level for memory access requests issued at the second privilege level or a third privilege level that is less privileged than the second privilege level, and if the hierarchical control information has a second value, the partition ID selection circuit is configured to select the selected partition ID space for memory access requests issued at the second privilege level or the third privilege level independent of the space selection control information programmable at the second privilege level.

[0026] In this approach, software operating at a first privilege level (having the highest privilege among the first, second, and third privilege levels) can use programmable control information to control whether software operating at a second privilege level is permitted to influence the selection of a selected partition ID space for memory access requests issued at the second or third privilege levels. This hierarchical control scheme can be useful for supporting a variety of different software usage models: some software at the first privilege level may want to delegate responsibility for controlling which partition ID space is selected to code operating at the second privilege level, while other software at the first privilege level may prefer to set control state to control the selection of the partition ID space itself, without allowing code operating at the second privilege level to influence the selection of a partition ID space for memory access requests issued at the second or third privilege levels.

[0027] The partition ID and partition ID space together represent information for selecting memory system resource control parameters or for controlling whether performance monitoring data is updated. This may affect the level of performance achieved for a particular memory access request or the performance view gathered using performance monitoring, but the functional result of processing a memory access request may be independent of the partition ID and selected partition ID space. Therefore, which particular memory system location is accessed corresponding to the target address does not depend on the partition ID and selected partition ID space. Similarly, whether a memory access request is granted or denied does not depend on the partition ID and selected partition ID space.

[0028] The apparatus may have a physical address space selection circuit that selects a selected physical address space for a memory access request based on the current region, and the processing circuitry may issue a memory access request that specifies a physical address space indicator that indicates the selected physical address space. For example, the physical address space selection circuit may be part of a memory management unit for performing address translation, or may be part of a physical address space filter for performing a check to determine whether code operating in the current region is permitted to access a physical address in the selected physical address space.

[0029] The physical address space selection circuit may select a selected physical address space based on the current region and based on physical address space selection information specified in an address translation entry, which provides address translation information for the memory access request. Thus, for a memory access made from a given region as the current region, the memory access request may specify a physical address space associated with a region different from the current region as the selected physical address space based on the information specified in the address translation entry. This may be useful, for example, to allow software in separate regions to share access to shared variables in memory. There may be some constraints on which regions are allowed to access each physical address space, and to maintain security, there may be some combinations of current domains and physical address spaces that are not allowed (e.g., if the processing circuitry is in a non-secure region, it may not be prohibited for the selected physical address space to be a secure physical address space associated with a secure region).

[0030] The physical address space indicator may be separate from the partition ID space indicator. The selection of the selected partition ID space according to the current region may be independent of the physical address space selection information specified in the address translation entry corresponding to the target address of the memory access request. Thus, even if the physical address space selection information indicates that the selected physical address space should be an address space other than the physical address space associated with the current region, the selected partition ID space may remain the partition ID space of the current region, or, if selection of a partition ID space based on programmable control information is supported, the programmable control information may enable selection of a partition ID space different from the physical address space. This provides flexible support for a variety of different software usage models.

[0031] Thus, the physical address space indicator may indicate the physical address space of a given region, and the partition ID space indicator may specify a partition ID space associated with the same region as the region whose address space is indicated by the physical address space indicator, or may indicate a partition ID space associated with a different region than the region whose physical address space is indicated by the physical address space indicator. Thus, both the selection of the physical address space and the selection of the partition ID space may depend on the current region, although separate selections may also be made (e.g., the selected partition ID space may vary depending on programmable control information, as described above).

[0032] The apparatus may include a point of physical aliasing (PoPA) memory system component configured to unalias multiple aliased physical addresses from separate physical address spaces that correspond to the same memory system resource and map any of the multiple aliased physical addresses to an unaliased physical address provided to at least one downstream memory system component; and at least one pre-PoPA memory system component upstream of the PoPA memory system component, the at least one pre-PoPA memory system component configured to treat the aliased physical addresses from the separate physical address spaces as if the aliased physical addresses correspond to separate memory system resources.

[0033] Thus, a memory system may include a Point of Physical Aliasing (PoPA), which is a point at which aliased physical addresses from separate physical address spaces corresponding to the same memory system resource are mapped to one physical address that uniquely identifies that memory system resource. The memory system may include at least one pre-PoPA memory system component located upstream of the PoPA, which treats the aliased physical addresses as if they correspond to different memory system resources.

[0034] For example, the at least one pre-PoPA memory system component may include a cache or translation lookaside buffer that may cache data, program code, or address translation information for aliased physical addresses in separate entries, such that when the same memory system resource is required to be accessed from different physical address spaces, the accesses allocate separate cache or TLB entries. The at least one pre-PoPA memory system component may be, for example, a data cache, an instruction cache, or a unified level 2, level 3, or system cache.

[0035] Additionally, pre-PoPA memory system components may include coherency control circuitry, such as a coherent interconnect, snoop filters, or other mechanisms for maintaining coherency between cache information at each master device. The coherency control circuitry may assign separate coherency states to each aliased physical address in a different physical address space. Thus, the aliased physical addresses are treated as separate addresses for purposes of maintaining coherency, even if they actually correspond to the same underlying memory system resource. While at first glance, tracking coherency separately for aliased physical addresses may appear to cause a loss of coherency issue, in practice, this is not an issue if processes operating in different realms are actually intended to share access to a particular memory system resource because they can access that resource using a common physical address (e.g., a less secure physical address space). Another example of a pre-PoPA memory system component may be a memory protection engine provided to protect data stored in off-chip memory from loss of confidentiality and / or tampering. Such a memory protection engine may, for example, encrypt data associated with a particular memory system resource separately using different encryption keys depending on the physical address space from which the resource is accessed, thereby treating the aliased physical addresses as if they effectively correspond to different memory system resources (e.g., an encryption scheme may be used that makes encryption address dependent, and the physical address space ID may be considered part of the address for this purpose).

[0036] Regardless of the form of the pre-PoPA memory system component, it may be useful for such PoPA memory system components to treat aliased physical addresses as if they correspond to different memory system resources, because this provides hardware-enforced isolation between accesses issued to different physical address spaces, so that information associated with one region cannot be leaked to another region due to features such as cache timing side channels or side channels triggered by coherency control circuits and involving coherency changes.

[0037] In some implementations, aliased physical addresses in different physical address spaces may be represented using a different numeric physical address value for each different physical address space. This approach may require a mapping table in PoPA to determine which different physical address values ​​correspond to the same memory system resource. However, this overhead of maintaining a mapping table may be considered unnecessary, and in some implementations it may be simpler if the aliased physical addresses include physical addresses represented using the same numeric physical address value in each of the different physical address spaces. If this approach is taken, it may be sufficient at the physical aliasing point to simply discard the physical address space ID that identifies which physical address space is accessed using the memory access, and then provide the remaining physical address bits downstream as the non-aliased physical address.

[0038] Thus, in addition to the pre-PoPA memory system component, the memory system may also include a PoPA memory system component configured to unalias multiple aliased physical addresses to obtain unaliased physical addresses that are provided to at least one downstream memory system component. The PoPA memory system component may be a device that accesses a mapping table to find the unaliased address that corresponds to an aliased address within a particular address space, as described above. However, the PoPA component may simply be a location in the memory system where a physical address tag associated with a given memory access is discarded, so that a physical address provided downstream uniquely identifies the corresponding memory system resource, regardless of which physical address space it is provided from. Alternatively, in some cases, the PoPA memory system component may still provide the physical address space tag to at least one downstream memory system component (e.g., to enable further filter checks in the downstream system component). However, PoPA marks a point in the memory system beyond which downstream memory system components no longer treat aliased physical addresses as different resources and may map the same memory system resource considering each of the aliased physical addresses. For example, when a memory controller or hardware memory storage device downstream of a PoPA receives the physical address tag and physical address of a given memory access request, if that physical address corresponds to the same physical address as a previously seen transaction, any hazard checking or performance improvement steps performed for each transaction accessing the same physical address (such as merging accesses to the same address) may be applied, even if each transaction specifies a different physical address space tag. In contrast, for memory system components upstream of a PoPA, such hazard checking or performance improvement steps taken for transactions accessing the same physical address may not be invoked if those transactions specify the same physical address in different physical address spaces.

[0039] In some embodiments, the above-described apparatus may not include the memory system component itself, which may be an external memory system component.

[0040] However, in other embodiments, the memory system component may be part of the device itself, and may include at least one of a resource control parameter selection circuit that selects a set of one or more memory system resource control parameters based on the partition ID space indicator and the partition ID, and / or a performance monitoring control circuit that controls whether to update performance monitoring data in response to a memory access request based on the partition ID space indicator and the partition ID.

[0041] When resource control parameter selection circuitry is provided within a memory system component, memory system resource control parameters can be mapped to portions of a physical address space so that the resource control parameters can be updated by software running on a processing circuit. Because multiple physical address spaces are supported, multiple options exist for selecting which physical address space to use to access memory system control parameters for a given partition ID space. In one example, if each of at least three partition ID spaces is associated with a corresponding one of at least three regions, a given set of memory system resource control parameters corresponding to a given partition ID space can be accessible in response to a memory access request issued with a target address within the physical address space corresponding to the region associated with the given partition ID space. Defining memory system resource control parameters for a partition ID space associated with a given region in the physical address space associated with the same given region can simplify management of memory system resource control parameters and help maintain security.

[0042] While providing support on the processing side for selecting among at least three partition ID spaces may be useful for the reasons described above, in practice, a processing element comprising the above-described processing circuit, partition ID selection circuit, and partition ID space selection circuit may be integrated into a data processing system (e.g., a system-on-chip) that may have many different memory system components with which the processing element can communicate. Upgrading all memory system components in the system to support three or more different partition ID spaces may require significant development effort, and therefore there may be some legacy components that support fewer partition ID spaces. Therefore, it may be useful to provide a bridge circuit at the boundary between a first area of ​​the device comprising one or more components that support at least three partition ID spaces and a second area of ​​the device comprising one or more components that support fewer partition ID spaces than the one or more components in the first area, the bridge circuit configured to remap partition ID space indicators for memory access requests passing between the first area and the second area. The mapping used by the bridge circuit may be a fixed mapping or a programmable mapping that can be variably changed according to programmable partition ID space mapping information. In some cases, if the bridge circuitry is at a point in the system upstream from the PoPA, the bridge circuitry may also remap the physical address space indicator specified by a given memory access request (if the bridge circuitry is downstream from the PoPA, the physical address space indicator may already have been discarded, and therefore remapping of the physical address space indicator may not be necessary). In general, the provision of the above-described bridge circuitry provides increased flexibility for combining different types of memory system components, thereby enabling the benefits of supporting multiple partition ID spaces in a processing element to be realized without all memory system components needing to support more than two partition ID spaces.

[0043] As described above, in some implementations, a memory system component may be considered an external component of a processing element comprising processing circuitry, and thus the memory system component may be considered a standalone product. Thus, in some examples, the memory system component may include a memory access request receiving circuit that receives a memory access request (e.g., from a processing element of a system-on-chip or other element), the memory access request specifying a target address and a partition ID space indicator as described above, the partition ID space including two or more bits for selecting a selected partition ID space from among at least three partition ID spaces. The memory access request also specifies a partition ID associated with the current software execution environment that caused the memory access request to be issued, defined within the selected partition ID space. The memory component system includes resource control circuitry and / or performance monitoring control circuitry as described above to use the partition ID space indicator and the partition ID to select memory system resource control parameters, control whether performance monitoring data is updated, or both.

[0044] Memory resource and performance monitoring division FIG. 1 schematically illustrates an example of a data processing system 2 including N (N is 1 or greater) processing clusters 4, each of which includes one or more processing units 6, such as a central processing unit (CPU) or a graphics processing unit (GPU). Each of the processing units 6 may have at least one cache, such as a level 1 data cache 8, a level 1 instruction cache 10, and a shared level 2 cache 12. It will be understood that this is merely one example of a possible cache hierarchy, and other cache arrangements may be used. The processing units 6 in the same cluster are coupled by a cluster interconnect 14. The cluster interconnect may include a cluster cache 16 for caching data accessible to any of the processing units.

[0045] A system-on-chip (SoC) interconnect 18 couples the N clusters to any other master devices 22 (such as a display controller or a direct memory access (DMA) controller). The SoC interconnect may include a system cache 20 for caching data accessible to any of the masters connected to the SoC interconnect. The SoC interconnect 18 controls coherency between each of the caches 8, 10, 12, 16, and 20 according to any known coherency protocol. The SoC interconnect is also coupled to one or more memory controllers 24, each of which controls access to a corresponding memory 25, such as a DRAM or SRAM. The SoC interconnect 18 may also route transactions to other slave devices, such as a crypto unit for providing encryption / decryption functions.

[0046] Thus, data processing system 2 comprises a memory system for storing data and providing access to data in response to transactions issued by processing unit 6 and other master devices 22. Caches 8, 10, 12, 16, 20, interconnects 14, 18, memory controller 24, and memory devices 25 may each be considered components of a memory system. Other examples of memory system components may include a memory management unit or translation lookaside buffer (either within processing unit 6 itself or further down in system interconnect 18 or another part of the memory system), which are used to translate memory addresses used to access memory and thus may be considered part of the memory system. Generally, memory system components may include any component of a data processing system used to service memory transactions to access memory data or to control the processing of these memory transactions.

[0047] The memory system may have various resources available for processing memory transactions. For example, caches 8, 10, 12, 16, 20 have storage capacity available for caching data needed by a given software execution environment executing in one of processors 6 to provide faster access to data or instructions than if the data or instructions had to be fetched from main memory 25. Similarly, the MMU / TLB may have capacity available for caching address translation data. Also, interconnects 14, 18, memory controller 24, and memory devices 25 may each have an amount of bandwidth available for processing memory transactions.

[0048] When multiple software execution environments executing on processing elements 6 share access to a memory system, it may be desirable to prevent one software execution environment from using more than its fair share of resources to prevent other execution environments from perceiving a loss in performance. This may be particularly important as data center (server) applications, where there is an increasing demand to reduce capital expenditures by increasing the number of independent software processes interacting with a given amount of memory capacity, increase data center server usage. However, there is still a demand to meet web application tail latency targets, so it is undesirable if one process executing on a server can monopolize memory system resources to the extent that other processes are impaired. Similarly, for networking applications, it is increasingly common to combine multiple functions that were previously located on separate SoCs into a single SoC. Again, this leads to a desire to limit performance interactions between software execution environments and to monitor how the software execution environments need to enable these independent processes to access shared memory while limiting performance interactions.

[0049] 2 schematically illustrates an example of dividing control over allocation of memory system resources depending on the software execution environment that issues the corresponding memory transaction. In this context, a software execution environment may be a process or portion of a process executed by a processing unit in a data processing system. For example, a software execution environment may include an application, a guest operating system or virtual machine, a host operating system or hypervisor, a security monitor program for managing different security states of the system, or subportions of any of these types of processes (e.g., a single virtual machine may have different portions that are considered separate software execution environments). As shown in FIG. 2, each software execution environment may be assigned a given partition identifier 30, and the given partition ID 30 is passed to memory system components along with memory transactions associated with that software execution environment.

[0050] A memory access request issued to a memory component specifies an address, a partition ID (PartID) determined for the corresponding software execution environment, and a partition ID space indicator (MPAM_SP) indicating a selected partition ID space.

[0051] Within a memory system component, resource allocation or conflict resolution operations can be controlled based on one set of several memory system component parameters selected based on a partition ID and a partition ID space indicator. For example, as shown in FIG. 2, each software execution environment may be assigned an allocation threshold that represents the maximum amount of cache capacity that can be allocated for data / instructions associated with that software execution environment, and the associated allocation threshold when processing a given transaction is selected based on the partition ID and partition ID space indicator associated with that transaction. For example, in FIG. 2, a transaction associated with partition ID 0 and partition ID space indicator 0 can allocate data up to 50% of the cache's storage capacity, leaving at least 50% of the cache available for other purposes. Meanwhile, the same partition ID 0 in a different partition ID space (e.g., with MPAM_SP=1 instead of 0) may correspond to a different set of resource control parameters (e.g., in this example, a limit of 40% of cache capacity is defined).

[0052] Similarly, in memory system components such as memory controller 24 that have a finite amount of bandwidth available to process memory transactions, a minimum and / or maximum bandwidth threshold may be specified for each combination of partition ID and partition ID space indicator. If a memory transaction specifying a given partition ID and partition ID space ID uses less than the minimum amount of bandwidth within a given period of time, the memory transaction associated with the given partition ID and partition ID space ID may be prioritized, whereas if the maximum bandwidth has already been used or exceeded by transactions specifying the same partition ID and partition ID space indicator, a lower priority may be used for the memory transaction.

[0053] It will be appreciated that these are merely two examples of how control of memory system resources may be partitioned based on the software execution environment that issued the corresponding transaction. Generally, by allowing different processes to "see" different partitioned portions of the resources provided by the memory system, this allows performance interactions between processes to be limited to help address the aforementioned issues.

[0054] Similarly, the partition ID and partition ID space indicator associated with memory transactions may be used to partition performance monitoring within the memory system, so that a separate set of performance monitoring data may be tracked for each partition ID to allow information specific to a given software execution environment (or group of software execution environments) to be identified, so that sources of potential performance interactions may be more easily identified than if performance monitoring data were recorded globally across all software execution environments. This may facilitate diagnosing potential performance interaction effects and may facilitate identifying possible solutions.

[0055] An architecture for controlling the setting of partition IDs and partition ID space indicators, labeling memory transactions based on the partition ID set for a corresponding software execution environment, routing the partition ID to a memory system, and providing partition-based control of memory system components in a memory system is discussed below. This architecture is scalable to widespread use of partition IDs. The use of partition IDs is intended to layer on the semantics of the memory system's existing architecture without changing those semantics; thus, the addressing, coherence, and required ordering of memory transactions imposed by the particular memory protocol used by the memory system are not affected by resource / performance monitoring partitioning. When partition IDs and partition ID spaces are used to control resource allocation, this may affect the performance achieved when processing memory transactions for a given software execution environment, but does not affect the results of computations effective for the architecture. That is, partition IDs and partition ID spaces do not change the outcome or result of a memory transaction (e.g., which data is accessed), but only affect the timing or performance achieved for that memory transaction.

[0056] Processing elements that support physical address space selection and memory resource partitioning and / or performance monitoring 3 illustrates in more detail some components within a given processing element 6 of system 2 shown in FIG. 1; for example, the processing element may be one of the CPUs 6 shown in FIG. 1. The processing element includes processing circuitry 310 capable of executing instructions according to an instruction set architecture. Processing circuitry 310 includes instruction fetch circuitry 300 that fetches instructions from an instruction cache or from memory, an instruction decoder 302 that decodes the fetched instructions, and one or more execution units 304 that perform processing operations in response to instructions decoded by instruction decoder 302. Registers 312 are provided for storing operands for instructions executed by processing circuitry 310, results of executed instructions, and control data for configuring how processing is performed by processing circuitry 310.

[0057] As described further below, the processing circuitry may support execution of instructions in several operational domains (security states), and registers 312 may contain control state used to identify which operational domain is the current domain. In the example shown in FIG. 3, the registers include a control register that provides a current domain indication 314 indicating which operational domain is the current domain. However, this is not required, and in other architectures, rather than providing a single domain indication identifying the current domain, the current domain may be determined based on two or more items of control state that may be stored in separate registers or in separate portions of the same register. For example, which domain is the current domain may be determined as a Boolean function of control bits accessible from separate system registers.

[0058] The processing circuitry may also support execution of instructions at several exception levels (privilege levels), which may be associated with different privilege levels such that instructions executed at more privileged exception levels have greater rights than instructions executed at less privileged exception levels (e.g., they may perform operations not permitted by code at less privileged exception levels or access register or memory data that is inaccessible to code at less privileged exception levels). Register 312 may specify a current exception level (privilege level) indication 315 that indicates which exception level is the current exception level at which the processing circuitry 310 is operating. The terms exception level and privilege level are used interchangeably in this application.

[0059] The processing circuit 310 can issue a memory access request specifying a virtual address (VA) and a region ID (region ID or “security state”) that identifies the current region. The address translation circuit 316 (e.g., a memory management unit (MMU)) translates the virtual address into a physical address (PA) through one of many stages of address translation based on page table data defined in a page table structure 317 stored in the memory system. The translation lookaside buffer (TLB) 318 functions as a lookup cache to cache a portion of the page table information for faster access than if the page table information had to be fetched from memory each time an address translation was needed. In this example, in addition to generating a physical address, the address translation circuit 316 also selects one of several physical address spaces associated with the physical address and outputs a physical address space (PAS) ID that identifies the selected physical address space. PAS selection is discussed in more detail below.

[0060] PAS filter 320 functions as a requester filtering circuit to determine, based on the translated physical address and the PASID, whether the physical address is permitted to be accessed within the specified physical address space identified by the PASID. This lookup is based on granule protection information stored in a granule protection table structure 321 stored within the memory system. Granule protection information may be cached in a granule protection information cache 322, similar to the caching of page table data within TLB 318. While in the example of FIG. 1, granule protection information cache 322 is shown as a separate structure from TLB 18, in other examples, these types of lookup caches may be combined into a single lookup cache structure, such that a single lookup of an entry in the combined structure provides both page table information and granule protection information. Granule protection information limits the physical address space in which a given physical address may be accessed and defines information that, based on this lookup, PAS filter 320 determines whether to allow a memory access request to proceed being issued to one or more caches 8, 10, 12, 16, 20 and / or interconnect 18. If the PAS specified for the memory access request is not permitted to access the specified physical address, PAS filter 320 may signal a fault and block the effect of the memory access request, for example, by preventing the request from being passed to the memory system.

[0061] While FIG. 3 shows an example in which the selection of a PAS for a given request is performed by the address translation circuit 316, in other examples, information for determining which PAS to select along with the PA can be output by the address translation circuit 316 to the PAS filter 320, which can select a PAS and verify whether the PA can be accessed within the selected PAS.

[0062] The provision of PAS filter 320 helps support a system that can operate in several operating domains, each associated with its own isolated physical address space, where, for at least a portion of the memory system (e.g., for some caches or coherency enforcement mechanisms such as snoop filters), separate physical address spaces are treated as if they refer to separate sets of addresses that identify entirely separate memory system locations, even if the addresses within those address spaces actually refer to the same physical location within the memory system. This can be useful for security purposes.

[0063] To support the memory system resource partitioning and performance monitoring described above, the processing element 6 also includes a partition ID selection circuit 332 for selecting a partition ID to specify for a memory access request sent to a cache, interconnect, or other memory system component, and a partition ID space selection circuit 334 for selecting a partition ID space within which the partition ID is defined. Both the partition ID selection circuit 332 and the partition ID space selection circuit 334 can make their partition ID selection based on control information such as the current region 314, the current exception level 315, and information specified in one or more memory partitioning and monitoring (MPAM) control registers 330, which are described in more detail below.

[0064] Thus, a memory access request sent to a cache, interconnect, or other memory system component specifies a physical address obtained by MMU 316 in address translation, a selected physical address space (PAS) selected by a physical address space selection circuit (e.g., MMU 316 or PAS filter 320) based on the current region 314 and information in page table 317, a partition ID space indicator (MPAM_SP) that identifies the selected partition ID space, and one or more partition IDs (PARTID, PMG) that can be used in combination with the selected partition ID space to control resource control parameter selection or performance monitoring in the memory system component.

[0065] Support for regions associated with each physical address space FIG. 4 shows examples of different operating states and domains in which processing circuitry 310 can operate, as well as examples of the types of software that may run at different exception levels and domains (it will, of course, be understood that the particular software installed on a system is selected by the party managing that system and, therefore, is not an essential feature of the hardware architecture).

[0066] The processing circuit 310 is operable at several different exception levels 80, in this example four exception levels labeled EL0, EL1, EL2, and EL3, where EL3 refers to the most privileged exception level and EL0 refers to the least privileged exception level. It will be appreciated that other architectures may choose the reverse numbering, with the exception level with the highest number considered to be the least privileged. In this example, the least privileged exception level EL0 is for application-level code, the next most privileged exception level EL1 is used for operating system-level code, the next most privileged exception level EL2 is used for hypervisor-level code that manages switching between several virtual operating systems, and the most privileged exception level EL3 is used for monitor code that manages switching between the respective domains and the allocation of physical addresses to the physical address space, as will be described below.

[0067] When an exception occurs at a particular exception level while processing software, for some types of exceptions, the exception is accepted to a higher (more privileged) exception level, and the particular exception level at which the exception is accepted is selected based on attributes of the particular exception that occurred. However, in some circumstances, other types of exceptions may be accepted at the same exception level as the exception level associated with the code that was being processed when the exception was accepted. When an exception is accepted, information characterizing the state of the processor at the time the exception was accepted may be saved, including, for example, the current exception level 315 at the time the exception was accepted. Thus, once an exception handler is processed to address the exception, processing can return to the previous processing, and the saved information can be used to identify the exception level to which processing should return.

[0068] In addition to different exception levels, the processing circuit also supports several operating regions, including a root region 82, a secure (S) region 84, a less-secure region 86, and a realm region 88. For ease of reference, the less-secure region is described below as a “non-secure” (NS) region, although it will be understood that this is not intended to imply a particular level (or lack thereof) of security. Instead, “non-secure” simply indicates that the non-secure region is intended for code that is less secure than code operating in the secure region. The root region 82 is selected when the processing circuit 310 is at the highest exception level, EL3. When the processing circuit is at one of the other exception levels, EL0-EL2, the current region is selected based on a current region indicator 314, which indicates which of the other regions 84, 86, 88 is active. For each of the other regions 84, 86, 88, the processing circuit can be at either exception level, EL0, EL1, or EL2.

[0069] At power-up, some boot code (e.g., BL1, BL2, OEM boot) may execute within, for example, the more privileged exception levels EL3 or EL2. Boot code BL1, BL2 may be associated with, for example, the root region, and OEM boot code may operate in the secure region. However, once the system is booted, during execution, processing circuitry 310 may be considered to operate in one of regions 82, 84, 86, and 88 at a time. Each of regions 82-88 is associated with its own associated physical address space (PAS). This allows for isolation of data from different regions within at least a portion of the memory system, as will be described in more detail below.

[0070] Non-secure region 86 may be used for normal application level processing and operating system and hypervisor activity for managing such applications. Thus, within non-secure region 86 there may be application code 30 running at EL0, operating system (OS) code 32 running at EL1, and hypervisor code 34 running at EL2.

[0071] The secure region 84 allows certain system-on-chip security, media, or system services to be isolated in a physical address space separate from the physical address space used for non-secure processing. The secure and non-secure regions are not equivalent in the sense that non-secure region code cannot access resources associated with the secure region 84, while the secure region can access both secure and non-secure resources. An example of a system that supports such a division of secure and non-secure regions 84, 86 is a system based on the TrustZone® architecture offered by Arm® Limited. The secure region can run trusted applications 36 at EL0, trusted operating systems 38 at EL1, and optionally a secure partition manager 40 at EL2. EL2, when secure partitioning is supported, can use two page tables to support isolation between different trusted operating systems 38 running within the secure region 84, in a manner similar to how the hypervisor 34 can manage isolation between virtual machines or guest operating systems 32 running within the non-secure region 86.

[0072] Extending systems to support secure domains 84 has become common in recent years because it allows a single hardware processor to support isolated secure processing and avoids the need for processing to occur on a separate hardware processor. However, as the use of secure domains has grown in popularity, many practical systems with such secure domains now support a relatively highly mixed environment of services provided within the secure domain by a wide range of different software providers. For example, the code running within secure domain 84 may include different software providers, including (among other providers) silicon providers that fabricate integrated circuits, original equipment manufacturers (OEMs) that assemble integrated circuits provided by the silicon providers into electronic devices such as mobile phones, operating system vendors (OSVs) that provide operating systems 32 for devices, and / or cloud platform providers that manage cloud servers that support services for many different customers via the cloud.

[0073] However, there is a growing demand for providers of user-level code (which might typically be expected to run as applications 30 in non-secure world 86) to be provided with a secure computing environment that can be trusted not to leak information to other parties running code on the same physical platform. It may be desirable for such a secure computing environment to be dynamically allocable during runtime and to be guaranteed and provable, allowing users to verify whether sufficient security guarantees are provided on the physical platform before entrusting the device with processing potentially sensitive code or data. Users of such software may not want to trust providers of feature-rich operating systems 32 or hypervisors 34 that might typically run in non-secure world 86 (or, even if those providers themselves are trustworthy, users may want to protect themselves from unauthorized access to the operating systems 32 or hypervisors 34 by attackers). While secure world 84 can be used for such user-provided applications requiring secure processing, in practice this creates problems for both users who provide code requiring a secure computing environment and providers of existing code running in secure world 84. For providers of existing code running in secure area 84, the attack surface for potential attacks against their code increases with the addition of arbitrary user-provided code within the secure area. This may be undesirable, and users may therefore be strongly discouraged from allowing code to be added to secure area 84. On the other hand, users who provide code that requires a secure computing environment may be reluctant to trust access to their data or code to all of the different code providers running in secure area 84, as it may be difficult to audit and certify all of the separate code provided by different software providers running in secure area 84 if assurances and certifications of the code running in a particular area are required as a prerequisite for the user-provided code to perform operations.This may limit opportunities for third parties to offer more secure services.

[0074] Thus, as shown in FIG. 4 , an additional region 88, called a realm region, is provided that can be used by such user-introduced code to provide a secure computing environment that is orthogonal to any secure computing environment associated with components operating in the secure region 84. In the realm region, the executing software can include several realms, each of which can be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 can control the isolation between the respective realms 42, 44 that execute in the realm region 88 by defining access permissions and address mappings within page table structures, for example, similar to how the hypervisor 34 manages the isolation between different components operating in the non-secure region 86. In this example, the realms include an application-level realm 42 that executes at EL0 and an encapsulated application / operating system realm 44 that executes across exception levels EL0 and EL1. It will be appreciated that supporting both EL0 and EL0 / EL1 type realms is not required, and multiple realms of the same type can be established by the RMM 46.

[0075] The realm region 88, like the secure region 84, has its own physical address space assigned to it; however, it is orthogonal to the secure region 84 in the sense that the realm region and the secure region 88, 84 each have access to the non-secure PAS associated with the non-secure region 86, but the realm region and the secure region 88, 84 cannot access each other's physical address space. This means that code running in the realm region 88 and the secure region 84 have no dependencies on each other. Code within the realm region trusts only the hardware, the RMM 46, and the code running in the root region 82, which manages switching between regions, which means that attestation and certification are more feasible. Attestation allows a given software to request verification that code installed on a device matches certain expected characteristics. This can be done by checking whether a hash of program code installed on the device matches an expected value signed by a trusted party using a cryptographic protocol. The RMM 46 and monitor code 29 may be attested by, for example, checking whether a hash of this software matches an expected value signed by a trusted party, such as the silicon provider that manufactured the integrated circuit that includes the processing system 2, or the architecture provider that designed the processor architecture that supports region-based memory access control. This allows the user-provided code 42, 44 to verify that the integrity of the region-based architecture can be trusted before performing any secure or sensitive functions.

[0076] Thus, as shown by the dotted lines indicating gaps in the non-secure realm where these processes would previously have executed, it can be seen that code associated with realms 42, 44 that would previously have executed in the non-secure realm 86 can now be moved to the realm realm where they may have stronger security guarantees because their data and code cannot be accessed by other code running in the non-secure realm 86. However, due to the fact that the realm realm 88 and the secure realm 84 are orthogonal and therefore cannot see each other's physical address space, this means that providers of code in the realm realm do not need to trust providers of code in the secure realm, and vice versa. Code in the realm realm can simply trust the firmware that provides the root realm 82 and the monitor code 29 of the RMM 46, which may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor. These providers may need to be inherently trusted from the start when code is running on their device, so that no additional trust relationships with other operating system vendors, OEMs, or cloud hosts are required by users in order for them to be provided with a secure computing environment.

[0077] This is useful for a variety of purpose applications and use cases, including, for example, mobile wallet and payment applications, fraud and piracy prevention mechanisms in games, operating system platform security extensions, secure virtual machine hosting, confidential computing, networking, or gatewaying for the Internet of Things. Users will appreciate that they may find many other applications in which Realm support is useful.

[0078] To support the security assurances provided to a Realm, a processing system may support an attestation reporting function, whereby firmware images and configurations, e.g., monitor code images and configurations, or RMM code images and configurations are measured at boot time or during runtime. During runtime, the contents and configurations of the Realm are measured, allowing the Realm Owner to trace back relevant attestation reports to known implementations and assurances and make trust decisions about whether to operate on that system.

[0079] As shown in FIG. 4 , a separate root region 82 is provided to manage region switching, with the root region having its own isolated root physical address space. Creating a root region and isolating resources from the secure region allows for a more robust implementation, even in systems with only non-secure and secure regions 86 and 84 and no realm region 88, but it can also be used in implementations that support the realm region 88. The root region 82 can be implemented using monitor software 29 provided (or certified) by the silicon provider or architecture designer and can be used to provide secure boot functionality, trusted boot measurements, system-on-chip configuration, debug control, and firmware update management for firmware components provided by other parties, such as the OEM. Code in the root region can be developed, certified, and deployed by the silicon provider or architecture designer without dependency on the final device. In contrast, the secure region 84 can be managed by the OEM to implement specific platform and security services. Management of the non-secure realm 86 may be controlled by the operating system 32, which provides operating system services, while the realm realm 88 is mutually isolated from existing secure software environments in the secure realm 84 while allowing the development of new forms of trusted execution environments that may be dedicated to user or third-party applications.

[0080] 5 illustrates the concept of aliasing the respective physical address spaces on the physical memory provided in the hardware. As previously mentioned, each of the regions 82, 84, 86, 88 has its own respective physical address space 61.

[0081] At the time a physical address is generated by the address translation circuit 316, the physical address has a value within a particular numeric range 62 supported by the system, which is the same regardless of which physical address space is selected. However, in addition to generating the physical address, the address translation circuit 316 may also select a particular physical address space (PAS) based on information in the current region 14 and / or the page table entry used to derive the physical address. Alternatively, instead of the address translation circuit 316 performing the PAS selection, the address translation circuit (e.g., an MMU) can output a physical address and information derived from a page table entry (PTE) that is used to select the PAS, which can then be used by the PAS filter 320 to select the PAS.

[0082] The selection of a PAS for a given memory access request may be limited depending on the current domain in which the processing circuit 310 operates when issuing the memory access request, according to the rules defined in the table below.

[0083] [Table 1]

[0084] For regions where there are multiple physical address spaces available to choose from, information from the accessed page table entry used to provide the physical address is used to select between the available PAS options.

[0085] Thus, by the time PAS filter 320 outputs a memory access request to the system fabric (assuming it passes any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0086] From the perspective of memory system components (caches, interconnects, snoop filters, etc.) operating before the Point of Physical Aliasing (PoPA) 60, each physical address space 61 is seen as an entirely separate address range corresponding to a different system location in memory. This means that from the perspective of the pre-PoPA memory system components, the address range identified by a memory access request is actually four times the size of the range 62 that may be output in the address translation. This is because the PASID is effectively treated as additional address bits alongside the physical address itself, so that the same physical address PAx may be mapped to several aliased physical addresses 63 within the separate physical address spaces 61, depending on the PAS selected. These aliased physical addresses 63 all actually correspond to the same memory system location implemented in physical hardware, but the pre-PoPA memory system components treat the aliased addresses 63 as separate addresses. Therefore, if there is a pre-PoPA cache or snoop filter that allocates entries to such addresses, the aliased addresses 63 will be mapped to different entries with separate cache hit / miss determinations and separate coherency management. This reduces the likelihood or effectiveness of an attacker using cache or coherency side channels as a mechanism to probe the behavior of other domains.

[0087] A system may include two or more PoPAs 60 (e.g., separate PoPAs may be implemented on separate paths, thereby routing memory access requests to separate subsets of receiving memory system components). In each PoPA 60, aliased physical addresses are folded into a single unaliased address 65 within the system physical address space 64. The unaliased address 65 is provided downstream to any post-PoPA components, so that the system physical address space 64, which actually identifies memory system locations, is again the same size as the range of physical addresses that may be output in the address translation performed at the requester side. For example, in the PoPA 60, the PASID may be stripped from the address, and for downstream components, the address may be identified simply using the physical address value without specifying the PAS. Alternatively, if some completer-side filtering of memory access requests is desired, the PASID may still be provided downstream of the PoPA 60, but may not be interpreted as part of the address. As a result, the same physical address appearing in separate physical address spaces 60 will be interpreted downstream of the PoPA to point to the same memory system location. However, the supplied PASID can still be used to perform completer-side security checks.

[0088] 6 illustrates how system physical address space 64 can be divided into chunks allocated for access within a particular architectural physical address space 61 using a granule protection table 321. Granule protection table (GPT) 321 defines which portions of system physical address space 64 are accessible from each architectural physical address space 61. For example, GPT 321 may contain several entries, each corresponding to a particular size granule of physical addresses (e.g., 4K pages, or granules of another size), and may define the assigned PAS for that granule, which may be selected from among non-secure, secure, realm, and root regions. By design, if a particular granule or set of granules is assigned to a PAS associated with one of the regions, it can only be accessed within the PAS associated with that region and cannot be accessed within the PASs of other regions. Note, however, that even though granules allocated to (for example) the secure PAS are not accessible from within the root PAS, the root region 82 can still access that granule of physical addresses by specifying PAS selection information in its page table 317 to ensure that virtual addresses associated with pages mapped to that area of ​​physically addressed memory are translated to physical addresses in the secure PAS instead of the root PAS. Thus, sharing of data between regions (to the extent permitted by the accessibility rules defined in the table above) can be controlled at the time of selecting a PAS for a given memory access request.

[0089] However, in some implementations, in addition to enabling access to granules of physical addresses within the assigned PAS defined by the GPT 321, the GPT can use other GPT attributes to mark a region of address space (e.g., an address space associated with a region of lower or orthogonal privilege that would not normally be permitted to select the assigned PAS for access requests for that region) as shared with another address space. This can facilitate temporary sharing of data without having to change the assigned PAS for a given granule. For example, in FIG. 6 , realm PAS region 70 is defined in the GPT to be assigned to the realm region and is normally inaccessible from non-secure region 86 because non-secure region 86 cannot select the realm PAS for its access requests. Because non-secure region 86 cannot access the realm PAS, non-secure code would not normally be able to see data in region 70. However, if a realm wants to temporarily share some of its data in its allocated region of memory with a non-secure region, it can request that monitor code 29 running in root region 82 update GPT 321 to indicate that region 70 is shared with non-secure region 86, thereby making region 70 accessible from the non-secure PAS shown on the left side of FIG. 6 without having to change which regions are allocated to region 70. When a realm region designates a region of its address space as shared with a non-secure region, a memory access request issued from the non-secure region and targeting that region may initially specify the non-secure PAS, but PAS filter 20 can remap the request's PASID to instead specify the realm PAS. Downstream memory system components then treat the request as if it had originally issued from the realm region. This sharing can improve performance because the operations for assigning different regions to specific memory regions can be more performance-intensive, involving a higher degree of cache / TLB invalidation and / or data zeroing in memory or copying data between memory regions.This may not be justifiable if the sharing is expected to be only temporary.

[0090] Issuing a memory access request 7 is a flow diagram illustrating steps performed when issuing a memory access request from a processing element 6. In step 100, the processing circuit 310 processes instructions in one of at least three regions each associated with a corresponding physical address space. In step 101, the processing circuit determines whether to issue a memory access request. The memory access request may be a data access request triggered by the execution of a load / store instruction, or an instruction fetch access request, which is caused by the instruction fetch stage 300 issuing a fetch request to fetch an instruction from memory or an instruction cache (or by a prefetcher issuing a prefetch request to prefetch an instruction into the instruction cache by the instruction fetch stage 300 before the instruction is actually needed). If there is no memory access request to currently issue, processing continues at step 100.

[0091] When there is a memory access request to issue, in step 102, MMU 316 translates the virtual address specified for the memory access into a physical address, and physical address selection circuitry (e.g., MMU 316 or PAS filter 320) selects an output PAS based on the current region 314 and the information specified in the page table entry from page table 317 that corresponds to the virtual address of the memory access.

[0092] FIG. 8 illustrates step 102 of FIG. 7 in more detail. In step 130 of FIG. 8, the processing circuit 310 issues a memory access request specifying a given virtual address (VA) as the target VA. In step 132, the address translation circuit 316 looks up any page table entries (or cache information derived from such page table entries (PTEs)) in its TLB 318. If any necessary page table information is not available, the address translation circuit 316 initiates a page table walk to memory to fetch the necessary PTEs (potentially requiring a series of memory accesses to step through each level of the page table structure and / or multiple stages of address translation to obtain the mapping from VA to intermediate address (IPA) and from IPA to PA). Any memory access request issued by the address translation circuit 316 in a page table walk operation may itself be subject to address translation and PAS filtering. Note that the request received in step 130 may therefore be a memory access request issued to request a page table entry from memory. Once the relevant page table information is identified, the virtual address is translated to a physical address (possibly in two stages via the IPA). In step 134, the address translation circuit 316 or PAS filter 320 determines which region is the current region (if the current exception level 315 is EL3, the current region is the root region; if the current exception level 315 is EL2, EL1, or EL0, the current region is one of the non-secure region, secure region, and realm region, as indicated by the current region indication 314).

[0093] If the current region is a non-secure region, then in step 136 the output PAS selected for this memory access request is a non-secure PAS.

[0094] If the current region is a secure region, then in step 138 the output PAS is selected based on the PAS selection information contained in the PTE that provided the physical address, and the output PAS will be selected as either a secure PAS or a non-secure PAS.

[0095] If the current region is a realm region, then in step 140 the output PAS is selected based on the PAS selection information contained in the PTE from which the physical address was derived, in which case the output PAS is selected as either a realm PAS or a non-secure PAS.

[0096] If step 134 determines that the current region is a root region, then step 142 selects an output PAS based on the PAS selection information in PTE 114 from which the physical address was derived. In this case, the output PAS is selected as one of the physical address spaces associated with the root, realm, secure, and non-secure regions.

[0097] 8 illustrates the selection of a PAS based on information defined in the PTE of page table 317, an alternative approach may provide a separate data structure that specifies the PAS to use for each VA, independent of page table 317. In practice, however, some space may be available within the PTE for specifying the PAS selection information, and combining the PAS selection information with the page table information avoids the need to look up a second structure in addition to TLB 318 or page table 317, which helps to save power and reduce circuit area.

[0098] Returning to FIG. 7, once an output PAS is available, in step 103, PAS filter 320 initiates a PAS filter check based on the physical address (PA) and the output PAS selected in step 102. Step 103 is shown in more detail in FIG. 9. In step 160 of FIG. 9, PAS filter 320 receives a memory access request specifying a PA and an output PAS, and in step 162, PAS filter 320 retrieves a granule protection table entry corresponding to the physical address of the memory access from granule protection table 321. (The GPT entry can be retrieved from GPT cache 322 if the PA hits in GPT cache 322; otherwise, it can be retrieved by performing an access to GPT 321 in memory.) In step 164, PAS filter 320 determines whether the retrieved granule protection table entry GPT[PA] corresponding to the target PA indicates that the granule of address space corresponding to the target PA is permitted to be accessed within the output PAS selected in step 102. If so, the memory access is allowed to proceed in step 166. If the GPT entry corresponding to a particular physical address indicates that the granule corresponding to the physical address is not allowed to be accessed in the output PAS selected in step 102, then in step 168 the memory access request is blocked and prevented from being issued to a cache, interconnect, or other memory system component, or, in systems that allow memory access requests to be speculatively issued before the checks performed by the PAS filter are complete, the PAS filter can take action to cancel the effects of the memory access request. For example, the PAS filter can issue control signals that cause state changes in memory caused by the memory access request to be reversed, or that cause state returned from memory in response to the memory access request to not be used to update registers that would otherwise be accessible to software.

[0099] The format of the information included in a GPT entry to specify whether a given granule may be allowed to be accessed within a given output PAS may vary from implementation to implementation. In some implementations, a GPT entry may support only allowing the use of one specific PAS for a given PA, in which case the check may be simply whether the output PAS matches the allowed PAS specified in the GPT entry accessed in step 162. Other embodiments may support multiple allowed output PASs for the same physical address, in which case the check may be whether the output PAS is any of one or more allowed PASs specified by the GPT entry for the PA.

[0100] Returning to FIG. 7 , in response to issuing memory access request 101, at step 104, partition ID selection circuit 332 selects a partition ID (e.g., PARTID and / or PMG, as described in more detail below) based on programmable partition ID selection information associated with the current execution environment. For example, the partition ID selection information can be obtained from MPAM control registers 330. Each software execution environment may be associated with a particular set of MPAM states stored in MPAM control registers 330, and this MPAM state may be part of the context information for that software execution environment that is saved / restored when context switches between execution environments. Thus, when switching from one software execution environment to another, the context associated with the incoming software execution environment can be written to the register, including updating MPAM control register 330 to specify the MPAM state associated with the successor software execution environment. Partition ID selection may also be based on the current exception level 315 and / or the type of access being performed (e.g., whether the access is an instruction fetch access or a data access). Partition ID selection is shown in more detail in FIGS. 13A and 13B, described below.

[0101] Also in step 105, partition ID space selection circuit 334 selects a partition ID space based on current region 340 (and optionally also based on programmable control information and / or current exception level 350, which may be specified in MPAM control register 330). Partition ID space selection is shown in more detail in Figures 14 and 15, which are described further below. While Figure 7 shows steps 104 and 105 being performed in parallel with steps 102 and 103, in other examples, these may occur sequentially. Also, while step 105 is shown as being performed sequentially after step 104, in other embodiments, step 105 may occur before step 104, or steps 104 and 105 may occur in parallel.

[0102] In step 106, a memory access request is issued to the memory system (e.g., a cache, interconnect, or other memory system component) specifying the physical address obtained by MMU 316 in step 102, a PAS indicator indicating the output PAS selected in step 102, a partition ID space indicator (MPAM_SP) indicating the selected partition ID space selected in step 105, and one or more selected partition IDs selected in step 104. The partition ID space indicator MPAM_SP is a multi-bit value and can indicate one of at least three different partition identification spaces corresponding to respective regions in which the processing circuitry is executable. In an embodiment such as that shown in FIG. 4, which supports four different regions (non-secure, secure, realm, and root), MPAM_SP can distinguish four different partition ID spaces, each corresponding to one of those regions. For example, MPAM_SP can have a two-bit encoding as follows (of course, other encodings are possible): ·Non-secure partition ID space: 0b01; ·Secure partition ID space:0b00; ·Realm partition ID space 0b11; Root partition ID space 0b10.

[0103] Partition ID and Partition ID Space Selection Figure 10 shows an example of the MPAM control register 330 shown in Figure 3. The MPAM control register 330 includes several partition ID registers MPAMi_ELj 340, 342, 344, 346, where i indicates the exception level at which the register is used to provide the partition ID and j indicates the lowest privileged exception level at which the information in the register can be updated. Thus, MPAM0_EL1 340 provides a partition ID for use at exception level EL0 and can be updated by code running at exception level EL1 or higher.

[0104] The MPAM control register 330 also includes a discovery register, MPAMIDR_EL1 348, which is shown in more detail in Figure 11 and is used to provide information about the hardware capabilities of a processor implementation so that software can discover which features are implemented on the hardware. As shown in Figure 11, the discovery register 348 may include a partition ID maximum value 370, 372 that indicates the maximum value allowed for the resource control partition ID (PARTID) and performance monitoring group (PMG) fields of the partition ID registers 340, 342, 344, 346. This allows different hardware implementations to support different numbers of bits in these IDs, and software can read the discovery register maximum fields 370, 372 to learn the maximum partition ID value supported by the hardware.

[0105] The discovery register 348 also includes a field SP4 374 to indicate whether the hardware implementation supports a four-partition ID space, corresponding to non-secure, secure, realm, and root states, as shown in FIG. 4 above. Because not all hardware implementations may support a four-partition ID space, the 4-space support field 374 may be useful for software to identify whether it can use additional partition ID spaces. In an implementation having a partition ID space selection circuit 334 that supports a four-partition ID space, the SP4 field 374 may be set to 1. The SP4 field 374 may be present in a bit in the discovery register 348, and this field would be set to 0 in legacy devices that do not support a four-partition ID space.

[0106] The discovery register also includes an alternate partition ID space support indication field 376 that indicates whether the hardware implementation supports providing an alternate partition ID space, as described further below. In implementations that do not support providing an alternate partition ID space, each region will be limited to using its primary partition ID space field 376, which will be set to 0. (Again, field 376 may be present in a bit of the discovery register, and this field will be set to 0 on legacy devices.) In implementations that support providing an alternate partition ID space, the HAS_ALTSP field 376 is set to 1.

[0107] 12 shows partition ID registers 340, 342, 344, and 346 in more detail. These registers contain information for selecting the partition ID to accompany a memory access request when sent to the memory system and for selecting the partition ID space to indicate for the memory access request. The state in partition ID registers 340, 342, 344, and 346 can be considered part of the context information associated with a given software execution environment executing on the processing circuit. When a context switch occurs, registers 340, 342, 344, and 346 are updated with the context information associated with the successor software execution environment.

[0108] Each partition ID register 340-346 includes several partition ID fields 350, 352, 354, 356 to provide the partition ID to use for software running at the corresponding exception level. In this example, there are four fields including a data (resource partition) partition ID (PARTID_D) field 350, an instruction (resource partition) partition ID (PARTID_I) field 352, a data performance monitoring group ID (PMG_D) field 354, and an instruction performance monitoring group ID (PMG_I) field 356.

[0109] Fields 350, 354 are used for data memory accesses, and fields 352, 356 are used for instruction fetch memory accesses.

[0110] Fields 350, 352 provide a resource partition ID to use for data access and instruction fetch, respectively. A memory system component can use the partition ID selected based on the value of one of resource partition partition ID fields 350, 352 to control allocation of resources such as cache capacity or memory bus bandwidth, or to manage contention between different requests (e.g., by selecting request priorities based on the partition ID).

[0111] The performance monitor group fields 354, 356 provide an ID used to control whether performance monitor data is updated based on the performance monitor group ID. In some embodiments, the performance monitor group ID in fields 354, 356 can be considered a standalone ID separate from the resource control partition ID fields 350, 352. However, in other embodiments, the performance monitor group ID 354, 356 may be several additional bits that can be used in conjunction with the resource control partition ID 350, 352, in which case the performance monitor group ID value used by memory system components to control performance monitoring may be a concatenation of the selected partition ID and the selected performance monitor group ID, rather than considering the values ​​in fields 354, 356 as independent IDs. For example, the PMG fields 354, 356 may be considered a prefix or suffix to the corresponding one of the PARTID fields. Whether the PMG fields 354, 356 are interpreted independently of the PARTID value or read in combination with the PARTID value, defining a performance monitoring group ID 354, 356 allows for distinguishing, for performance monitoring purposes, between separate subsets of requests that share the same resource partition ID.

[0112] It will be appreciated that it is not necessary to provide separate partition IDs for resource partitioning (using fields 350, 352) and performance monitoring and control (using fields 354, 356). In other embodiments, the same ID may be used for both purposes, or some implementations may support only one of resource allocation partitioning and performance monitoring and control partitioning, but not both, and therefore may not provide both types of fields.

[0113] Also, separate support for instruction and data partition IDs is not required; in other embodiments, a common ID can be provided for both purposes. It may be useful to allow separate partition IDs to be defined for data and instruction accesses of the same software execution environment, allowing different resource control parameters to be used for corresponding instruction and data accesses. An alternative approach is to have one partition ID associated with the software execution environment as a whole, but add an additional bit of 0 or 1 depending on whether the access is for instructions or data, allowing memory system components to select different control parameters for instruction and data accesses, respectively. However, for a given number of sets of control parameters selected based on the partition ID, this approach would mean that the partition ID space would need to be split 50 / 50 between data and instructions. In practice, it is often desirable to have more data partitions than instruction partitions, since it may be relatively common for multiple software execution environments to use the same code but run with different data inputs; therefore, it may be particularly useful to allow a single instruction partition ID to be shared between multiple software execution environments, each using a different data partition. The approach of adding a 0 or 1 bit to indicate instruction or data access would, in that situation, require defining multiple sets of identical configuration information in the memory system components for each separate instance of the common code. In contrast, by providing separate instruction and data partition fields in partition ID registers 340-346 (where the instruction and data partition IDs are selected from a common ID space), the same partition ID can be reused between different software execution environments, and the partition ID space can be split between data and instruction as needed, without constraining the partition ID space to 50 / 50.Although additional storage capacity is required for twice the partition ID fields in each partition ID register 340-346, this approach conserves resources in the memory system components by requiring a smaller set of control parameters (and therefore less storage capacity) in the memory system components by sharing a single partition among instruction accesses of multiple execution environments.

[0114] FIG. 13A illustrates a method for controlling the selection of a partition ID to be specified for a memory access request. The technique illustrated in FIG. 13A can be used for data access memory transactions. In step 110, processing circuit 310 issues a data access (load / store) memory access request, for example, in response to a load / store instruction executed by execution unit 304. In step 112, partition ID selection circuit 332 reads one of partition ID registers 340, 342, 344, 346 selected according to the current operating state of the processor. For example, partition ID selection circuit 332 can select one of partition ID registers 340, 342, 344, 346 corresponding to current exception level 315 (e.g., register 340 if the current exception level is EL0; register 342 if the current exception level is EL1; register 344 if the current exception level is EL2; or register 346 if the current exception level is EL3). In some implementations, it may be possible to define additional control state information in the control registers that can change which partition ID register is selected for a particular exception level, away from the default of using registers 340-346 associated with the current exception level. For example, a parameter can be set to force the use of the partition ID in register MPAM1_EL1 342 if the current exception level is EL0; this is useful if the operating system wants the applications it is managing to use the same partition ID as the operating system itself, as defined in MPAM1_EL1 342, thereby avoiding the need for the operating system to set the partition ID value in MPAM0_EL1 340. Thus, in some systems, some control state can influence the selection of MPAM registers other than the current exception level, although this is not required.

[0115] In step 118, because the current memory access request is a data access request, the PMG_D and PARTID_D fields 354, 350 are read from one of the registers 340, 342, 344, 346 selected in step 112. In step 120, the partition ID selection circuit 332 determines whether partition ID virtualization is implemented and enabled for the partition ID read from the selected register in the current operating state. For processes executing as EL2 or EL3, virtualization does not need to be performed. For software execution environments at EL0 or EL1, if virtualization is supported by hardware, whether virtualization is currently enabled may depend on information specified in a control register (e.g., controlled by a hypervisor executing at EL2). If partition ID virtualization is implemented in hardware and is currently enabled for the current exception level, in step 122, the partition ID selection circuit 332 performs virtual-to-physical partition ID mapping to map the virtual partition ID value read in step 118 to a corresponding physical partition ID value based on the mapping information configured for the current execution environment. For example, a hypervisor may maintain a partition ID remapping table that may be used to implement partition ID remapping. This may be useful to allow separate guest operating systems that may define conflicting partition ID values ​​to coexist on the same system without conflict, so that the conflicting virtual partition ID values ​​can be remapped to separate physical partition ID values, and the access requests of each operating system can be differentiated in memory system components to perform individual resource allocation control or performance monitoring.The mapping table can be implemented in a variety of different ways, for example, a set of partition ID remapping registers can be provided to specify physical partition ID values ​​that correspond to different values ​​of virtual partition IDs read from registers 340, 342, 344, and 346, or a remapping structure stored in memory can be used to provide the mapping table. If virtualization is implemented and enabled and partition IDs are remapped to physical partition IDs in step 122, then in step 150 the remapped partition IDs are output along with memory access requests (after the requests have undergone any necessary address translation and PAS filtering) for transmission to a cache, interconnect, or other memory system component. If virtual-to-physical partition ID mapping is not implemented in or is not currently enabled in the hardware device, step 122 is omitted and in step 150 the partition IDs read from selected registers 340-346 are simply output in their original format without remapping.

[0116] FIG. 13B illustrates a method for selecting a partition ID for an instruction fetch access memory transaction. In step 111 of FIG. 13B, processing circuitry 310 issues an instruction fetch memory access request, requesting the fetching of an instruction for a given address. The instruction fetch request may be made by fetch circuitry 300 when the instruction actually needs to be fetched for execution, or some implementations may have prefetch circuitry that prefetches instructions into an instruction cache ahead of the time the instructions are actually needed for execution, so that the prefetch circuitry can also generate the instruction fetch memory access request. In response to issuing an instruction fetch memory access request, steps 112-150 of FIG. 13B are the same as those of FIG. 13A for a data access request, except that step 118 of FIG. 13A is replaced by step 116 of FIG. 13B, in which the PMG_I and PARTID_I fields 356, 352 are read from the selected partition ID register instead of the PMG_D and PARTID_D fields 354, 350. Steps 120, 122, and 150 are the same except that the instruction partition ID value from fields 356, 352 is used instead of the data partition ID value from fields 354, 350.

[0117] 12, some of the partition ID registers also contain control state information for controlling the selection of the partition ID space used for a given memory access request. Each region supported by the processing circuit has a corresponding primary partition ID space associated with it. The control state in registers 344, 346 can be used to select whether to use the primary partition ID space or the alternate partition ID space. This control state information includes the following:

[0118] In MPAM3_EL3346: · Root Alternate Space Selection Information (RT_ALTSP_NS) 360 used by code in EL3 to select whether the alternate partition ID space for the root region is a secure partition ID space or a non-secure partition ID space; · EL3 partition ID space selection information (ALTSP_EL3 362) used to select whether to use the primary or alternate partition ID space for memory accesses issued in EL3; EL3 Control Hierarchical Forced Space Selection Information (ALTSP_HFC) 364, which provides programmable space selection control information at EL3 to control the selection of whether to use the primary or alternate partition ID space for accesses made from EL2, EL1, and EL0 when hierarchical control is disabled using ALTSP_HEN 366; Hierarchy control enable information (ALTSP_HEN) 366, which controls whether hierarchical control is enabled or disabled. When hierarchical control is enabled, instructions executing at EL2 can affect the selection between the primary partition ID space and the alternate partition ID space for accesses made from EL2, EL1, or EL0. When hierarchical control is disabled, instructions executing at EL2 cannot affect the selection between the primary partition ID space and the alternate partition ID space for accesses made from EL2, EL1, or EL0, and the selection between the primary partition ID space and the alternate partition ID space for accesses made from EL2, EL1, or EL0 depends on ALSTP_HFC 364, which is set by instructions executing at EL3 in register MPAM3_EL3 346. In MPAM2_EL2344: EL2 tier forced space indication information (ALTSP_FRCD) indicating whether code running in EL3 forced the selection of an alternate partition ID space for code running in EL2; EL2 partition ID space selection information (ALTSP_EL2) 372, which is information set by code running in EL2 and controls whether code running in EL2 should use the primary partition ID space or the alternate partition ID space when tiering control is enabled using MPAM3_EL3.ALTSP_HEN 366; EL2 Controlled Hierarchical Forced Space Selection Information (ALTSP_HFC) 374, programmable partition ID space selection information set in EL2 that specifies whether code running at EL0 or EL1 should use the primary or alternate partition ID space when hierarchical control is enabled by MPAM3_EL3.ALTSP_HEN 366; ·In MPAM1_EL1 342, EL1 tier forced space indication information (ALTSP_FRCD) 380, which indicates to code running at EL1 whether the selection of an alternate partition ID space was forced on code running at EL1 by code running at EL3 or EL2.

[0119] The options supported by these partition ID selection controls are outlined below.

[0120] If the alternate partition ID space feature (ALTSP) is supported by the hardware as indicated by field 376 in the discovery register, an alternate partition ID space is supported for each security state (region) other than non-secure (the non-secure partition ID space is used regardless of whether the controls in registers 344, 346 indicate that a primary / alternate space is selected). Similarly, the non-secure security state can still be considered to have an alternate partition ID space, but that alternate partition ID space is the same as the primary partition ID space. Thus, the primary and alternate partition ID spaces supported per region are as follows:

[0121] [Table 2]

[0122] The selection of the alternate space for root is made in MPAM3_EL3 346 in RT_ALTSP_NS field 360. A 0b1 in this field selects the non-secure partition ID space as the alternate partition ID space for the root security state. If RT_ALTSP_NS is 0b0, the secure partition ID space is selected as the alternate partition ID space for the root security state.

[0123] When executing in EL3, the processing element is in the root security state. The selection of the primary or alternate partition ID space for memory system requests made in the root security state is controlled by a bit in MPAM3_EL3 346.

[0124] RT_ALTSP_NS 360 sets whether the alternate partition ID space for the root security state is a non-secure partition ID space or a secure partition ID space.

[0125] ALTSP_EL3 362 sets whether memory system requests generated from EL3 use the primary partition ID space or the alternate partition ID space.

[0126] Combining these two bits gives three combinations of partition ID space used for access from EL3 in root state:

[0127] [Table 3]

[0128] When executing at EL2, EL1, or EL0, the security state can be secure, non-secure, or realm security state. Root software running at EL3 can allow EL2 to control its own partition ID space and the partition ID space used by EL1 and EL0, or can force EL2, EL1, and EL0 to select the primary or alternate space.

[0129] If EL3 has enabled alternate space control in MPAM2_EL2 344 (i.e., hierarchical control is enabled as indicated by MPAM3_EL3.ALTSP_HEN 366), EL2 can select whether partition IDs generated in EL2 use the primary or alternate partition ID space via MPAM2_EL2.ALTSP_EL2 370. If EL3 has enabled alternate space control in MPAM2_EL2 344, EL2 can also select whether the primary or alternate partition ID space is used by EL1 and EL0. EL3 forces the selection on all lower ELs by clearing MPAM3_EL3.ALTSP_HEN 366 and setting MPAM3_EL3.ALTSP_HFC 364 to force the alternate partition ID space, or clearing ALTSP_HFC 364 to force the primary partition ID space on all lower ELs.

[0130] The combinations for EL2 and the set of combinations for EL1 and EL0 are shown in the table below.

[0131] [Table 4]

[0132] In each of MPAM2_EL2 344 and MPAM1_EL1 342, fields ALTSP_FRCD 370, 380 indicate that the alternate partition ID space is forced to the partition ID in MPAM2_EL2 and the partition ID in MPAM1_EL1 and MPAM0_EL1, respectively. Because the selection of EL1 and EL0 is always the same, and EL1 controls the partition ID in MPAM0_EL1, there is no need for a separate indication in MPAM0_EL1 340.

[0133] 14 is a flow diagram illustrating the selection of a partition ID space by the partition ID space selection circuit 334. In step 170, the partition ID space selection circuit 334 determines whether the programmable control information in registers 344, 346 specifies the use of the primary partition ID space or the use of the alternate partition ID space. If the primary partition ID space is to be used, in step 172, the selected partition ID space indicated by the partition ID space indicator MPAM_SP for the issued memory access request is the primary partition ID space associated with the current region. If the alternate partition ID space is to be used, in step 176, the selected partition ID space indicated by MPAM_SP is the alternate partition ID space associated with the current region. This alternate partition ID space may be fixed as the non-secure partition ID space if the current region is a realm, secure, or non-secure region, or may be programmable as either the secure or non-secure partition ID space for the root region depending on the root alternate space selection information MPAM_EL3.RT_ALTSP_NS 360 set in MPAM3_EL3 346 by code running at EL3.

[0134] Figure 15 is a flow diagram illustrating in more detail the criteria for selecting between the primary partition ID space and the alternate partition ID space in step 170 of Figure 14. In step 180, the partition ID space selection circuit 334 determines whether the current privilege level is EL3, and if so, in step 182, uses the EL3 space selection information (MPAM3_EL3.ALTSP_EL3 362) set by the code running in EL3 to select between the primary partition ID space and the alternate partition ID space.

[0135] If the current privilege level is EL2, EL1, or EL0, then in step 184, the partition ID space selection circuit 334 determines whether tier control for partition ID space selection is enabled by EL3. For example, the circuit 334 determines whether the tier enable value MPAM3_EL3.ALTSP_HEN 366 has a first value or a second value. If ALTSP_HEN 366 has a first value (e.g., 1), tier control is enabled, and if ALTSP_HEN 366 has a second value (e.g., 0), tier control is disabled.

[0136] If tier control is disabled by code running at EL3, the code running at EL3 determines whether to use the primary / alternate partition ID space for code running at EL2, EL1, or EL0. Thus, in step 186, the selection between the primary and alternate partition ID spaces used by EL2, EL1, or EL0 is made using the tier enforcement space selection information MPAM3_EL3.ALTSP_HFC 364 set by the code at EL3. Thus, in this case, the code running at EL2 does not affect whether it or the code running at EL1 or EL0 should use the primary or alternate partition ID space.

[0137] If hierarchical control over partition ID space selection is enabled by EL3 (ALTSP_HEN 366 has a first value), then in step 188, the partition ID space selection circuit 334 determines whether the current privilege level is EL2 or one of EL1 and EL0. If the current privilege level is EL2, then in step 190, a selection between the primary partition ID space and the alternate partition ID space is made using EL2 space selection information MPAM2_EL2.ALTSP_EL2 372 set by code at EL2 in register 344. On the other hand, if the current privilege level is EL1 or EL0, then in step 192, a selection between the primary partition ID space and the alternate partition ID space is made using hierarchical force selection information MPAM2_EL2.ALTSP_HFC 374 set in register 344 by code running at EL2.

[0138] It will be appreciated that although the flow diagrams described above show steps occurring in a particular order or sequence, in other implementations the order of those steps may be rearranged or some of the steps may be performed in parallel.

[0139] In summary, by using programmable control information in registers, partition IDs can be defined within one of four partition ID spaces corresponding to each operating region, as described above, and software has flexibility as to whether it actually needs to use all four of the supported partition ID spaces, or whether some software may prefer to use an alternate partition ID space to enable sharing of a common partition ID space among software operating in various different security states. If software can share a common partition ID space, the number of sets of resource control parameters defined for memory system components can be reduced for each combination of partition ID and partition ID space currently in use, reducing software management overhead.

[0140] Partition ID and Partition ID Space Memory System Component Use 16 illustrates an example of circuitry within a memory system component, which may be, for example, a cache 8, 10, 12, 16, 20, control circuitry within an interconnect 14, 18, or memory controller 24. A memory access request is received by a memory system component, which specifies the physical address (PA) of the access, a partition ID space indicator MPAM_SP, and one or more partition IDs (e.g., resource control partition ID (PARTID) and performance monitoring group ID (PMG)), as described above. If the memory system component is a pre-Physical Aliasing Point (PoPA) component located upstream of PoPA 60, the memory access request also specifies a physical address space PASID that identifies the physical address space of the access. If the memory system component is downstream of PoPA 60, PASID may not be provided with the request because the request has already passed through the PoPA and aliased physical addresses in separate physical address spaces have been de-aliased (e.g., by removing PASID).

[0141] The memory system component includes a resource control parameter selection circuit 400 that selects a set of one or more memory system resource control parameters from a resource control settings structure 402 based on a combination of a partition ID space indicator MPAM_SP and a resource control partition ID value (PARTID) supplied with the request. The resource control settings structure 402 includes several entries 404, each corresponding to a different combination of MPAM_SP, PARTID values. Thus, the same partition ID value PARTID that occurs in different partition ID spaces may correspond to different sets of resource control parameters 404. The resource control setting structure 402 may be a set of hardware-implemented registers within the memory system component that can be updated by the processing circuit 310 issuing a memory access request that specifies an address mapped to one of the registers as the target address. (Possibly, to reduce the number of addresses exposed to the memory map, a single register may serve as an interface with memory-mapped addresses that are written to when the resource control setting is updated, and part of the information specified by a memory access request targeting the interface register may be an entry ID indicating which resource control setting entry 404 is being updated, thereby avoiding the need for a separate memory-mapped address for each hardware-implemented resource control setting register.) Alternatively, the resource control setting structure 402 may be a structure maintained in memory at a set of addresses reserved by software for the structure, in which case the memory system component hardware need only have a register that identifies the base address of that data structure within its memory address space. Optionally, the memory system component may include a resource control setting cache for caching resource control setting entries 404 from its memory-based structure.

[0142] In general, regardless of whether resource control settings 402 are implemented using registers in hardware system components or data structures in memory, resource control parameters 404 corresponding to a given partition ID space may be accessible to software executing on a processing element 6 by issuing a memory access request that specifies in the PASID a physical address space that corresponds to a region associated with the given partition ID space. Thus, resource controls for defining settings for partition IDs within the non-secure, secure, realm, and root partition ID spaces may be accessed using memory access requests that specify physical addresses within the non-secure, secure, realm, and root physical address spaces, respectively.

[0143] Based on the selected set of resource control parameters 404, resource usage control circuitry 406 controls the processing of memory access requests based on the selected resource control parameters. The manner in which the resource control parameters are used to affect the processing of requests may vary depending on the type of memory system component and the features implemented, but in general the parameters may affect the allocation of performance resources to the processing of requests or the management of contention for such resources between separate requests. However, the resource control settings do not affect the functional outcome of the processing of requests, such as determining whether a request should be granted or denied or selecting which particular memory system location is accessed in response to a request.

[0144] For example, if the memory system component is a cache, resource control settings 404 may be used to control allocation of cache storage capacity to data or instructions associated with the physical address PA of the request. For example, resource control settings 404 may define a maximum cache capacity that can be allocated to data instructions associated with a specified partition ID and partition ID space, with a cache capacity limit defining, for example, a maximum percentage of cache capacity that can be used for that combination of partition ID and partition ID space indicator. Another option may be for the resource control settings to specify which individual portions of the cache (e.g., which style of set-associative cache) can be allocated to data or instructions associated with the corresponding partition ID and partition ID space. With portion-based control, one software process may be restricted to using a relatively small subset of the cache's styles, while another software execution environment may be permitted to use a larger number of styles, thereby potentially providing better performance when accessing memory. In any event, providing some resource control settings that can limit the cache capacity used by a given software execution environment can reduce the noisy neighbor problem by preventing one software execution environment from using up a large portion of the cache capacity.

[0145] As another example of resource usage control, an interconnect or memory controller may control bus bandwidth allocation based on the specified partition ID and partition ID space and the resource control setting 404 selected for the current request. For example, a minimum and / or maximum bandwidth may be defined in the resource control setting, which may be used to control how many slots on the bus are available for requests associated with a particular software execution environment indicated by the partition ID, partition ID space specified in a memory access request. For example, if the bandwidth recently used by a given process falls below its minimum bandwidth indicated in the corresponding set of resource control settings selected for that combination of partition ID and partition ID space, requests specifying that combination of partition ID and partition ID space may be prioritized in future bus arbitration decisions. If the bandwidth used by a given process exceeds a defined maximum bandwidth, memory access requests specifying the corresponding combination of partition ID and partition ID space may be deprioritized in future bus arbitration decisions, e.g., by preventing further bus slots from being allocated until bandwidth utilization drops below the maximum.

[0146] As another option, a memory system component, such as a memory controller or interconnect, may prioritize a given memory access request based on resource control settings, such that requests for one software execution environment may be prioritized ahead of requests for another software execution environment, and the priorities are used to manage resource contention between the requests. Thus, there may be a wide variety of ways in which resource control settings may affect the performance achieved when processing requests for access to memory.

[0147] 16, the memory system component may also include a performance monitor selection and filtering circuit 410 that controls the updating of performance monitor counters 412 in response to memory access request processing by the memory system component, with criteria for updating the performance monitors 412 defined in filter parameters 414. Similar to resource control settings 402, the filter parameters 414 may be defined in registers of the memory system component or in a memory-based structure (which may optionally be cached). The performance monitors 412 may also be accessed as memory-mapped registers or in memory. A partition ID space indicator and a performance monitor group ID PMG (and optionally, a resource control partition ID value (PARTID) in implementations where PMG is considered a prefix / suffix concatenated with PARTID) may be used to select which performance monitors 412 to update and / or whether to update a performance monitor based on the selection of a set of filter parameters 414 corresponding to the combination of MPAM_SP, PMG, and optionally, PARTID. Thus, different performance monitors 412 can be defined for different combinations of partition IDs and partition ID space indicators, and different sets of filter parameters can also be defined for such combinations, allowing performance tracking to be done differently for one software execution environment compared to another, and software running in different security realms may have different sets of performance monitors associated with them, or different sets of filter parameters to define different criteria for performance monitoring.For example, performance monitor 412 may be a set of counters that are incremented in response to memory access requests that meet certain criteria, and filter parameters may define the criteria, such as defining the range of memory addresses over which the performance monitor is updated, defining the type of memory access (e.g., load or store) that is tracked, or defining the type of event that is counted by performance monitor 412, such as cache misses, total requests, wait time to process requests, etc.

[0148] 16 shows an example of a memory system component having both resource control setting selection circuitry 400 and performance monitoring selection and filtering circuitry 410, it is not necessary for all memory system components to have both, and some system components may have only one of them. Also, a memory system may include some components that do not support resource partitioning at all, which do not have resource control setting selection circuitry 400 or performance monitoring selection and filtering circuitry 410. Nevertheless, such memory system components that do not support partitioning at all may coexist in the same memory system with other memory system components that do support partitioning.

[0149] 17 is a flow diagram illustrating processing of a memory access request in a memory system component. In step 200, the memory system component receives a memory access request specifying a physical address (PA), a partition ID (PARTID and / or PMG), a partition ID space indicator (MPAM_SP), and optionally, a PAS indicator (e.g., if the memory system component is upstream of a PoPA 60). In step 202, if the memory system component supports resource partitioning, the method proceeds to step 204, where the resource control setting selection circuit 400 selects a set of one or more resource control parameters 404 based on the resource control partition ID (PARTID) and the partition ID space indicator (MPAM_SP). In step 206, the resource usage control circuit 406 controls resource allocation or contention management for the memory access request based on the selected set of resource control parameters 204. If the memory system component does not support resource partitioning, steps 204 and 206 are omitted.

[0150] If the memory system component supports performance monitor partitioning in step 208, then in step 210, the performance monitor selection and filtering circuit 210 selects whether to update performance monitor data 412 based on the partition ID (which is at least the performance monitor group ID (PMG), but optionally in some embodiments also the resource control partition ID (PARTID)) and the partition ID space indicator MPAM_SP. For example, a set of filter parameters 414 corresponding to the combination of partition ID and partition ID space indicator is selected, and it is determined whether the memory access request satisfies these filter parameters, and if so, the performance monitor 414 corresponding to the combination of partition ID and partition ID space indicator is updated. If the memory system component does not support performance monitor partitioning, step 210 is omitted.

[0151] Regardless of whether the memory system component supports resource partitioning and / or performance monitoring partitioning, the memory access request is processed in step 212. If the memory system component is pre-PoPA, located upstream of PoPA 60, aliased physical addresses in separate physical address spaces are treated as if they refer to separate memory system resources. For example, if the memory system component is a cache, a lookup of the cache capacity can use the PAS indicator as part of the information for determining whether a given cache location corresponds to the requested data or instruction. This can be done, for example, by including the PAS indicator as part of an index value for selecting a cache set and / or a tag value for determining whether the looked-up cache location corresponds to the specified address. In effect, the PAS indicator can be treated as several additional address bits in a cache lookup. If the memory system component is a pre-PoPA memory controller or other component that outputs requests to an interconnect or bus, the PAS indicator can be provided along with the PA and can qualify the PA to function as an additional address bit.

[0152] In step 214, if any memory access request needs to be sent to a downstream memory system component (such as a cache line fill request in case of a cache miss, or a request sent by the interconnect onto a bus or a request issued by a memory controller to a memory storage unit), the partition ID and partition ID space indicator are included as labels attached to the request sent downstream so that the downstream memory system component can also implement resource partitioning or performance monitoring partitioning. Also, the PA and PAS indicators may be provided downstream unless the memory system component is a PoPA memory system component that strips out the PAS to un-alias physical addresses from separate physical address spaces (in which case the PAS indicator may be omitted from the request sent downstream).

[0153] Bridging between regions supporting different numbers of partition ID spaces When building a data processing system such as a system-on-chip, it may be useful for some components to support three or more partition ID spaces and three or more security regions, as in the above-described example, although there may be other memory system components that may support fewer regions and partition ID spaces. For compatibility with legacy devices, it may be desirable to allow devices that support such fewer partition ID spaces and security regions to coexist with processing elements and memory system components such as those described above. Thus, as shown in FIG. 18 , a data processing system may include a first region 450 that includes one or more components that support at least three partition ID spaces and at least three security regions, as described above, and a second region 452 of the device that includes one or more components that support fewer partition ID spaces and security regions than the components in the first region. Bridge circuitry 460 may be provided to remap the physical address space ID and partition ID space indicators for memory access requests passing between the first and second regions. For example, at the boundary between region 450 and region 452, four values ​​of the physical address space indicator (PASID) may be mapped to a value selected from a set of two physical address space values ​​supported within region 452. Similarly, a 4:2 remapping of the partition ID space indicator (MPAM_SP) may be performed. A corresponding 2:4 region / partition ID space remapping may be performed for requests issued from the second area 452 to the first area 450. The bridge circuitry 460 may optionally include remapping circuitry combined with other functions, such as a system memory management unit (SMMU) 462, which performs address translation on behalf of devices in the second area 450 and may also perform remapping in the bridge between area 450 and area 452.Alternatively, dedicated bridge circuits 464, 466 may be provided at the interface between the zones, separate from other functions such as address translation. Separate bridging components may be provided for 4:2 remapping for requests passed from the first zone 450 to the second zone 452, and for 2:4 remapping for requests passed from the second zone 452 to the first zone 450.

[0154] Various bridging techniques can be used to support legacy areas 452 under various design goals. For 2PAS and 2PARTID space devices 454 making requests to 4PAS / PARTID area 450, system MMU 462 can perform the mapping under the control of software-defined page tables. Alternatively, for a relatively inexpensive but inflexible solution, devices 454 can be hardwired with static translations from non-secure PAS to non-secure PAS and secure PAS to secure PAS, and corresponding translations from non-secure partition ID space to non-secure partition ID space and secure partition ID space to secure partition ID space. Although such legacy devices may encode the non-secure / secure partition ID space using a one-bit indicator, such that 0b1 indicates non-secure and 0b0 indicates secure, the above encoding of MPAM_SP, where 0b00, 0b01, 0b10, and 0b11 represent the secure, non-secure, root, and realm partition ID spaces, respectively, may be useful because static mapping can be implemented by simply adding a high-order 0 bit to the non-secure / secure request indication received from devices 454 in zone 452. However, static mapping is possible with other encodings of MPAM_SP.

[0155] When PE6 and other elements in 4PAS and 4PARTID space area 450 make requests to devices in area 452, they have several options: 1. A rigid static mapping transforms root PAS and secure PAS into secure PAS requests to legacy devices, and realm PAS and non-secure PAS requests into non-secure requests to legacy components. Similarly, the root / secure partition ID space is mapped to the secure partition ID space, and realm / non-secure PAS requests are mapped to the non-secure partition ID space. The encoding of MPAM_SP, where 0b00, 0b01, 0b10, 0b11 represent secure, non-secure, root, and realm partition IDs, again helps to simplify the circuitry for performing this static mapping, as it means that the most significant bit of MPAM_SP can simply be discarded to provide a one-bit indicator of 0b1 for non-secure and 0b0 for secure that can be used by such legacy devices 454. 2. A simple programmable space mapper external to the legacy component 454 or legacy area 452. The space mapper controls whether the root partition ID space is mapped to the secure or non-secure partition ID space, and whether the realm partition ID space is mapped to the secure or non-secure partition ID space. a) The mapper can also choose whether to map the root PAS to a secure PAS or a non-secure PAS, and whether to map the realm PAS to a secure PAS or a non-secure PAS. Alternatively, the root PAS can always be mapped as secure and the realm PAS can always be mapped as non-secure, in which case programmable aspects of the mapper affect the partition ID mapping but not the PAS mapping. b) The mapper can also indicate via flags (e.g., NO_MON) whether requests from the root partition ID space should not be monitored and whether requests from the realm partition ID space should not be monitored (this may require a small redesign of legacy components 454 to implement the monitoring disablement when the flags indicate that monitoring should be disabled, but this may require less redevelopment effort than supporting all four partition ID spaces). One of the mapper combinations in 3.2 can be implemented in legacy components 454 and requires greater changes to the component design than those required by 2b.

[0156] In this application, the term "configured to..." is used to mean that an element of an apparatus has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a method of arranging or interconnecting hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that an apparatus element needs to be modified in any way to provide the defined operation.

[0157] Although exemplary embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to these precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: a processing circuit for processing instructions in one of at least three regions each associated with a corresponding physical address space, and issuing memory access requests to the memory system specifying a target address indicating a target memory system location; a partition identifier selection circuit that selects a partition identifier based on programmable partition identifier selection information associated with the current software execution environment that caused the memory access request to be issued; a partition identifier space selection circuit that selects a selected partition identifier space from among at least three partition identifier spaces based on a current region of the processing circuit; Equipped with The selected partition identifier space and the partition identifier together representing information for selecting, in a memory system component of the memory system, a set of one or more memory system resource control parameters for controlling allocation of resources to process the memory access request or for managing contention for the resources, or information for selecting, in the memory system component, whether to update performance monitoring data in response to the memory access request; the processing circuitry is configured to issue the memory access request to the memory system, the memory access request specifying the partition identifier and a partition identifier space indicator comprising a plurality of bits indicating the selected partition identifier space selected by the partition identifier space selection circuitry.

2. The apparatus of claim 1 , wherein the partition identifier space selection circuitry is configured to select the selected partition identifier space based on the current region of the processing circuitry and based on programmable control information.

3. 3. The apparatus of claim 2, wherein the partition identifier space selection circuit is configured to select, based on the programmable control information, whether the selected partition identifier space should be a primary partition identifier space associated with the current region or an alternate partition identifier space associated with the current region, and wherein, for at least one of the at least three regions, the alternate partition identifier space is the primary partition identifier space associated with another region.

4. 4. The apparatus of claim 3, wherein the primary partition identifier space associated with a given region is a fixed partition identifier space defined for the given region independent of the programmable control information.

5. 4. The apparatus of claim 3, wherein for at least one region, the alternate partition identifier space associated with that region is a partition identifier space that is variably selected in response to the programmable control information.

6. the processing circuitry is configured to process instructions at one of a plurality of privilege levels; 6. The apparatus of claim 2, wherein, for at least one privilege level, at least a portion of the programmable control information that controls selection of the selected partition identifier space for memory access requests issued at the at least one privilege level is programmable at a privilege level that is more privileged than the at least one privilege level.

7. 7. The apparatus of claim 6, wherein the processing circuitry is configured to, for at least a subset of the at least one privilege level, make accessible to at least one instruction executed at a privilege level of the subset a forced space indicating information indicating the selected partition identifier space selected based on the programmable control information programmable at the more privileged privilege level.

8. the processing circuitry is configured to process instructions at one of a plurality of privilege levels, and the programmable control information comprises: hierarchical control enablement information programmable at a first privilege level; space selection control information programmable at a second privilege level less privileged than the first privilege level; Including, when the hierarchical control information has a first value, the partition identifier selection circuit is configured to select the selected partition identifier space in response to a memory access request issued at the second privilege level or a third privilege level that is lower in privilege than the second privilege level, in accordance with the space selection control information programmable at the second privilege level; 8. The apparatus of claim 2, wherein when the hierarchical control information has a second value, the partition identifier selection circuit is configured to select the selected partition identifier space for a memory access request issued at the second privilege level or the third privilege level, regardless of the space selection control information programmable at the second privilege level.

9. The apparatus of any one of claims 1 to 8, wherein a functional result of processing the memory access request is independent of the partition identifier and the selected partition identifier space.

10. a physical address space selection circuit that selects a selected physical address space based on the current area in response to the memory access request; The apparatus of any preceding claim, wherein the processing circuitry is configured to issue the memory access request specifying a physical address space indicator that indicates the selected physical address space.

11. 11. The apparatus of claim 10, wherein the physical address space selection circuitry is configured to select the selected physical address space based on the current region and based on physical address space selection information specified in an address translation entry that provides address translation information corresponding to the target address of the memory access request.

12. 12. The apparatus of claim 11, wherein the partition identifier space selection circuitry is configured to select the selected partition identifier space according to the current region and independently of the physical address space selection information specified in the address translation entry corresponding to the target address.

13. a Point of Physical Aliasing (PoPA) memory system component configured to unalias a plurality of aliased physical addresses from separate physical address spaces corresponding to the same memory system resource and map any of the plurality of aliased physical addresses to an unaliased physical address provided to at least one downstream memory system component; at least one pre-PoPA memory system component upstream of the PoPA memory system component, the at least one pre-PoPA memory system component configured to treat the aliased physical addresses from separate physical address spaces as if the aliased physical addresses correspond to separate memory system resources; The apparatus according to any one of claims 10 to 12, comprising:

14. a resource control parameter selection circuit that selects the set of one or more memory system resource control parameters based on the partition identifier space indicator and the partition identifier; and / or The apparatus of any one of claims 1 to 13, comprising a memory system component, the memory system component comprising a performance monitoring control circuit that controls whether to update the performance monitoring data in response to the memory access request based on the partition identifier space indicator and the partition identifier.

15. each of the at least three partition identifier spaces is associated with a corresponding one of the at least three regions; 15. The apparatus of claim 14, wherein a given set of memory system resource control parameters corresponding to a given partition identifier space is accessible in response to a memory access request issued with a target address within the physical address space that corresponds to the region associated with the given partition identifier space.

16. a bridge circuit at a boundary between a first area of ​​the device having one or more components supporting the at least three partition identifier spaces and a second area of ​​the device having one or more components supporting fewer partition identifier spaces than the one or more components in the first area; The apparatus of any preceding claim, wherein the bridge circuitry is configured to remap the partition identifier space indicator for memory access requests passing between the first area and the second area.

17. The bridge circuit is Fixed mapping, and The apparatus of claim 16 , configured to remap the partition identifier space indicator according to one of a programmable mapping.

18. 18. The apparatus of claim 16 or 17, wherein the bridge circuitry is also configured to remap a physical address space indicator that indicates the selected physical address space associated with the memory access request passing between the first area and the second area.

19. A memory system component comprising: a memory access request receiver circuit for receiving a memory access request, the memory access request specifying a target address indicating a target memory system location within a memory system, a partition identifier space indicator including a plurality of bits indicating a selected partition identifier space selected from at least three partition identifier spaces, and a partition identifier associated with a current software execution environment that caused the memory access request to be issued; and / or resource control circuitry that selects a set of one or more memory system resource control parameters based on the partition identifier space indicator and the partition identifier, and controls allocation of resources for processing the memory access request or manages contention for the resources based on the selected set of memory system resource control parameters. a performance monitoring control circuit that controls whether to update the performance monitoring data in response to the memory access request based on the partition identifier space indicator and the partition identifier.

20. 1. A method comprising: processing instructions in one of at least three regions each associated with a corresponding physical address space; selecting a partition identifier based on programmable partition identifier selection information associated with the current software execution environment that caused the memory access request to be issued; selecting a selected partition identifier space from among the at least three partition identifier spaces based on a current region of the processing circuit; issuing a memory access request to a memory system specifying a target address indicating a target memory system location, the partition identifier, and a partition identifier space indicator including a plurality of bits indicating the selected partition identifier space; selecting a set of one or more memory system resource control parameters based on the partition identifier space indicator and the partition identifier, and controlling resource allocation for processing the memory access request or managing contention for the resource based on the selected set of memory system resource control parameters; and / or and controlling whether to update performance monitoring data in response to the memory access request based on the partition identifier space indicator and the partition identifier.

Images