CONSTRAINING UPDATES OR USE OF MEMORY SYSTEM COMPONENT RESOURCE CONTROL PARAMETERS - Patent application

Abstract

The memory transaction may be tagged with a partition identifier selected depending on which software execution environment issued the memory transaction. The memory system component may control allocation of resources for processing the memory transaction or manage contention for the resources depending on a selected set of memory system component parameters selected depending on the partition identifier specified by the memory transaction. The programmable constraint storage circuit stores at least one resource control parameter constraint used to constrain updates or usage of memory system component resource control parameters.

Description

[Technical field]

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

[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 between the software execution environments. For some systems, it may be important that the performance of one software execution environment is not thwarted due to another software execution environment using too many 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. Summary of the Invention [Problem to be solved by the invention]

[0003] At least some examples provide an apparatus comprising a processing circuit for processing instructions from one of a plurality of software execution environments; and a memory system component for processing a memory transaction issued by the processing circuit in response to the instructions, wherein in response to the memory transaction issued by the processing circuit specifying a selected partition identifier depending on which software execution environment caused the memory transaction to be issued, the memory system component is configured to control an allocation of a resource for processing the memory transaction or manage contention for the resource depending on a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters depending on the partition identifier specified by the memory transaction, the memory system component including a programmable constraint storage circuit for storing at least one resource control parameter constraint, and wherein based on the at least one resource control parameter constraint stored in the programmable constraint storage circuit, the memory system component is configured to constrain at least one of updating a target memory system component resource control parameter and use of the target memory system component resource control parameter to control the allocation of a resource or manage contention for the resource.

[0004] At least some examples provide an apparatus comprising: means for processing instructions from one of a plurality of software execution environments; and means for processing a memory transaction issued by the means for processing in response to the instructions, the memory transaction issued by the means for processing specifying a selected partition identifier depending on which software execution environment caused the memory transaction to be issued; the means for processing the memory transaction in response to the memory transaction issued by the means for processing being configured to control an allocation of resources for processing the memory transaction or manage contention for the resources in dependence on a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters in dependence on the partition identifier specified by the memory transaction; the means for processing the memory transaction including means for programmably storing at least one resource control parameter constraint; and based on the at least one resource control parameter constraint stored in the means for programmably storing, the means for processing the memory transaction is configured to constrain at least one of updating a target memory system component resource control parameter and using the target memory system component resource control parameter to control the allocation of resources or manage contention for the resources.

[0005] At least some examples provide a method that includes processing instructions from one of a plurality of software execution environments and, in response to the instructions, processing an issued memory transaction, wherein in response to the memory transaction specifying a partition identifier selected depending on which software execution environment caused the memory transaction to be issued, a memory system component controls an allocation of resources for processing the memory transaction or manages contention for the resources depending on a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters depending on the partition identifier specified by the memory transaction and constraining at least one of updating a target memory system component resource control parameter and using the target memory system component resource control parameter to control the allocation of resources or manage contention for the resources based on at least one resource control parameter constraint stored in a programmable constraint storage circuit.

[0006] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a schematic diagram of an example of a data processing system including a memory system. [Diagram 2] FIG. 2 is a schematic diagram illustrating one example of partitioning control of memory system resources depending on a partition identifier assigned to a software execution environment associated with a memory transaction. [Diagram 3] FIG. 3 is a schematic diagram of an example of a processing circuit for issuing memory transactions that specify a partition identifier. [Figure 4]FIG. 4 illustrates an example of different software execution environments executed by a processing circuit. [Diagram 5] FIG. 5 is a diagram showing an example of assigning partition identifiers to different software execution environments. [Figure 6] FIG. 6 illustrates an example of controlling memory system resources using at least one memory system component resource control parameter selected based on a partition identifier specified in a memory access request. [Figure 7] FIG. 7 illustrates a programming interface for updating memory system component resource control parameters. [Figure 8] FIG. 8 is a flow diagram illustrating a method for responding to a memory transaction in a memory system component. [Figure 9] FIG. 9 illustrates an example cache that controls allocation of cache resources depending on a partition identifier and / or updates selected performance monitoring data based on the partition identifier. [Figure 10] FIG. 10 is a flow diagram illustrating a method for controlling allocation to a cache depending on a capacity threshold selected depending on a partition identifier. [Figure 11] FIG. 11 illustrates an example of controlling which portion of a cache data may be allocated depending on a partition identifier. [Figure 12] FIG. 12 illustrates an example memory system component having programmable constraint storage circuitry for storing at least one resource control parameter constraint. [Figure 13] FIG. 13 is a flow diagram illustrating a method for programming resource control parameter constraints. [Figure 14] FIG. 14 is a flow diagram illustrating a method for controlling updates of memory system component resource control parameters based on resource control parameter constraints. [Figure 15]FIG. 15 illustrates an example of resource control parameter update constraints for portion-based resource allocation control parameters. [Figure 16] FIG. 16 illustrates an example set of resource control parameter update constraints for a fraction-based capacity threshold provided as an example of a memory system component resource control parameter. [Figure 17] FIG. 17 illustrates an example of applying a maximum constraint to a minimum bandwidth threshold and a maximum bandwidth threshold. [Figure 18] FIG. 18 is a flow diagram illustrating how resource control parameter constraints are applied when using resource control parameters to control resource allocation or contention management for memory transactions. [Figure 19] FIG. 19 illustrates an example of an identifier specified by a memory transaction that may be used to determine whether the transaction is subject to resource control parameters. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The apparatus may have a processing circuit for processing instructions from one of several software execution environments, and a memory system component for processing memory transactions issued by the processing circuit in response to the instructions. The memory transaction may be assigned a partition identifier that is selected depending on which software execution environment issued the memory transaction. The memory system component may use the partition identifier to control allocation of resources or management of contention for resources depending on a set of memory system component parameters selected based on the partition identifier. The partition identifier may also be used to control whether performance monitoring data is updated in response to the memory transaction.

[0009] Thus, the processing circuitry may present a partition identifier as a label for the memory transaction depending on which software issued the transaction. This means that, to address the noisy neighbor problem described above, resources in the memory system may be partitioned between software execution environments to prevent one software execution environment from taking more than its fair share of resources.

[0010] However, there may be more than one software execution environment, and more than one software execution environment may be enabled to control the setting of a respective set of memory system component parameters, each of which is used by the memory system components to control allocation of resources or manage conflicts for resources for a corresponding partition identifier. Thus, while one software execution environment may set a respective set of memory system component parameters to grant a software execution environment associated with one partition identifier a larger resource allocation than a software execution environment associated with another partition identifier, this may not be effective if another controlling software execution environment is then able to update the memory system component parameters to provide a different resource allocation. This may impair the execution of the software execution environment that was expected to be assigned the larger resource allocation.

[0011] For example, in one use case, a first control software execution environment may program memory system component parameters to allocate a dedicated portion of resources for use by a real-time process that should not be used by other processes. This may help provide expected maximum time guarantees for certain operations performed by the real-time process. However, if a second control software execution environment then subsequently changes the memory system component parameters to allow other non-real-time processes to access the dedicated resources, this may violate the dedicated use expected by the real-time software execution environment, which may make it more difficult for the real-time processes to meet the real-time guarantees of the real-time processes. A similar problem may arise between secure and non-secure software programming the control settings, in which the resource partitioning used to enforce secure access to data from the secure software may be compromised only if another process is able to overwrite the memory system component parameters to allow the non-secure software to access resources expected to be allocated for the secure software.

[0012] In the technique described below, a memory system component (MSC) is provided with a programmable constraint storage circuit for storing at least one resource control parameter constraint that can be used to constrain updates or use of target memory system component resource control parameters. The resource control parameter constraint thus provides a way to enforce (i) updates allowed to be made to the resource control parameters maintained for a given MSC, and / or (ii) certain bounds on valid values ​​of resource control parameters used in processing memory transactions to control resource allocation or manage contention for resources. This can address the aforementioned problem and ensure that once a certain set of resource control parameters is established, another control software execution environment cannot change these parameters outside the bounds specified in the programmable constraint storage circuit (or if the parameters are changed beyond the bounds, the updated parameters are not observed in use), and thus the previously set resource control parameters can be respected.

[0013] Before considering the use of such resource control parameter constraints in more detail, we first describe a general architecture for setting partition identifiers for software execution environments and for using these partition identifiers to control resource allocation or management and / or performance monitoring in a memory system. After describing the general architecture, features for controlling the updating or use of memory system component resource control parameters based on resource control parameter constraints are discussed in the section "Resource Control Parameter Constraints."

[0014] A general architecture for memory resource and performance monitoring partitioning. 1 shows a schematic diagram of an example of a data processing system 2 including N (N is 1 or more) 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 appreciated that this is merely one example of a possible cache hierarchy and that 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.

[0015] A system on chip (SoC) interconnect 18 couples the N clusters and any other master devices 22 (such as a display controller or a Direct Memory Access (DMA) controller). The SoC interconnect may have 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, 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 direct transactions to other slave devices, such as a crypto unit for providing encryption / decryption functions.

[0016] 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. Each of caches 8, 10, 12, 16, 20, interconnects 14, 18, memory controller 24, and memory devices 25 may 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. In general, memory system components may include any components of a data processing system used to service memory transactions to access memory data or to control the processing of these memory transactions.

[0017] The memory system may have various resources available to process memory transactions. For example, caches 8, 10, 12, 16, 20 have storage capacity available to cache data required by a given software execution environment executing in one of the processors 6 to provide faster access to the 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 to cache address translation data. Also, the interconnects 14, 18, memory controller 24, and memory devices 25 may each have an amount of bandwidth available to process memory transactions.

[0018] When multiple software execution environments executing on a processing element 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 for 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, thus increasing the use of data center servers. However, there is still a demand to meet web application tail latency objectives, and thus 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 in separate SoCs into a single SoC. Again, this leads to a desire to limit performance interactions between software execution environments, and a desire to monitor how the software execution environments need to enable these independent processes to access the shared memory while limiting performance interactions.

[0019] 2 shows a schematic example of partitioning control of 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 a part 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 any subpart of these types of processes (e.g., a single virtual machine may have different parts that are considered as separate software execution environments). As shown in FIG. 2, each of the software execution environments may be assigned a given partition identifier 30, which is passed to the memory system components together with the memory transaction associated with that software execution environment.

[0020] Within a memory system component, resource allocation or conflict resolution operations may be controlled based on one of several sets of memory system component parameters selected based on the partition identifier. For example, as shown in Figure 2, each of the software execution environments may be assigned an allocation threshold that represents a maximum amount of cache capacity that may be allocated for data / instructions associated with that software execution environment, and the associated allocation threshold when servicing a given transaction is selected based on the partition identifier associated with the transaction. For example, in Figure 2, a transaction associated with partition identifier 0 may allocate data up to 50% of the storage capacity of the cache, leaving at least 50% of the cache available for other purposes.

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

[0022] These control schemes are discussed in more detail below. It will be understood 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 problems.

[0023] Similarly, a partition identifier associated with a memory transaction may be used to partition performance monitoring within the memory system, such that a separate set of performance monitoring data may be tracked for each partition identifier to allow information specific to a given software execution environment (or group of software execution environments) to be identified, such that sources of potential performance interactions may be more easily identified than if performance monitoring data was recorded as a whole across all software execution environments. This may aid in diagnosing potential performance interaction effects and may aid in identifying possible solutions.

[0024] An architecture for controlling the setting of partition identifiers, labeling memory transactions based on the partition identifiers set for a corresponding software execution environment, routing the partition identifiers 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 identifiers. The use of partition identifiers is intended to be a layer on top of the semantics of the existing architecture of the memory system without changing the semantics of the memory system, and 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 using partition identifiers to control resource allocation, this may affect the performance achieved when servicing memory transactions for a given software execution environment, but this does not affect the outcome of the computations available to the architecture. That is, the partition identifier does not change the outcome or result of a memory transaction (e.g., what data is accessed), but simply affects the timing or performance achieved for that memory transaction.

[0025] 3 illustrates in more detail an example of a processing unit 6. The processor includes a processing pipeline including several pipeline stages, including a fetch stage 40 for fetching instructions from an instruction cache 10, a decode stage 42 for decoding the fetched instructions, an issue stage 44 including an issue queue 46 for queuing instructions while waiting for operands of the instructions to become available and for issuing the instructions for execution when the operands are available, an execution stage 48 including several execution units 50 for executing instructions of different classes to perform corresponding processing operations, and a writeback stage 52 for writing results of the processing operations to data registers 54. Source operands for the data processing operations may be read from the registers 54 by the execution stage 48. In this example, the execution stage 48 includes an Arithmetic / Logic Unit (ALU) for performing arithmetic or logical operations, a Floating Point (FP) unit for performing operations using floating point values, and a Load / Store unit for performing load operations to load data from the memory system into the registers 54 or store data from the registers 54 into the memory system. It will be appreciated that these are merely some examples of possible execution units and other types may be provided. Similarly, other examples may have different configurations of pipeline stages. For example, in an out-of-order processor, additional register renaming stages may be provided to remap architectural register specifiers specified by instructions to physical register specifier identification registers 54 provided in hardware, and a reorder buffer to track the execution and commitment of instructions executed in a different order to the order in which they were fetched from the cache 10. Similarly, other mechanisms not shown in FIG. 1 may also be provided, for example a branch prediction function may be provided at the fetch stage to control the generation of the next fetch address 61 based on the predicted outcome of the branch instruction.

[0026] The processor 6 has a number of control registers 60, including, for example, a program counter register 62 for storing a program counter indicating a current execution point of a program being executed, an exception level register 64 for storing an indication of the current exception level at which the processor is executing instructions, a security state register 66 for storing an indication of whether the processor is in a non-secure or secure state, and a Memory Partitioning And Monitoring (MPAM) control register 68 for controlling memory system resources and performance monitoring partitioning (MPAM control registers are discussed in more detail below). It will be appreciated that other control registers may also be provided. Although the program counter register 62 is shown in FIG. 3 as being maintained by the fetch stage 40, the program counter register 62 may also be accessible to other stages, such as the execution stage 48.

[0027] The processor has a memory management unit (MMU) 70 for controlling access to the memory system in response to memory transactions. For example, when a load or store instruction is encountered, the load / store unit issues a corresponding memory transaction specifying a virtual address. The virtual address is provided to the memory management unit (MMU) 70, which translates the virtual address into a physical address using address mapping data stored in one or more translation lookaside buffers (TLBs) 72, 73, 74. The TLBs may include a data TLB 74 acting as a level-1 TLB for data accesses initiated by the load / store unit 50, an instruction TLB 73 acting as a level-1 TLB for instruction fetch accesses initiated by the fetch stage 40, and a primary TLB 72 acting as a shared level-2 TLB for both instruction and data accesses, where the primary TLB 72 is accessed on misses in the level-1 TLBs 73, 74. Each of the TLBs 72-74 stores a number of TLB entries. Each of the TLB entries may identify not only mapping data that identifies how to translate an address, but also associated access permission data that defines whether the processor is allowed to read or write to an address in a corresponding page of the address space. In some examples, there may be multiple stages of address translation, and thus multiple TLBs, for example, a stage 1 TLB that provides a first stage of translation for mapping a virtual address generated by the load / store unit 50 to an intermediate physical address, and a stage 2 TLB that provides a second stage of translation for mapping the intermediate physical address to a physical address used by the memory system to identify the data being accessed.The mapping data for the stage 1 TLB may be set under control of an operating system, and the mapping data for the stage 2 TLB may be set under control of a hypervisor, e.g., to support virtualization. It will be appreciated that the arrangement of the TLBs shown in Figure 3 is merely an example and other implementations may have different sets of TLBs.

[0028] In addition to the TLBs 72, 73, 74, the MMU may also include other types of caches, such as a page walk cache 75 for caching data used to identify mapping data to be loaded into the TLBs during a page table walk. The memory system may store page tables that specify address mapping data for each of the pages of the virtual memory address space. The TLBs 72, 73, 74 may cache a subset of these page table entries for some recently accessed pages. A page table walk is initiated by the page table walk unit 76 when the processor issues a memory transaction to a page that does not have corresponding address mapping data stored in the TLBs 72, 73, 74. This may be relatively slow, since there may be multiple levels of page tables to traverse memory to identify an address mapping entry for the needed page. To speed up the page table walk, recently accessed page table entries of the page tables may be placed in the page walk cache 75. These are typically page table entries other than the last level page table entry that actually specifies the mapping for the needed page. These higher level page table entries typically specify where in memory other page table entries for the corresponding range of addresses can be found. By caching in the page walk cache 75 at least some levels of the page table that were traversed in the previous page table walk, page table walks for other addresses that share the same initial portion of the page table walk can be made faster.Alternatively, rather than caching the page table entries themselves, the page walk cache 75 may cache the addresses at which these page table entries may be found in memory, so again, given page table entries may be accessed more quickly than if their addresses had to be identified by first accessing other page table entries in memory.

[0029] FIG. 4 illustrates an example of different software execution environments that may be executed by the processor 6. In this example, the architecture supports four different exception levels EL0 to EL3 of increasing privilege level (so that EL3 has the highest privilege exception level and EL0 has the lowest privilege exception level). Generally, higher privilege levels have more privileges than lower privilege levels and therefore can access at least some data and / or perform some processing operations not available to lower privilege levels. Applications 80 run at the lowest privilege level EL0. Several guest operating systems 82 run at privilege level EL1, each of the guest operating systems 82 managing one or more applications 80 at EL0. A virtual machine monitor 84, also known as a hypervisor or host operating system, runs at exception level EL2 and manages the virtualization of each of the guest operating systems 82. It is possible that some applications at EL0 may be managed directly by the host operating system at EL2, without an intervening operating system at EL1.

[0030] A transition from a lower exception level to a higher exception level may be caused by an exception event (e.g., an event that needs to be handled by a hypervisor or host operating system may cause a transition to EL2), and a transition back to a lower level may be caused by a return from handling an exception event. Some types of exception events may be serviced at the same exception level at which the exception event is taken, and other types of exception events may trigger a transition to a higher exception state. Current exception level register 64 indicates at which of exception levels EL0-EL3 processing circuit 6 is currently executing code.

[0031] In this example, the system also supports partitioning between a secure domain 90 and a normal (less secure) domain 92. Sensitive data or instructions may be protected by allocating them to memory addresses marked as accessible only to the secure domain 90, and the processor has hardware mechanisms to ensure that processes executing in the less secure domain 92 cannot access the data or instructions. For example, access permissions set in the MMU 70 may control the partitioning between the secure and non-secure domains, or alternatively, a completely separate security memory management unit may be used to control the security state partitioning, with separate secure and non-secure MMUs 70 and 70 being provided for sub-control within each of the security states. Transitions between the secure domain 90 and the normal domain 92 may be managed by a secure monitor process 94 running at the highest privilege level EL3. This allows transitions between domains to be tightly controlled to prevent non-secure operations 80 or the operating system 82 from accessing data from the secure domain, for example. In other examples, hardware techniques may be used to enforce separation between security states and police transitions, so that code in normal domain 92 can branch directly to code in secure domain 90 without transitioning through a separate secure monitor process 94. However, for ease of explanation, the remainder of the description below refers to an example using a secure monitor process 94 at EL3. Within secure domain 90, a secure world operating system 96 runs at exception level EL1, and one or more trusted applications 98 may run at exception level EL0 under the control of the operating system 96. In this example, exception level EL2 is absent in secure domain 90 because virtualization is not supported in the secure domain, although it is still possible to provide virtualization if desired.One example of an architecture for supporting such a secure domain 90 may be the TrustZone® architecture offered by Arm® Limited of Cambridge, UK. However, it will be appreciated that other techniques may also be used. Some examples may have more than two security states, with the three or more states being provided with different levels of security associated with the state. The security state register 66 indicates whether the current domain is a secure domain 90 or a non-secure domain 92, which indicates to the MMU 70 or other control unit what access permissions are used to govern whether certain data may be accessed or operations are permitted.

[0032] Thus, FIG. 4 shows several different software execution environments 80, 82, 84, 94, 96, 98 that may be executed in the system. Each of these software execution environments may be assigned a given partition identifier (partition ID or PARTID), or a group of two or more software execution environments may be assigned a common partition ID. In some cases, individual parts of a single process (e.g., different functions or subroutines) may be considered as separate execution environments and may be assigned separate partition IDs. For example, FIG. 5 shows an example in which a virtual machine VM 3 and two applications 3741, 3974 executing under VM 3 are all assigned PARTID 1, a particular process 3974 executing under a second virtual machine VM 7 is assigned PARTID 2, and VM 7 itself and another process 1473 executing under VM 7 are assigned PARTID 0. It is not necessary to assign a bespoke partition ID to all software execution environments. A default partition ID may be designated to be used for software execution environments that have not been assigned a dedicated partition ID. Control of what portion of the partition ID space is assigned to each of the software execution environments is performed by software at a higher privilege level, e.g., a hypervisor executing at EL2 controls the allocation of partitions to virtual machine operating systems executing at EL1. However, in some cases, the hypervisor may allow an operating system at a lower privilege level to set its own partition ID for parts of its code or for applications that execute under that code. Also, in some examples, secure world 90 may have a partition ID space that is entirely separate from normal world 92, controlled by secure world OS or monitor program EL3.

[0033] 3, the CPU may include MPAM generation logic 77 for generating MPAM-related information associated with a given memory access transaction. The MPAM-related information may include at least a PART ID, but in some examples the MPAM-related information may also include other information (e.g., a performance monitor group ID used by a memory system component to select which set of performance monitor parameters to update in response to a given memory access request). The MPAM generation logic 77 may include MPAM register selection logic 78 for selecting between partition ID registers of the MPAM control registers 68 to determine which registers should be used to generate the MPAM-related information, and partition ID virtualization logic 79 for controlling the mapping of a virtual partition ID based on information in the MPAM control registers 68 to a physical partition ID used by the memory system component to select resource control settings. The MPAM generation logic 77 generates several alternative MPAM-related information including Instruction MPAM-related information (I-MPAM) used for instruction fetch accesses, Data MPAM-related information (D-MPAM) used for data accesses, Instruction Page Table Walk MPAM-related information (I-PTW-MPAM) used for page table walk accesses triggered by instruction fetches, and Data Page Table Walk MPAM-related information (D-PTW-MPAM) used for data page table walk MPAM-related information.Providing separate MPAM related information I-PTW-MPAM and D-PTW-MPAM for page table walk memory accesses can be useful so that a page table walk memory access can have its resource usage controlled according to memory system component parameters defined for the process that manages the page tables, rather than for the currently running process.

[0034] It will be appreciated that depending on the software execution environment associated with a given memory request, the precise mechanisms for determining which partition identifier to assign to that request may vary greatly, and any such mechanisms may be used in processing element (CPU) 6. From the point of view of memory system components such as caches, interconnects, or memory controllers, it is not important how the partition identifier specified in a given memory request was selected in the CPU.

[0035] The partition ID and performance monitor group ID attached to a given memory transaction (and in some embodiments a security state indication that specifies the security state under which the transaction was issued) flow with the memory transaction throughout the memory system. Thus, a node (e.g., an interconnect) of the memory system that passes a memory transaction to other components of the memory system provides an outgoing memory transaction with the same partition ID, performance monitor group, and security state indication as the corresponding request received at such node. For caches in the memory system, they have the behavior of sometimes generating a response to the request if there is a cache hit, and other times passing the request to a further part of the memory system if there is a cache miss. Caches in the memory system may also allocate new entries from time to time based on the request. When allocating a new entry, the cache may store the partition ID, performance monitor group, and security indication of the request that caused the allocation along with the cached data itself. When the data is written back to a further cache or memory, a writeback transaction is generated, and the writeback transaction specifies the partition ID, performance monitor group, and security indication associated with the deleted data in the cache, rather than the ID associated with the request that triggered the deletion. This allows resource allocation or performance monitoring for write-backs to be controlled / monitored according to parameters specific to the software execution environment that allocated the corresponding data in the cache.

[0036] It should be noted that not all of the memory system components (e.g., caches, interconnects, memory controllers, memory devices, or memory management units) can support partitioning. Components that do not support partitioning can control resource allocation or monitor performance in a manner that is common for all software execution environments. However, outgoing requests are still appended with a partition ID in the same manner as described above, so that downstream memory system components that support partitioning can use the partition ID to select an appropriate set of parameters. Thus, regardless of whether a system designer actually chooses to use partition IDs in any given memory system component, the processing element architecture and partition ID routing scheme described above provide the flexibility to support a range of implementations that implement partitioning at different points in the memory system. However, for those memory system components that respond to partition IDs or performance monitoring group IDs, they can control resource allocation or contention management, or performance monitoring, based on the partition ID.

[0037] Performance monitors work differently than resource partitioning controls. Performance monitors measure, count, or calculate performance metrics based on filters programmed into the monitor. Filter parameters may include partition ID and performance monitor group (or may include performance monitor group without partition ID). For example, a performance monitor that counts bytes transferred to memory may filter its measurements to only count reads with a partition ID of 5 and a performance monitor group of 2. Thus, performance measurements may be collected for different software execution environments or different groups of software execution environments that share the same partition ID and performance monitor group.

[0038] On the other hand, for system components that support resource partitioning, the memory system component selects a set of memory system component parameters based on the partition ID. The memory system component parameters may be resource control parameters that are used to control allocation of memory system resources (such as bandwidth, cache capacity, etc.) or contention for these resources (e.g., the selected memory system component parameters may define a set priority for transactions associated with the corresponding partition ID).

[0039] FIG. 6 illustrates an example of controlling resource partitioning using memory system component parameters selected based on a partition ID (PARTID). The memory system component 100 includes a regulator 102 for controlling access to a controlled resource 104 (e.g., cache capacity, bandwidth). The memory system component 100 has a settings table 106 that provides several entries, each of which corresponds to a given partition ID. The settings table 106 is indexed based on the PARTID specified in a received memory access request. Although FIG. 6 illustrates one settings table, other examples of controlling more than one form of resource control can have a settings table 106 per resource control implemented. Each of the settings table entries specifies one or more partitioning control settings (memory system component resource control parameters) 108 for the corresponding PARTID. The settings can specify, for example, how much cache (or how much memory bus bandwidth) can be used for requests associated with the corresponding PARTID. Some forms of control (e.g., based on maximum cache occupancy for a given PARTID) may depend on resource usage measurements made by measurement circuit 110 (e.g., a count of how many cache entries are already allocated for a given PARTID). Other forms of control may not require measurement circuit 110 (e.g., for a portion-based cache control mechanism described further below, no measurements are required). Thus, based on the resource usage limit for a given PARTID defined in configuration table 106, regulator 102 controls how request handling function 112 handles incoming requests to prevent a particular software process assigned to a given PARTID from taking more than its fair share of controlled resources 104.

[0040] If the memory system component is a cache 8, 10, 16, 20, the controlled resource 104 may be cache storage capacity. Regulator 102 may control allocation of data to the cache in response to a memory transaction depending on a selected set of memory system component resource control parameters 108 in the configuration table for the associated PARTID. If the memory system component is an interconnect 14, 18 or memory controller 24, regulator 102 may control allocation of bandwidth or buffer occupancy for processing a memory transaction depending on a selected set of memory system component resource control parameters 108 in the configuration table for the associated PARTID.

[0041] 7 shows a programming interface 120 for updating control settings in one or more setting tables 106. In this example, there are two separate setting tables 106-A and 106-B for controlling each of the regulators 102-A, 102-B to control access to the respective type of controlled resource 104-A, 104-B. The programming interface 120 includes a PARTID selector 130 and several setting interface registers 132-A, 132-B. To set or read a control setting for a given PARTID, first a register in the PARTID selector 130 is written with the given PARTID, and then a read or write operation is performed to the one or more interface registers 132-A, 132-B corresponding to the control setting to be updated (a read operation returns a value from the corresponding entry in the setting table, and a write operation writes a new value to the corresponding entry in the setting table). The PARTID selector 130 selects the appropriate entry in the configuration table(s) 106 for writing or reading based on the PARTID specified in the PARTID selection register of the PARTID.

[0042] The registers of the programming interface 120 are memory-mapped registers that are accessed by the CPU 6 issuing load / store operations that specify the memory address mapped to the corresponding register to be read / written as the target address of the load / store operation. Thus, the PARTID selector 130 connects a common set of interface registers 132 to the associated row(s) of the configuration table(s) 106, avoiding the need for a separate interface register for each separate PARTID. The PARTID selector 130 actually moves a "keyhole" that is used to access the configuration table 106 up and down the table to select the entry to be read or written.

[0043] In a system that supports separate secure and less secure address spaces, separate configuration tables 106 and separate programming interfaces 120 may be provided for the secure and less secure address spaces, respectively, to separate the less secure domain from the secure domain.

[0044] 8 illustrates a method for controlling operation of a memory system component based on a partition ID. At step 200, a memory system component receives a memory transaction that specifies a partition ID, a performance monitoring group (PMG), and a security state indication as described above. If the memory system component supports memory system resource partitioning (step 202), then at step 204, a set of resource control parameters is selected based on the partition ID and the security state. Performance monitoring groups are not considered in this step. At step 206, allocation of resources is controlled using the selected set of resource control parameters, or contention for these resources is managed using the selected set of resource parameters. If memory system resource partitioning is not supported, then steps 204 and 206 are omitted.

[0045] If the memory system component supports performance monitor partitioning by performance monitor group (step 208), then in step 210, each performance monitor implemented in the component tests the request against the performance monitor's filter parameters (which may include tests applied to the PMG and partition ID). Each monitor for which the monitor's filter parameters are satisfied updates the monitor's internal state according to the measurement, count, or calculation that the monitor is designed to make. For memory system components that do not support performance monitor partitioning, step 210 is omitted. In some embodiments, both the partition ID field and the PMG field may be included in the filter parameters (thus the PMG field further qualifies the partition ID field). Alternatively, the PMG may be interpreted as an independent ID separate from the partition ID field, in which case the filter parameters may consider the PMG without considering the partition ID.

[0046] Each memory system component that supports resource monitoring partitioning can have a set of parameter registers that store different sets of memory system component parameters, which are selected based on the partition ID. The control parameters for partitioning control are logically an array of control parameters indexed by the partition ID. The interface for setting the control parameters can be arranged as an array of memory-mapped registers, or with a selector register and only a single configuration register per control parameter. In the latter case, the configuration software first stores the partition ID to be configured in a selector register, and then stores the desired control parameters in one or more control parameter configuration registers.

[0047] 9 illustrates an example of a cache 300, which is an example of a memory system component. Cache 300 may be a cache for caching instructions or data, such as level 1 data cache 8, level 1 instruction cache 10 or level 2 cache 12 of a given processing element 6, cluster cache 16, or system cache 20. Cache 300 may also be a cache for address translation, such as TLB 72 or page walk cache 74 in MMU 70. While FIG. 3 illustrates an example where MMU 70 is located within a given processor core, a system MMU may also be located further down in the memory system, such as within SoC interconnect 18.

[0048] The cache 300 includes a cache storage (cache RAM) 302 for storing cached information. The cache RAM 302 includes a number of storage entries 304. As shown in FIG. 9, each entry includes: cached data 306 (which can be any cached information, including not only data values ​​but also instructions or address translation data, depending on the type of cache); a valid bit 308 that specifies whether the corresponding data in the entry is valid; A tag field 310 indicating a portion of the address associated with the cached data; Partition ID 314 of the memory transaction that allocated the data in the cache, Performance monitoring group ID 316 for memory transactions to be allocated, A security state indication 318 of the memory transaction to be allocated (the security state indication 318 indicates from which security state the memory transaction was issued); Other information that a system design may need to keep for each cache line, such as a coherence state or an Address Space Indicator (ASI). can be stored. Upon removal of data from the cache, the ID fields 314, 316, 318 are used to derive a partition ID, a performance monitoring group ID, and a security state indication for the write-back transaction. Although not shown in Figure 9, each of the cache entries may also store coherency information that specifies the coherency state of the cached data (e.g., whether the data is clean or dirty to determine if a write-back is required) and / or victim selection data (e.g., data for tracking which entries were most recently used) to select a victim cache line when removal is required.

[0049] Allocation of data to the cache may be controlled according to any known cache organization, including direct-mapped, set-associative, or fully associative. The example of FIG. 9 shows a four-way set-associative organization scheme, but it should be understood that this is merely an example. Lookups into the cache are performed independent of the partition ID associated with the corresponding memory transaction. Thus, when a memory transaction is received that specifies a given partition ID, the transaction may hit against data in the indexed cache entry regardless of the partition ID 314, non-secure ID indicator 318, and performance monitoring group 316 stored in the cache entry. Thus, partitioning and / or performance monitoring of performance resources does not prevent different software processes from sharing access to cached data.

[0050] On the other hand, when allocating data to the cache, the allocation is controlled depending on a set of resource control parameters, which the cache controller 312 selects based on the security state and partition ID of the corresponding memory transaction. The cache has a set of resource control parameter registers 320 (an example of the configuration table 106 described above), each of which stores resource control parameters for a corresponding software execution environment. A selector 322 selects one of the registers based on the partition ID and security state of an incoming memory transaction that requires allocation of data to the cache. The parameters stored in the selected register are used to control whether and how data is allocated to the cache.

[0051] In a first cache partitioning control mode, allocation is controlled using a maximum capacity threshold selected using a partition ID, the maximum capacity threshold identifying the maximum number of entries of cache capacity to which data associated with the corresponding partition ID is allowed to be allocated. In an implementation supporting secure and non-secure states, the threshold may define the maximum capacity to which data associated with a given combination of partition ID and non-secure ID indicator is allowed to be allocated. For example, the maximum capacity threshold may be set by a higher privilege process, i.e., the threshold for a given operating system may be set by the hypervisor and the threshold for a given application may be set by the operating system.

[0052] For example, Figure 2 shows an example where partition IDs 0, 1, and 2 are assigned maximum capacity thresholds of 50%, 50%, and 40%, respectively. Note that this is not a guaranteed allocation, but only a maximum limit on the amount of cache that can store data for a given partition ID, so the sum of the maximum capacity thresholds defined for different software execution environments may exceed 100%. In this case, not all of the corresponding software execution environments will use their maximum allocation at the same time.

[0053] Returning to FIG. 9, the cache 300 has a set of allocation counters 326 for tracking how many of the cache entries 304 have been allocated for data associated with each of the partition IDs. If security states are supported, the counters may be further partitioned based on security states. When a data value for a given partition ID is allocated to the cache, the corresponding allocation counter 326 is incremented. When data is invalidated, deleted, or replaced, the allocation count for the corresponding partition ID is decremented. When a cache miss occurs in response to a given memory transaction, the cache controller 312 reads the allocation counter 326 and the resource control parameter register 320 corresponding to the partition ID specified by the memory transaction, compares the allocation count to a maximum capacity threshold, and controls the allocation based on the result of the comparison. If the current allocation does not already exceed the threshold, the needed data may be allocated to the cache. However, if the allocation count is equal to or greater than the threshold, the cache controller 312 may determine not to allocate data for the new request to prevent more than the threshold level of entries associated with the same partition ID from being allocated to the cache, or may remove or replace other data associated with that partition ID from the cache before allocating the new data. If removal or replacement is required, the partition ID 314 (and victim selection information, if provided) stored in each of the cache's entries may be used to determine which data to remove. It will be appreciated that the above means of counting capacity are merely examples and that other techniques may also be used to track cache capacity.

[0054] The resource control parameter register 320 may express the maximum number of entries indicated by the maximum capacity threshold in different ways. For example, the resource control parameter register 320 may directly specify the maximum number of entries that may be allocated to the corresponding partition ID data. Alternatively, the resource control parameter register 320 may specify the threshold in terms of a fraction of the total capacity of the cache that may be allocated for that partition ID. For example, the parameter may represent a scaled percentage, where the width of the parameter and a scale factor are specified in the ID register 362 for the corresponding memory component. For example, a component may support an 8-bit capacity control scaled by 256, in which case to allocate 30% of the capacity to a given partition, the partition's maximum capacity parameter may be set to 30. * 256=76.8, which is rounded down to 76 to prevent the allocation from exceeding the desired percentage.

[0055] In embodiments where multiple security states are supported, the security state indication is also used in combination with the partition ID to select the appropriate resource control parameter register 320 and allocation count 326 .

[0056] 10 illustrates a method for controlling cache allocation according to a maximum capacity threshold in a first partitioning control mode. At step 330, a cache miss is detected for a given memory transaction. At step 332, a set of resource control parameters 320 is selected based on the corresponding partition ID and security state. At step 334, the allocation count maintained by counter 326 for the corresponding security state and partition ID is compared to the maximum capacity threshold in the selected set of resource control parameters 320, and at step 336, it is determined whether the allocation count is greater than the maximum capacity threshold. If not, then at step 338, data for the request is allocated to the cache in response to the cache miss. On the other hand, if the allocation is greater than or equal to the allocation threshold, then in step 340, allocation of the data to the cache is prevented, or alternatively, in step 342, data associated with the same partition ID as the current request may be replaced or deleted to make way for the newly allocated data, and in step 338, the data may be allocated normally (e.g., the allocation count may sometimes exceed the threshold, despite the limits provided by steps 340 or 342, if the threshold was recently updated). Whether the method proceeds to step 340 or 342 is an implementation choice for a given implementation of a cache.

[0057] Alternatively, as shown in FIG. 11, a second cache control mode may be used, in which a cache capacity portion bitmap 350 selected based on a partition ID is used to control cache allocation. The bitmap 350 has a number of fields 352, each of which specifies whether a corresponding portion of the cache storage 302 is allowed to be allocated to store data associated with the corresponding partition ID. For example, the bitmap 350 shown at the bottom of the example of FIG. 11 has 32 fields 352, each of which corresponds to 1 / 32 of the cache capacity. Each of the fields may be set to 0 to indicate that a transaction specifying the corresponding partition ID cannot allocate data to that portion of the cache, or may be set to 1 to indicate that data for that partition ID is allowed to be allocated to that portion.

[0058] As shown at the top of Figure 11, by setting different bitmaps 350 for different partition IDs, this allows some portions of the cache to be reserved for a given partition ID, while other portions may be shared between partition IDs or may not be fully allocated. For example, for the subset of four cache portions shown in Figure 11 (which is not the entire cache capacity), portion 0 of the cache is allocated only to partition 1, portion 1 is allocated to both partition 1 and partition 2, and thus partition 1 and partition 2 may compete for allocation to this portion of the cache, portion 2 is allocated only to partition 2, and portion 3 is allocated to none of these partitions. Thus, when allocating data to the cache for partition 1, cache controller 312 is limited to selecting a location in portion 0 or 1, but cannot allocate to portion 2 or 3. A "portion" defined by a bitmap may be a group of one or more cache entries that have the property that any given address may be assigned to at least one entry of the group, e.g., an entire way (including all sets that belong to that way) in a set-associative cache, or any further subset of the entries in a fully associative cache.

[0059] Thus, in the second allocation control mode, when a cache miss is detected, a set of control parameters for the corresponding partition ID and security state is again selected, but this time the cache bitmap is read and used to control which portion of the cache the data may be allocated to.

[0060] Some cache implementations may support only one of the first and second cache allocation control modes above (e.g., a direct-mapped cache may implement the first mode but not the second mode). Other implementations may support the option of using both modes. For example, this may be useful when the particular cache organization being used does not support providing many portions (e.g., a relatively low associativity set-associative cache), as overlaying the maximum capacity limit provides more control than portion partitioning alone.

[0061] As mentioned above, cache 300 may have memory-mapped configuration registers 360 for controlling how resource partitioning is performed. This is one example of the programming interface 120 discussed above. Configuration registers 360 include an ID register 362 for identifying the hardware capabilities of cache 300, a selector register 364 for selecting a set of resource control parameters to update, and one or more configuration registers 366 for specifying parameters to be written to the selected set of resource control parameters.

[0062] For example, ID register 362 may specify which of the first / second cache allocation control modes is supported (threshold or bitmap based partitioning). For example, a cache without an allocation counter 326 may indicate that the first mode is not supported. In this case, the control processor may be limited to using the second mode. Other caches may support both modes and have the flexibility to choose which one is used for a given process. In this case, which mode to use may be specified in resource control parameter register 320 for the corresponding partition ID or may be programmed using configuration register 360.

[0063] When setting a set of resource control parameters for a given partition ID, software writes the partition ID to registers 364 and the parameters to be written to the corresponding registers 366 by issuing a memory transaction specifying a memory address mapped to selector registers 364 and configuration registers 366. In response, cache 300 reads the parameters from configuration registers 366 and writes the parameters to the corresponding resource control parameter registers 320 identified by the associated partition ID. When security states are supported, selector registers 364 and configuration registers 366 may be banked, such that different versions are provided for secure and non-secure states, respectively, and a security instruction associated with the memory transaction selects which set of registers is accessed.

[0064] Note that such selector register 364 and configuration register 366 for setting resource control parameters is just one example of how resource control parameters may be set. The advantage of this approach is that it conserves address space usage in the memory system components. However, in an alternative, a wider interface is used, in which the array of control settings is exposed as an array of N control setting registers, where N is the maximum number of partition IDs supported. This is simpler in that the control configuration can be updated with a single write for a partition, and therefore no mutual exclusion is required to prevent one processor from accessing the selector register 364 and configuration register 366 while another processor is configuring the memory system components. For example, if the maximum number of partition IDs is 216 and a typical memory system component has 2-4 control IDs, this approach may use 256KB of address space for the array of resource control parameters.

[0065] Access to memory-mapped configuration registers 360 may be controlled by MMU 70, for example, to limit which operating states can issue memory transactions to update configuration registers 360. For example, instructions executing at EL0 may not be enabled to access configuration registers 360, but a hypervisor at EL2 may be enabled. When partition ID virtualization is supported, the partition ID used in cache 300 is the physical partition ID, and an operating system attempting to set resource control parameters to be used for a corresponding application's partition ID specifies the virtual partition ID. Thus, to prevent the operating system from updating an incorrect resource control parameter, an access to an address mapped to configuration registers 360 may be trapped and trigger an exception that switches processing to the hypervisor at EL2. An exception handler in the hypervisor can then issue a corresponding memory transaction with the correct physical partition ID to update the associated set of parameters 320 in cache 300. To accomplish this, in a two-stage MMU translation process, the address associated with memory-mapped registers 360 may be placed in a different stage 2 address page than other address spaces used by memory system components.

[0066] Similar to resource control partitioning, performance monitors in cache 300 may be partitioned based on performance monitor group (and partition ID in embodiments where PMG is a sub-property of partition ID) and security state. Several performance monitors 380 may be provided, each configurable to measure, count, or calculate performance metrics based on filters programmed in a set of filter parameters 382 corresponding to that performance monitor 380. Filter parameters 382 may include fields to specify PARTID and PMG, and upon receiving a memory transaction, if filter parameters 382 set a particular value for the PARTID / PMG field, the performance monitor may determine whether to update the performance monitor's metrics based on the transaction depending on whether the PARTID / PMG value associated with the transaction matches the value set in filter parameters 382. It should be noted that in implementations supporting the first cache allocation mode, if an allocation counter 326 is provided to track whether an allocation threshold is exceeded, the same allocation counter 326 may also be used for performance monitoring.

[0067] If cache 300 is an address translation cache, such as a TLB or page walk cache, partitioning cache allocation resources in this manner may be useful to ensure that one software execution environment cannot allocate more than a percentage / portion of its allocated address translation cache capacity in order to leave space for other software execution environments and reduce the "noisy neighbor" effect.

[0068] FIG. 9 shows one example of a cache 300, however other memory system components may have a similar set of memory mapped configuration registers 360 for configuring memory system component parameters associated with a given partition ID / performance monitoring group / security state and resource control parameter registers 320 for specifying a set of configuration data for the corresponding partition ID.

[0069] In particular, with respect to other memory system components (eg, memory controller 24 or interconnects 14, 18, etc.), any of the following forms of resource partitioning may be implemented:

[0070] Memory Channel Bandwidth Partitioning The bandwidth of the main memory channel may be partitioned. Two bandwidth control schemes may be provided. The memory channel may optionally be partitioned: The minimum bandwidth a partition requires, even in the presence of contention. The maximum bandwidth limit available to a partition in the presence of contention. One or both of the following may be implemented: Any combination of these control schemes may be used simultaneously on channels that support them. Each of the control schemes is described in the following sections.

[0071] Minimum Bandwidth Control Scheme The minimum bandwidth control scheme gives preference to requests from a partition when the partition's current bandwidth is below a minimum, and allows the partition's requests to compete with other regular requests when the partition's current bandwidth exceeds the partition's minimum bandwidth. Thus, a partition's requests that are below the partition's minimum bandwidth are most likely to be scheduled on a channel. The minimum bandwidth control scheme tracks memory bandwidth during an accounting period. A partition's requests are preferentially selected to use channel bandwidth if the partition's bandwidth usage as tracked during the accounting period is currently less than the partition's minimum. If the bandwidth usage by a partition as tracked during the accounting period is currently greater than the partition's minimum, the partition's request competes with other normal priority requests for bandwidth use on the channel. Bandwidth not used by a partition during the accounting window does not accumulate. A register in a memory system component can specify a minimum bandwidth limit for a given partition ID as scaled megabytes per second. The scaled value of megabytes per second is calculated as the desired megabytes per second multiplied by a scale factor that may be defined by the hardware.

[0072] Maximum Bandwidth Limit Control Scheme The maximum bandwidth limit control scheme gives a partition normal priority up to the partition's maximum bandwidth limit during an accounting period. If the bandwidth usage by a partition as tracked during the accounting period is currently less than the partition's maximum value, the partition's requests compete with normal priority for scheduling on the memory channel. If the bandwidth usage by a partition as tracked during the accounting period is currently greater than the partition's maximum bandwidth limit, the partition's requests compete with other lower priority requests for bandwidth use on the channel.

[0073] The maximum bandwidth limit control scheme gives normal priority to requests from a partition when bandwidth usage is below the maximum bandwidth limit, and gives non-priority to requests from a partition when bandwidth usage exceeds the maximum bandwidth limit. Thus, in the absence of contention for channel bandwidth, a partition may use more than the maximum bandwidth. Requests for bandwidth when a partition's bandwidth usage is below the partition's maximum limit are scheduled with normal priority, and thus, depending on the competing requests, not all of a partition's requested bandwidth that is below the partition's maximum limit may be granted by the channel scheduler. Bandwidth not used by a partition during the accounting window does not accumulate.

[0074] Again, the control parameter for the maximum bandwidth limit may be specified as scaled megabytes per second, where the scaled value of megabytes per second is calculated as the desired megabytes per second multiplied by a scale factor that may be defined by the hardware.

[0075] When both the minimum bandwidth control scheme and the maximum bandwidth limit control scheme are implemented, the following table shows the priority of the requests.

[0076] [Table 1] * It should be noted that priorities may generally be defined as high, medium, or low to increase the likelihood that high priority requests will be serviced before medium or low priority requests, although an implementation may still deviate from the priority order when servicing requests to meet other goals of the implementation, such as starvation avoidance.

[0077] For all of the above schemes, all of the control parameters for the bandwidth partitioning scheme may be expressed in a given unit, for example, megabytes per second. This value also corresponds to bytes transferred per microsecond. An implementation may require that each of the bandwidth partitioning control parameters be multiplied by a constant scale factor before the resulting value is programmed into one of the memory system component's bandwidth control registers for the partition ID. Whether an implementation requires scaling of the control parameters and, if so, the scale factor, may be specified in a discovery register in the memory system component (similar to the cache discovery register 362 described above).

[0078] For all of the above memory bandwidth partitioning schemes, memory channel bandwidth adjustments may occur over an accounting period. The accounting period may be either a fixed window or a moving window. The width of the window may be a discoverable constant that may be read from a discovery register in the memory system component. For example, the accounting period may be at least 1 microsecond, and the accounting period may be up to 20 microseconds or more. Longer accounting periods may require more hardware, especially in a moving window implementation, and shorter accounting periods may have more boundary effects, especially in a fixed window implementation.

[0079] In fixed window accounting, bandwidth is allocated to requests so that each partition gets bandwidth according to the minimum and maximum values ​​for that partition. Requests or local priorities can be used to resolve competing requests for bandwidth. When the duration of an accounting window is reached, a new window begins with no history, except for a queue of previously unserviced requests. The new window starts accumulating bandwidth from zero for each partition.

[0080] In moving window accounting, a moving window keeps a history of bandwidth by partition from all commands issued in the past window width. There is no reset of the bandwidth accounting per partition; rather, bandwidth is added as a command is processed and removed from the accounting when that command moves out of the window history. This continuous accounting is relatively free of boundary effects, but requires more hardware to track the history of commands within the window, in addition to the bandwidth counters per partition ID required by a fixed window.

[0081] The minimum bandwidth allocations of all partitions may add up to more bandwidth than is available. This is not a problem when some partitions are not using their bandwidth allocation, because the unused allocation is available for other partitions to use. However, when the minimum bandwidth is over-allocated, the programmed minimum bandwidth for a partition may not always be met. Software can ensure that the minimum bandwidth is not over-allocated to ensure that the programmed minimum bandwidth allocation is delivered reliably by the system.

[0082] Because available bandwidth may depend on one or more clock frequencies in many systems, such as DDR clocks, software may want to reallocate bandwidth when changing clocks that affect available bandwidth. Reducing the clock rate without changing the allocation may result in over-allocation of bandwidth. Note that the available bandwidth in a DRAM channel is not constant, but varies with clock rate, read and write mix, and bank hit rate.

[0083] Those skilled in the art will appreciate that the type of bandwidth control described is not limited to use only in memory channel controllers, but may be deployed to control bandwidth in any memory system component.

[0084] Priority Partitioning Unlike other memory system resources described herein, priority does not directly affect allocation of memory system resources, but instead has an effect on contention that arises for access to the resource. A properly configured system should rarely have significant performance effects due to prioritization, but priority does play an important role in situations of oversubscription, whether immediate or sustained. Thus, "priority partitioning" can be used as a tool to help isolate memory system effects between partitions.

[0085] Partitions can be assigned priorities in each of the components in a memory system (that supports priority partitioning). This partitioning control allows different parts of the memory system to be set up to handle requests with different priorities. For example, requests from the processor to the system cache may be set to use a higher transfer priority than requests from the system cache to main memory.

[0086] Two types of priority may be identified for each partition ID. The internal priority controls the priorities used in the internal operations of this memory system component. The internal priority may be used within the memory system component to prioritize internal operations. For example, a memory controller may use the internal priority to select between waiting requests when bandwidth allocation does not pick a clear winner. Downstream priority controls the priority communicated downstream to another memory system component (e.g., to an interconnect or memory controller). "Downstream" refers to the direction of communication for a request. An "upstream" response typically uses the same transfer priority as the request that generated it. Memory system components use downstream priority to indicate priority over downstream components that do not have priority partitioning. This can be used to set transfer priority for downstream interconnect components. On the other hand, if a component does not implement priority partitioning, or if the component does not implement downstream priority, the component may use "through priority", where the downstream priority is the same as the incoming (upstream) priority or request. Similarly, the priority of a response passing through a memory system component (from downstream to upstream) is the same priority as the response received (from downstream).

[0087] Resource Control Parameter Constraints In the above examples, various memory system component (MSC) resource control parameters are described that may be used to control allocation of resources or management of contention for resources in the MSC. For example, the resource control parameters may include either threshold capacity based control or portion based control as shown in the cache examples of Figures 9-11 above, or may include minimum or maximum bandwidth control for memory bandwidth allocation as shown in the example of Figure 2, or may include priority based control. As shown in the example of Figure 9 above, the resource control parameters may be updated using memory accesses to certain memory mapped registers of the MSC. The memory map defined by the page table used to control memory accesses by the MMU 70 may specify which software processes are allowed to access memory addresses mapped to configuration registers used to set the resource control parameters of a given MSC. For example, one approach may be that the resource control parameters for software processes in a particular operating state of the processing circuit may be accessible by the most privileged level software associated with that operating state. For example, the resource control parameters associated with a secure partition identifier may be updatable by the most privileged level code (or the second most privileged) running in a secure domain such as a hypervisor or operating system. Non-secure code may not be enabled to write to memory-mapped registers that control updates of resource control parameters associated with the secure state, whereas most-privileged (or second-most-privileged) code running in the non-secure domain may be enabled to set resource control parameters associated with the non-secure partition.

[0088] Thus, software in the secure domain can reserve some portion of resources (such as a fraction of cache capacity) for the exclusive use of the software by setting resource control parameters associated with a partition identifier for the secure software execution environment. For example, the secure software can set a cache partition bitmap as shown in FIG. 11 to leave at least a portion of the cache available for allocation for the secure process, while the partition bitmaps for other processes specify that the portion is not allocated to those other processes. In particular, the secure software can set a partition bitmap for a non-secure partition ID to leave the dedicated portion of the cache unallocated for those other partition IDs.

[0089] However, if the non-secure software is also able to set resource control parameters for non-secure partition IDs, then the non-secure software can update the partition bitmap for one of those non-secure partition IDs to indicate that the dedicated portion of the cache reserved by the secure software may also be allocated for the non-secure software, effectively violating the dedicated use expected by the secure software.

[0090] A similar problem may exist where some real-time software is granted exclusive access to a resource, but then subsequently partition identifiers associated with other processes are assigned access to the reserved portions by updating memory system component resource control parameters for these other partition IDs, which may make it difficult for the real-time software to meet its service guarantees.

[0091] In the following example, a memory system component (MSC) is provided with a programmable constraint storage circuit, which stores at least one resource control parameter constraint that can be used to constrain updates that may be made to resource control parameters used to manage allocations or contention for resources, or to constrain the use of resource control parameters when processing memory transactions. Access to the resource control parameter constraints stored in the programmable constraint storage circuit is restricted to a subset of operational states, e.g., the secure domain. This allows the subset of operational states to restrict which resource control parameters are enabled in other states to reduce the chance that a previously configured partitioning of resources is compromised by a subsequent update to the resource control parameters. This can be particularly useful for enforcing dedicated use of cache or bandwidth resources for certain secure or real-time software.

[0092] Figure 12 illustrates an example of a memory system component, which may be one of the caches 8, 12, 16, 20 or memory controller 24 as in the above examples. Although not shown in Figure 12 for the cache example, it will be understood that the MSC of Figure 12 may also include some of the components shown in Figure 9, such as cache storage 302, allocation count register 326, memory mapped status and configuration register 360, and performance monitoring storage 380, 382.

[0093] The MSC has a set of resource control parameter storage circuits 400 (e.g., registers) that store a set of resource control parameters, one for each of the partition identifiers. A multiplexer 402 selects between the sets of control parameters based on the partition identifier (and security domain indicator) associated with a request for use of a memory system resource. The partition identifier and security indicator are generated by the processing element issuing the request as described above. The selected set of resource control parameters is used by the resource control circuitry 404 to control the allocation of resources for processing memory transactions associated with the specified partition identifier or for managing contention for resources. The particular control exercised by the resource control circuitry may vary depending on the type of memory system component, e.g., for a cache, the control may be which cache entries may be allocated to store data associated with the memory transaction, and for a memory controller, the control may be whether bandwidth on the bus may be allocated to the transaction.

[0094] The MSC has a resource control parameter update circuit 410 for controlling the update of the resource control parameters 400 in response to a parameter update request 412 received from a processing element. For example, the parameter update request 412 may be a store memory transaction that specifies a memory address mapped to one of the resource control parameter registers 400 as the target address of the store memory transaction. Alternatively, in an example using memory-mapped state or configuration registers 360, such as the example shown in FIG. 9, the parameter update request 412 may specify an address mapped to one of the configuration registers 360, and updates made to these configuration registers 360 may then control the resource control parameter update circuit 410 to update the corresponding resource control parameter register 400. This approach of using configuration registers may help reduce the number of addresses that need to be exposed to the memory map, as compared to when each corresponding resource control parameter register has its own memory-mapped address. It will thus be appreciated that there are several ways in which the resource control parameters may be updated in response to a parameter update request.

[0095] When a parameter update request is received specifying a new value to be written to at least one target resource control parameter associated with at least one partition identifier, in some embodiments the resource control parameter updating circuit 410 controls whether the update of the target resource control parameter is allowed based on at least one resource control parameter constraint stored in the programmable constraint storage circuit 420. For example, a resource control parameter constraint may limit a minimum or maximum value that may be set for a resource control parameter, or may specify whether a certain portion of a memory system resource is allowed to have its corresponding resource control parameter updated to indicate that portion of the resource as allowed to be assigned to any partition identifier. Thus, when updating a target resource control parameter in response to a parameter update request 412, the resource control parameter updating circuit 410 considers whether the requested update satisfies the constraints specified in the programmable constraint storage circuit 420, and if the parameter update request violates these constraints, the resource control parameter updating circuit 410 may reject the request, or the resource control parameter updating circuit 410 may comply with the request to the extent allowed by the constraints. For example, instead of setting a value that violates a constraint, the resource control parameter update circuit 410 can set the resource control parameter to a value different from the requested value, where the different value satisfies the constraint.

[0096] Thus, in this manner, constraints can be used to ensure that once a certain set of resource control parameters has been established in the MSC's registers 400, subsequent updates cannot update these parameters outside the limits of the constraints defined in the programmable constraint storage circuit 420. This provides better assurance of expected resource partitioning for certain critical software, such as secure software executing in the secure domain 90, or real-time critical software that requires certain bounds on response latency.

[0097] Alternatively, instead of applying the constraints when updating the resource control parameters, the constraints may be applied by the resource control circuitry 404 when using the resource control parameters 400 to control the processing of memory transactions, as will be further described below with reference to FIG.

[0098] Regardless of whether the constraints are applied when updating or using resource control parameters, the programmable constraint storage circuit 420 is programmable in response to a constraint update request 422 issued by the processing circuit of a given processing element 6. For example, the programmable constraint storage circuit 420 may comprise one or more memory-mapped registers in the MSC, which may be updated by issuing a store memory transaction specifying a memory address mapped to one of these registers as a target address of the store memory transaction. The programmable constraint storage circuit may be programmable in response to a constraint update request 422 when the constraint update request 422 is issued by the processing circuit 6 when in one of a restricted subset of operating states (excluding at least one operating state of the processing circuit 6). Thus, programming of the programmable constraint storage circuit may be inhibited in response to a constraint update request 422 when the constraint update request 422 is issued by the processing circuit 6 when in an operating state other than one of these restricted subsets of operating states. This ensures that software execution environments that are enabled to set resource control parameters 400 but that are not one of the restricted subset of operating states are forced to adhere to the constraints set by the software executing in one of the restricted subset of operating states, which provides stronger guarantees of resource control parameter constraints that are enforced by the restricted subset of operating states.

[0099] For example, the processing circuitry may operate in one of the secure domain 90 and the less secure domain 92 as described above, and the restricted subset of operating states may include at least one operating state in which the processing circuitry operates in the secure domain. Thus, the secure software may be able to set the resource control parameter constraints stored in the programmable constraint storage circuitry 420, but the non-secure software in the less secure domain 92 may not be able to set the constraints. This means that updates to the resource control parameters 400 performed by the non-secure software are subject to the constraints imposed by the secure software. This enables central control from the secure domain of the resource allocation caps or limits imposed on the non-secure software, limiting the extent to which the non-secure software can change previously established resource control parameters 400 established by the secure software.

[0100] In one example, the enforcement that constraint update request 422 can only succeed if issued from a restricted subset of operating states (such as the secure domain) may be done through control of memory maps defined in page tables used by memory management unit 70. For example, addresses mapped to registers corresponding to programmable constraint storage circuit 420 may be defined in any page table structure as accessible only to secure code and may not be accessible to non-secure code. These addresses may also be further restricted in access based on privilege level, such that only secure code associated with a given privilege level or higher can access the memory mapped registers to store resource control parameter constraints.

[0101] When the programmable constraint storage circuit 420 is reprogrammed to update the resource control parameter constraints to new values, it is possible that the current values ​​of some of the memory system component resource control parameters stored in the registers 400 may violate the new values ​​of the constraints set in the programmable constraint storage circuit 420. In this case, there is no need to change the old values ​​of the resource control parameters in the registers 400 despite the violation of the new constraints. The MSC preferably retains the current value of any given MSC resource control parameter that violates the new value of the constraint, even though it is now outside the limits indicated by the resource control parameter constraints 420. This ensures that secure software or other software that is capable of setting constraints is allowed to first set some resource-rich setting in the resource control parameters that govern its own resource allocation or that govern the allocation for some preferred software execution environment (such as real-time software), and then set the resource control parameter constraints 420 to a less resource-rich threshold to constrain future updates to the resource control parameters in the registers 400 while still retaining the previously set resource-rich controls. If the constraint control software then subsequently needs to add new resource-rich settings to the resource control parameters 400 that violate the current constraint values, the constraint control software can temporarily relax or remove the constraints defined in the programmable constraint storage circuit 420 (e.g., for at least a subset of the partitions, such as the secure partition), then add the new resource-rich resource control parameters to the registers 400, and then restore the constraints in the programmable constraint storage circuit 420 to prevent other software from programming resource control parameter settings that violate the constraints.

[0102] 13 is a flow diagram showing a method of responding to a constraint update request 422 requesting an update of a resource control parameter constraint in the programmable constraint storage circuit 420. In step 450, the constraint update request is received and in step 452, it is determined whether the constraint update request is issued from a secure domain or a less secure domain. In an example where access to the programmable constraint storage circuit 420 is controlled by a memory map used by the MMU 70, then steps 450 and 452 may actually be performed by the MMU 70 and not by the MSC receiving the constraint update request. In an alternative, the constraint update request may be forwarded to the MSC with an indicator indicating the domain 90, 92 from which the request is issued, regardless of checking from which domain the request is issued, and then some circuitry in the MSC can check whether the constraint update request is issued from the secure domain. In this case, step 452 is performed in the MSC itself.

[0103] Thus, if it is determined in step 452 that the constraint update request originates from the less secure domain 92, then in step 454 the constraint update request 42 is rejected. If the constraint update request originates from the secure domain, then in step 456 the constraint update request is responded to by the MSC, which updates at least one resource control parameter constraint stored in the programmable constraint storage circuit 420 to one or more new values ​​specified in the constraint update request. Following the constraint update, in step 458 the old values ​​of the MSC resource control parameters 400 are retained even if they violate the new values ​​for the constraints set in the programmable constraint storage circuit 420 in response to the constraint update request. This ensures that the previously assigned resource-rich settings are retained even if future updates are restricted.

[0104] FIG. 14 shows a flow diagram illustrating the processing of a received parameter update request 412 in the MSC, which requests an update to a resource control parameter. In this embodiment, a resource control parameter constraint is used as a resource control parameter update constraint that constrains the processing of the parameter update request. In step 470, the resource control parameter update circuit 410 receives a parameter update request 412, which may be, for example, a memory-mapped store transaction as described above. The parameter update request specifies one or more new values ​​to be written to one or more target resource control parameters associated with a given partition identifier. In step 472, the resource control parameter update circuit 410 checks whether the specified new parameter value violates the resource control parameter update constraint set in the programmable constraint storage circuit 420. If not, then in step 474, the new parameter value may be written to the target resource control parameter in the register 400, thus providing a new partition control setting.

[0105] On the other hand, if, at step 472, the new parameter value violates a resource control parameter update constraint specified in the programmable constraint storage circuit 420, different options are available for responding to this event. In one option, at step 476, the parameter update request 412 may simply be rejected, so that the previous value of the target resource control parameter is retained and the update requested by the parameter update request 412 is not made.

[0106] Alternatively, instead of simply rejecting the parameter update request, as shown in step 478, the parameter update request may be complied with to the extent permitted by the resource control parameter update constraint. Thus, in response to a parameter update request 412, when a new value for a target memory system component resource control parameter violates a resource control parameter update constraint, the resource control parameter updating circuit 410 of the MSC sets the target MSC resource control parameter to a value that satisfies the resource control parameter update constraint instead of using the new value that violates the constraint. For example, the resource control parameter updating circuit 410 may attempt to set the target MSC resource control parameter to grant access to the memory system resource to the same extent as permitted by the constraint. For example, the target MSC resource control parameter may be set to a value that coincides with a threshold defined in the resource control parameter update constraint instead of being set to the new parameter value specified in the parameter update request. Thus, in this approach, if a given software process requests that parameters be updated to grant too many resources to a given partition identifier, the MSC instead grants access to the resources only as much as permitted within the limits of the constraints set in the programmable constraint storage circuit 420. This approach can improve performance (avoiding unnecessarily resource-poor settings for processes that may be granted more resources, while still respecting constraints enforced by some constraint control software such as secure code).

[0107] Regardless of which of the options at steps 476 and 478 are taken, at step 480 the resource control parameter update circuit 410 may determine whether constrained error reporting is supported and enabled for this particular MSC. If constrained error reporting is supported and enabled, then at step 482 an error reporting action is performed. This error reporting action may be at least one of recording the error reporting information in an error reporting storage element and / or signaling an interrupt. On the other hand, if error reporting is not supported, or in implementations that do not support error reporting, if error reporting is not currently enabled, then at step 484 no error reporting action is performed.

[0108] In general, it may be useful to have software know if a parameter update request has not been fully satisfied due to a parameter update request specifying a new parameter value that violates a parameter update constraint. This may be useful for debugging, so that if the software is not behaving as expected, for example because it is getting less access to memory system resources than expected, the reason for this may be known. This may aid in code development.

[0109] Some hardware implementations may not support error reporting at all, in which case no error reporting action may be performed when new parameter values ​​for a parameter update request violate parameter update constraints, and thus for such implementations the method always proceeds to step 484.

[0110] However, for other implementations that support error reporting, this may be useful to improve debugging capabilities so that software can receive notification if a request resource control parameter update has been downgraded due to a constraint set in the programmable constraint storage circuit. Some such implementations that support error reporting may permanently enable error reporting so that the method always proceeds to step 482 and step 484 is never performed.

[0111] However, in other implementations that provide hardware support for error reporting, whether error reporting is enabled or disabled may depend on programmable configuration information stored in a configuration storage element. For example, the configuration storage element may be another memory-mapped register in the MSC that stores parameters that enable or disable error reporting. In some cases, the configuration may simply be that error reporting is performed or not performed at all. In other examples, the configuration information may also specify more detailed properties of error reporting, such as defining a particular error reporting action to be taken (e.g., the configuration information may be configurable as to whether an interrupt is signaled when an error reporting action is performed, or whether the error is simply logged in the error reporting storage element without signaling an interrupt). Another error reporting configuration option may be to report the occurrence of some types of errors and not report the occurrence of other types of errors. Thus, constraint errors may be configurable to be reported or not reported.

[0112] Resource control parameter constraints are considered generally in the examples of Figures 12 to 14. Figures 15 to 17 show examples of more specific types of constraints that may be imposed on corresponding types of MSC resource control parameters.

[0113] FIG. 15 illustrates an example of constraining updates to resource control parameters using a portion bitmap as in the example of FIG. 11 above. For example, FIG. 15 illustrates a cache portion bitmap (CPBM) 502 for a partition ID that may be used to control allocation to the cache for requests associated with that partition ID, the bitmap including several bits, each corresponding to a portion of the cache capacity. When a given bit has a value of 0, this indicates that software for the corresponding partition ID is not allowed to allocate data to the corresponding portion of the cache, and when the bit has a value of 1, software for the corresponding partition ID is allowed to allocate data to the corresponding portion of the cache. Although FIG. 15 illustrates an example of controlling cache allocation based on such a portion bitmap, it is also possible to provide portion-based resource allocation control parameters for other types of memory system components. For example, portion-based control may be imposed on memory bandwidth allocation by providing several independent types of bus credits and using a portion-based bitmap to indicate which types of bus credits are allowed to be used by a particular partition identifier. Thus, in general, a portion-based resource allocation control parameter may be provided that specifies, for each of two or more portions of a resource, whether that portion of the resource is enabled to be allocated for use by a software execution environment associated with a corresponding partition identifier.

[0114] As shown in FIG. 15, when portion-based resource allocation control parameters are used, the resource control parameter update constraints may also be defined as a bitmap 500 acting as a mask, masking updates to at least a subset of the resource control bitmap 502 specified as the portion-based resource allocation control parameters. The mask bitmap (CPMBM) 500 acts as a portion-based constraint that specifies, for each of a subset of portions of the resource that have corresponding bits in the portion bitmap 502, whether any of the portion-based resource allocation control parameters 502 for a given partition ID are allowed to be updated to indicate that particular portion as being allowed to be allocated for use. For example, in the encoding shown in FIG. 15, if a given bit 504 of the portion mask bitmap 500 is 0, then the corresponding bit of the portion bitmap 502 is allowed to be set to 1 to indicate that the corresponding partition ID is allowed to use the corresponding portion of the cache or memory resource. On the other hand, when a given bit 506 of partial mask bitmap 500 has a value of 1, this may indicate that the corresponding bit is not enabled to be set to 1. Note that mask bitmap 500 is shared among all partial bitmaps 502 associated with all partition identifiers (FIG. 15 only shows partial bitmap 502 for one partition ID, but each of the other partition IDs has its own partial bitmap), and thus each of the partial bitmaps is subject to the same update constraints defined in partial mask bitmap 500.

[0115] Thus, the portion mask bitmap 500 acts as a portion-based constraint that constrains what updates can be made to the portion-based resource allocation control parameters 502 to limit the resources that can be requested in a subsequent request. This means that if the secure domain software assigns exclusive use of a portion of a memory system component resource to itself or to some other software execution environment, sets a control parameter for the partition identifier of another partition to exclude that other partition from using the reserved dedicated resource, and then sets a constraint in the portion mask bitmap 500 with a bit equal to 1 in the location that corresponds to the reserved portion, this prevents any other control software from subsequently updating the resource control bitmap 502 for any partition ID to change the bit that corresponds to the reserved portion from 0 to 1.

[0116] In one exemplary implementation, when an update of partial bitmap 502 is attempted and a given bit of partial bitmap 502 is set to 1 for the update of partial bitmap 502, but the corresponding bit of partial mask bitmap 500 specifies that this is prohibited, the given bit of partial bitmap 502 retains its previous value (so that if previously set to 0, the bit remains 0 even though the corresponding bit of new partial bitmap value 508 is 1, but if a given bit of partial bitmap was 1 before the update, it can retain its value of 1 after the update). However, this behavior is not required.

[0117] A second approach may be that when updating the partial bitmap 502, the "masked out" bits of the partial bitmap 502 (the "masked out" bits correspond to the "1" bits 506 of the partial mask bitmap 502, which "1" bits 506 indicate that the corresponding bit of the partial bitmap 500 is prohibited from being set to 1) are cleared to 0, regardless of the previous state of the "masked out" bits. In other words, the mask bitmap 500 is applied when an update is applied to the partial bitmap 502, and the "not allowed" bits 506 in the mask bitmap 500 force the corresponding "masked out" bits in the partial bitmap 502 to be cleared (to indicate that the portion of the resource may not be allocated to requests with the corresponding partition ID). Thus, the previous values ​​of the "masked out" bits of the partial bitmap 502 are not important when this approach is taken. This may be useful because it may be that the associated entry in the control settings table has been updated since the corresponding PARTID has been reused for the new software environment, and thus it may be preferable to ensure that a previously assigned setting for the previous software environment is cleared if that setting violates a constraint defined in partial mask bitmap 500. Thus, in this embodiment, the "masked out" bit identified by partial mask bitmap 502 indicates that the new value 508 for partial bitmap 500 cannot allow that portion of the resource to be assigned to the partition ID, and thus, after a subsequent write to partial bitmap 500 for the partition ID, the corresponding bit in the newly written partial bitmap 500 should indicate that assignment of that portion of the resource is not enabled (e.g., in this embodiment, that bit should be 0).

[0118] In this second approach, this constraint on the update of the partial bitmap 500 may be implemented by combining the new bitmap value 508 specified in the parameter update request with the constrained partial mask bitmap 500, whereby the new value is bitwise ANDed with the result of the inversion of the corresponding bit in the partial mask bitmap 502. In other words, CPBM'[PARTID i ] j =CPBMnew j AND(NOT(CPMBM j )), where CPBM'[PARTID i ] j ) is the new value set for bit j of the partial bitmap 500 for partition ID i after the requested update, and CPBMnew j is bit j of the new value 508 requested to be written to the partial bitmap 500 for partition ID i, and CPMBM j is the value of bit j of constrained partial mask bitmap 502. This approach means that bits in new bitmap value 508 that correspond to bits of 1 in partial mask bitmap 500 are cleared to 0. For example, in the particular case shown in Figure 15, the new partial bitmap value 508 specified in the parameter update request requested that bitmap 502 be updated to indicate that resource portions 0 and 1 can be allocated to the corresponding partition identifier, but because bits 0 and 1 in partial mask bitmap 500 are set to 1, this instead constrains the update and clears bits 0 and 1 of the corresponding partition's partial bitmap 502 to 0.

[0119] Note that it is not necessary for partial mask bitmap 500 to have the same number of bits as partial bitmap 502. Typically, at least some portion of the resources in the cache or memory component must be allocated to other software execution environments, so in practice it is unlikely that the software controlling the constraint storage circuit 420 would impose a constraint to prevent the entire partial bitmap 502 from being changed from 0 to 1. In practice, there is a hardware cost to implement the storage for partial mask bitmap 500 in the programmable constraint storage circuit 420, and also a hardware cost to implement the logic to combine each of the bits of partial mask bitmap 500 with the new value 508 for the partial bitmap. To limit this hardware cost, there may be a limit on the number of portions that can be constrained by the partial mask bitmap, so for bits of partial bitmap 500 that fall outside the range covered by partial mask bitmap 502, the partial mask bits for these portions may be implicitly assumed to be equal to 0, so that updates for these portions of the memory system component resources are unconstrained. That is, a partial mask bitmap (part-based constraint) may actually constrain updates to only a subset of the parts of a resource, which may exclude at least one part of the resource, which may be more efficient in terms of hardware. In this case, if the secure software controlling the constraint wants to reserve a part of the resource for its own use or for use by a specified other software execution environment, the secure software may be forced to select one of the parts that corresponds to an explicitly stored bit in the partial mask bitmap 500 as the reserved part of the resource.

[0120] Thus, in summary, if the memory system component resource control parameters include portion-based resource allocation control parameters that specify, for each of two or more portions of a resource, whether the portion is allowed to be allocated for use by a software execution environment associated with a corresponding partition identifier, the constraint may include a portion-based constraint that specifies, for each of a subset of the portions, whether the corresponding portion-based resource allocation control parameter is allowed to be updated to indicate the portion as allowed to be allocated. If the parameter update request requests that the portion-based resource allocation control parameter be updated to indicate that a given portion of a resource is allowed to be allocated and the portion-based constraint specifies that the given portion is prohibited from being updated to indicate that the given portion is allowed to be allocated, then the portion-based resource allocation control parameter may instead be set to indicate that the given portion of the resource is prohibited from being allocated. An example of this is shown at the bottom of FIG. 15, where in this example bits 0 and 1 of partial mask bitmap 502 have been set to 1 to indicate that a 0 to 1 transition in the part-based constraint is prohibited for these parts 0 and 1 of the available resources, so the requested update to set bits 0 and 1 of partial bitmap 500 equal to 1 is denied and instead these bits are set equal to 0 in the new value written to partial bitmap 502.

[0121] It will be appreciated that the particular encoding shown in Figure 15 is not required. For example, other implementations may reverse the meaning of 0's and 1's in one or both of partial bitmap 502 and partial mask bitmap 500.

[0122] As shown in FIG. 16 and as previously described, other MSCs may define fraction-based resource control parameters, which set limits on the maximum fraction of resources that are allowed to be allocated to software associated with the corresponding partition identifier. For example, FIG. 16 shows an example where the maximum fraction of cache allocation for a given partition identifier is defined by a cache allocation threshold 520, which in this example is set to 40% of the cache capacity. When a capacity fraction limit is imposed in the MSC resource control parameters, the corresponding parameter update constraint can be a further fraction 522, which sets a limit on the maximum fraction that is allowed to be specified in the fraction control 520. Again, the constraint 522 can be shared between each of the fraction control parameters 520 for each of the partition IDs (FIG. 16 only shows fraction control parameters 520 for a single partition ID for simplicity). For example, in FIG. 16, the maximum fraction that can be set in the resource control parameters 520 is set in the constraint storage 522 as being 50%. Thus, an attempt to update resource control parameters 520 to allocate a partition more than 50% of the storage may be rejected or may only be partially satisfied to the extent permitted within the upper limits set in programmable constraints 522. In this manner, when a new value 524 is specified by a parameter update request 412 that is written to fraction-based control 520, that new value 524 may be combined with the limits specified in parameter update constraints 522 by a minimum determination circuit 526 that outputs the minimum of values ​​522, 524, and the resulting minimum value 528 is then written to the capacity threshold fraction value 520 for the corresponding partition identifier.Thus, if the requested new value 524 is less than or equal to the limit specified in the parameter update constraint 522, the new value is simply written to the associated resource control parameter 520, but if the new value exceeds the limit, the limit value is written instead, so that the corresponding partition is not allocated more resources than allowed by the constraint.

[0123] 17, in an example having a memory controller or other memory system component that imposes minimum and maximum bandwidth thresholds 530 and 532 as previously described, corresponding minimum and maximum constraint limits 534 and 536 may be provided within the programmable constraint circuit 420 that limits the maximum values ​​that may be written to each of the minimum and maximum bandwidth values ​​530 and 532, respectively. Again, a single instance of the minimum or maximum threshold limit 534 or 536 may be shared among the bandwidth controls 530, 532 for all partition IDs. As in FIG. 16, the constraint values ​​534, 536 are combined with new values ​​538, 540 written to one of the minimum and maximum bandwidth limits 530 and 532 using minimum value determination circuits 542, 544, such that the values ​​written to the resource control parameters 530, 532 for the minimum and maximum bandwidth values ​​are capped at the levels specified in the corresponding constraint values ​​534, 536 for both the minimum and maximum bandwidth. Thus, by capping updates to maximum bandwidth to a certain level, this prevents a given partition from being allocated more than its share of memory bandwidth permitted by constraint control software such as secure domain code, and by preventing minimum bandwidth from being set above a certain threshold level, this ensures that there is a limit to the extent to which memory transactions can have increased priority when the allocated bandwidth is below the minimum threshold.

[0124] 16 and 17 are examples where the set of memory system component resource control parameters includes a resource allocation threshold parameter, the resource allocation threshold parameter indicating either a maximum or minimum threshold for controlling allocation of resources for use by a software execution environment associated with the corresponding partition identifier, or a maximum or minimum threshold for controlling management of contention for the resources. The resource allocation threshold parameter may be a maximum threshold, such that further allocation of resources is prevented if such allocation would cause an amount of resources greater than the maximum threshold to be allocated to the corresponding software execution environment (as in examples 520, 532 shown in FIGS. 16 and 17). Alternatively, the resource allocation threshold parameter may indicate a minimum threshold, as in example 530 shown in FIG. 17, such that a request issued by the corresponding software execution environment may be prioritized when the current fraction or amount of resources allocated to the corresponding software execution environment is less than the minimum threshold indicated by the resource allocation threshold parameter.

[0125] Either way, whether the threshold is a minimum or maximum value, the resource control parameter update constraints may specify a threshold upper constraint (e.g., examples 522, 534, 536 shown in Figures 16 and 17) that specifies an upper threshold value. When a parameter update request requests an update of the resource allocation threshold parameters 520, 530, 532, the memory system component may prohibit the resource allocation threshold parameters 520, 530, 532 from being updated to indicate a threshold as either a maximum or minimum threshold that is greater than the threshold upper value indicated by the threshold upper constraints 522, 534, 536. In particular, when updating the resource allocation threshold parameters, the memory system component may set the resource allocation threshold parameters to indicate the minimum of the new thresholds 524, 538, 540 specified by the parameter update request and the threshold upper value 522, 534, 536 indicated by the threshold upper constraints.

[0126] 15-17 show some example types of MSC resource control parameters and corresponding example constraints that may be set to include updates to these parameters, although it will be understood that these are not the only examples that may be provided. In another example, a proportional stride resource may be defined. Proportional stride resource control has a stride minus one parameter (STRIDEM 1). STRIDEM 1 is represented as a non-negative integer. A STRIDEM 1 value of 0 gets maximum access to the resource. A STRIDEM 1 value of 1 gets half access to the resource, a STRIDEM 1 value of 3 gets one-quarter access to the resource, and so on. Proportional stride resource control constraints are also non-negative integers. When a new value of STRIDEM 1 is written for a PARTID, the value stored in the control setting storage is the maximum of the new value and the constraint.

[0127] When the processing system is reset (e.g., upon power-up or when a reset signal is received indicating that the device is to be reset to some known, predetermined state), the contents of the programmable constraint storage circuit 420 may be reset to a value indicating that updating of each of the sets and memory system component resource control parameters 400 is not constrained. This therefore allows system firmware executing immediately after power-up or reset to set each of the sets of resource control parameters 400 without restriction, such that dedicated access to certain portions of the resources may be implemented prior to setting the constraints 420, which then protects these resource control settings from subsequent updates by other software.

[0128] Alternatively, in some implementations there may be no hardware circuitry to effect a reset of constraints to values ​​indicative of unconstrained updates to the MSC resource control parameters, in which case firmware or other platform software executing on the device after a reset is responsible for setting up the device appropriately by setting the constraint registers 420 to allow unconstrained updates to resource control parameters until such time as carve out of the dedicated resources has been performed, and then setting constraints in the programmable constraint storage circuit 420 to inhibit subsequent updates.

[0129] Thus, in one possible use of the programmable constraint storage circuit, after a reset firmware that sets up the device, the constraint register 420 can be set so that the constraint register 420 does not have any constraint control settings in the resource control parameters 400. For example, for the portion-based bitmap of FIG. 15, this can be that all bits of the portion mask bitmap 500 can be set to 0. For the fraction-based threshold control in the example of FIG. 16, this can be that the limit value specified in the constraint register 522 is set to the maximum allowed value of the constraint register 522, and similarly, for the example of FIG. 17, the constraint registers 534, 536 that limit the minimum and maximum bandwidth parameters can be set to the maximum allowed constraint value. If the system firmware then needs to allocate some resources for exclusive use early in the boot process, the system firmware can set the appropriate resource control parameters 400 to grant exclusive access to a portion of the memory system resource to itself or some other partition, or to grant a relatively high fraction of the resource to itself or other processes, depending on the control type. Having set up the resource control parameters as necessary, the system firmware can then set constraints to reduce the flexibility for subsequent updates to the control parameters, for example, by setting some bits equal to 1 in the partial mask bitmap 500 of FIG. 15, or by reducing thresholds defined in the parameter update constraint registers 522, 534, 536 as in the examples of FIGS. 16 and 17.

[0130] Once the system is in normal operation, subsequent updates to the constraints may be limited to some control software, e.g., a potentially small piece of software running in the secure domain that acts as a constraint controller. The constraint controller can receive constraint update requests from secure and non-secure software and can decide whether to grant or deny the constraint update request. This software can then alter the contents of constraint registers 420 in specific memory system components as necessary to enforce the constraints.

[0131] In another example, multiple constraints may be set for a given resource, each controlled by a different controller and applying only to accesses from a lower privilege environment. For example, in a system with secure / non-secure domains, the constraints of the secure controller may apply to lower privilege levels in the secure domain and to all privilege levels in the non-secure domain. The non-secure controller may specify constraints that apply to lower privileges in the non-secure environment but not to the secure environment.

[0132] Although several different types of constraints corresponding to different types of resource control parameters are discussed above, it will be understood that any one platform implementation may not use all of these examples depending on the particular memory system components and resource partitioning controls involved, and some implementations may have some memory system components that use one type of constraint and other memory system components that use another type (depending on the type of resource partitioning control implemented in each of the memory system components).

[0133] The examples of Figures 14-17 above describe constraints that are applied at the time of updating resource control parameters for a given partition identifier. As shown in Figure 18, an alternative approach is to allow unconstrained settings of resource control parameters, but use constraints defined in the programmable constraint storage circuit 420 to constrain the use of the resource control parameters when processing memory transactions. For example, if a memory transaction is controlled based on a given resource control parameter, and if a constraint is defined to impose a limit on the given resource control parameter, then even if the stored value of the given resource control parameter violates the limit defined by the constraint, the given resource control parameter may be interpreted as having a constrained value within the limit defined by the constraint, and the constrained value may be used to control resource allocation or manage contention between resources instead of the actual stored value for the given resource control parameter.

[0134] Thus, in the example of Figure 18, resource control parameter constraints may be defined in a similar manner to the examples of Figures 14-17 (e.g., using partial mask bitmap 500 or upper threshold values ​​522, 534, 536), but the constraints may be interpreted as resource control parameter use constraints instead of resource control parameter update constraints.

[0135] Figure 18 illustrates in more detail the steps performed in one embodiment when using resource control parameters to control allocation of resources or manage contention for resources in step 206 of Figure 8. In step 600, a memory system component determines whether the memory transaction being processed is a constrained type memory transaction subject to constraints defined in a programmable constraint storage circuit.

[0136] As shown in FIG. 19, in addition to a partition identifier 602, a memory transaction may specify one or more identifiers, such as a privilege level identifier 604 indicating a level of privilege associated with the memory transaction, a security domain identifier 606 indicating a security domain associated with the memory transaction, and / or a constraint exemption identifier 608 indicating whether the memory transaction is exempt from being constrained based on a corresponding resource control parameter constraint. It will be understood that these are merely some examples and that it is not necessary to use all of these identifiers. In one example, a memory system component may determine whether a memory transaction is a constrained type of memory transaction based on at least one of the identifiers 602, 604, 606, 608 specified by the memory transaction. For example, some specific PARTIDs may be exempt from constraints and other PARTIDs may be constrained. Also, the determination of whether to apply the constraints may be based on whether the memory transaction was issued from a secure domain or a non-secure domain (e.g., secure transactions may not be constrained, while less secure transactions may be constrained). Another approach may be that memory transactions issued from privilege levels below a certain threshold may be constrained, but memory transactions of more privileged processes are not constrained. Also, the constraint exemption identifier 608 may allow some software processes to individually identify a particular transaction as being exempt from constraints, while other transactions from the same software process may be constrained. In some examples, the constraint exemption identifier 608 may be used in combination with one of the other identifiers 602, 604, 606, such that only certain software processes (e.g., secure processes, or processes with privileges greater than a threshold) are allowed to selectively exempt their transactions from constraints, while other software processes may have all of their transactions constrained, regardless of the value of the constraint exemption identifier 608.

[0137] There are a number of options that may be implemented. In some implementations, the determination of whether a memory transaction is constrained or not may depend on programmable configuration data stored in a control register. For example, a privileged process may program the configuration data to specify the PARTID, privilege level, or security domain to which the constraint should or should not be applied, or may set a "mode" indicator that indicates a particular mode for determining whether the memory transaction is constrained or not (e.g., one mode may determine whether the transaction should be constrained based on the PARTID, another mode may determine whether the transaction should be constrained based on the privilege level, and other modes may use a combination of identifiers, such as the exemption identifier 608, in combination with the privilege level 604).

[0138] Thus, regardless of the precise mechanism used to distinguish between constrained and unconstrained types of memory transactions, a determination is made whether the particular memory transaction being processed is a constrained type of memory transaction, step 600. By providing a mechanism by which some memory transactions are exempt from constraints, this allows some preferred processes (such as secure domain processes or real-time critical processes) to use relatively resource-rich settings, while other processes are constrained to use settings within certain limits.

[0139] If the memory transaction is not a constrained type of memory transaction, then in step 610, allocation of resources for the transaction or management of contention for resources is controlled based on unconstrained values ​​of a selected set of resource control parameters stored in configuration table 106.

[0140] If the memory transaction is a constrained type of memory transaction, then in step 612 it is determined whether a given resource control parameter in the selected set of resource control parameters violates a resource control parameter constraint stored in the programmable constraint storage circuit 420. If the given resource control parameter does not violate the constraint, then in step 614 the given resource control parameter may be used (unmodified) to control resource allocation or manage contention for the resource. If the given resource control parameter violates the constraint, then in step 616 a constrained value of the resource control parameter may be used to control resource allocation or manage contention for the resource, the constrained value of the resource control parameter being determined based on the resource control parameter constraint and giving less permission in allowing resources to be allocated than the stored value of the resource control parameter. For example, for a threshold-based resource control parameter, the constrained resource control parameter used in step 616 can be a threshold upper limit specified by the constraint. For portion-based resource control parameters, the constrained resource control parameter used in step 616 may be a modified bitmap, where bits in the modified bitmap that are indicated as masked out by the corresponding portion mask bitmap are assumed to be clear, so that the corresponding portion of the resource may not be allocated to the memory transaction. In step 618, if error reporting is supported by the hardware and enabled (this decision depends on the configuration settings, if supported, whether error reporting is enabled or disabled), error reporting actions are taken as in step 482 of Figure 14 (e.g., log the error reporting information and / or signal an interrupt).

[0141] 18 shows the logic flow at steps 612, 614, 616, in which it is first determined whether a resource control parameter violates a constraint, and then either the unmodified resource control parameter or the constrained resource control parameter is used to control resource allocation or manage contention for the resource. If error reporting is not required, an equivalent approach could omit the determination of whether a given resource control parameter violates a constraint, but instead simply combine the given resource control parameter with the constraint, such that the result of the combination is either the original given resource control parameter (if the parameter did not violate the constraint) or corresponds to the limit indicated by the constraint (if the parameter violated the constraint). For example, for a portion-based approach, the effective value of the partial bitmap 502 used to control resource allocation may be generated by bitwise ANDing the partial bitmap 502 with the inverse of the mask bitmap 500 representing the constraint, similar to the aforementioned bitwise AND function for controlling updates of the partial bitmap 502 in the previous example (alternatively, for different encodings of the partial bitmap 502 or mask bitmap 500, different functions of logical operators may be used to combine the inverses of the partial bitmap 502 and the bitmap 500 to generate the effective value to use for resource control). For a threshold-based approach, the effective value of a cache capacity or minimum / maximum bandwidth allocation threshold to use to handle resource allocation or contention management may be determined as the minimum of the stored value of the threshold and the threshold represented by the constraint (similar to the approaches of Figures 16 and 17). It will thus be appreciated that an actual determination of whether a stored resource control parameter has violated a constraint is not essential if error reporting is not required.

[0142] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration capable of performing a defined operation. In this context, "configuration" refers to an arrangement or method of interconnection of 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 in any way that the apparatus elements need to be modified to provide the defined operation.

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

Claims

1. processing circuitry for processing instructions from one of a plurality of software execution environments; a memory system component for processing memory transactions issued by the processing circuit in response to the instructions; An apparatus comprising: In response to a memory transaction issued by the processing circuitry specifying a selected partition identifier dependent on which software execution environment caused the memory transaction to be issued, the memory system component is configured to control allocation of resources for processing the memory transaction or manage contention for the resources dependent on a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters dependent on the partition identifier specified by the memory transaction; the memory system component includes a programmable constraint storage circuit for storing at least one resource control parameter constraint; based on the at least one resource control parameter constraint stored in the programmable constraint storage circuitry, the memory system component: updating target memory system component resource control parameters; using the target memory system component resource control parameters to control the allocation of resources or to manage contention for the resources; 13. An apparatus configured to constrain at least one of:

2. the processing circuit has a plurality of operating states including a restricted subset of operating states, the restricted subset including at least one of the plurality of operating states; the programmable constraint storage circuitry is programmable in response to a constraint update request issued by the processing circuitry when in one of the restricted subset of operating conditions; 2. The apparatus of claim 1, wherein programming of the programmable constraint storage circuitry is inhibited in response to a constraint update request issued by the processing circuitry when in an operating state other than the restricted subset of operating states.

3. the processing circuitry is configured to operate in one of a secure domain and a less secure domain, and when operating in the less secure domain the processing circuitry is configured to prohibit access to addresses reserved for access by the secure domain; The apparatus of claim 2 , wherein the restricted subset of operating states includes at least one operating state in which the processing circuitry operates in the secure domain.

4. the programmable constraint storage circuitry is reprogrammed to update the at least one resource control parameter constraint to a new value, when a current value of a given memory system component resource control parameter violates a constraint indicated by the new value of the at least one resource control parameter constraint; 4. The apparatus of claim 1, wherein the memory system component is configured to retain the current value of the given memory system component resource control parameter regardless of the violation of the constraint indicated by the new value of the at least one resource control parameter constraint.

5. 5. The apparatus of claim 1, wherein in response to a parameter update request requesting an update of the target memory system component resource control parameter, the memory system component is configured to constrain the update of the target memory system component resource control parameter based on the at least one resource control parameter constraint stored in the programmable constraint storage circuitry.

6. 6. The apparatus of claim 5, wherein in response to the parameter update request requesting that the target memory system component resource control parameter be updated to a new value and when the new value violates the at least one resource control parameter constraint, the memory system component is configured to set the target memory system component resource control parameter to a value that satisfies the at least one resource control parameter constraint.

7. In response to the parameter update request requesting that the target memory system component resource control parameter be updated to a new value and when the new value violates the at least one resource control parameter constraint, the memory system component is configured to perform an error reporting action; The error reporting action is: recording the error report information in an error report storage element; Signaling an interrupt and At least one of:

6. The apparatus of claim 5.

8. 8. The apparatus of claim 7, wherein in response to the parameter update request requesting that the target memory system component resource control parameter be updated to a new value, and when the new value violates the at least one resource control parameter constraint, the memory system component is configured to select whether to perform the error reporting action depending on programmable configuration information stored in a configuration storage element.

9. In response to the memory transaction issued by the processing circuit, and when the memory transaction is a constrained type of memory transaction, the memory system component: controlling the allocation of resources or managing contention for resources based on a given resource control parameter in the selected set of one or more memory system component resource control parameters when the given resource control parameter satisfies a corresponding resource control parameter constraint; Controlling the allocation of resources or managing contention for the resources based on a constrained resource control parameter determined based on the corresponding resource control parameter constraint when the given resource control parameter violates the corresponding resource control parameter constraint. The apparatus according to any one of claims 1 to 8, configured as follows.

10. 10. The apparatus of claim 9, wherein the memory system component is configured to determine whether the memory transaction is of the constrained type based on at least one identifier specified by the memory transaction.

11. The at least one identifier is The partition identifier; and a privilege level identifier indicating a level of privilege associated with the memory transaction; a security domain identifier indicating a security domain associated with the memory transaction; a constraint exemption identifier indicating whether the memory transaction is exempt from being constrained based on the corresponding resource control parameter constraint; The apparatus of claim 10 , comprising at least one of:

12. 12. The apparatus of claim 1, wherein in response to a reset signal indicating that the apparatus is to be reset to a predetermined state, the programmable constraint storage circuit is configured to reset the at least one resource control parameter constraint to a value indicating that updating or using the multiple sets of one or more memory system component resource control parameters is not constrained.

13. For a given memory system component, each of the sets of one or more memory system component resource control parameters is associated with a corresponding partition identifier and includes portion-based resource allocation control parameters that specify, for each of a plurality of portions of a resource, whether that portion of the resource is enabled for allocation for use by a software execution environment associated with the corresponding partition identifier; The at least one resource control parameter constraint includes a portion-based constraint, the portion-based constraint comprising, for each of a subset of portions of the plurality of portions of resources: whether the portion-based resource allocation control parameters are enabled to be updated to indicate the portion of resources as being enabled to be allocated; and and when using the portion-based resource allocation control parameter to control the allocation of resources for constrained-type memory transactions, whether the given memory system component should prevent a portion of a resource from being allocated even if the portion-based resource allocation control parameter specifies that portion of a resource as being allowed to be allocated. The apparatus according to any one of claims 1 to 12, further comprising:

14. The apparatus of claim 13 , wherein the subset of portions excludes at least one of the multiple portions of resources.

15. 15. The apparatus of claim 13 or 14, wherein in response to a parameter update request requesting that the portion-based resource allocation control parameter be updated to indicate that a given portion of a resource is allowed to be allocated, and when the portion-based constraint specifies that the portion-based resource allocation control parameter is prohibited from being updated to indicate the given portion as being allowed to be allocated, the given memory system component is configured to set the portion-based resource allocation control parameter to indicate that the given portion of a resource is prohibited from being allocated.

16. For a given memory system component, each of the sets of one or more memory system component resource control parameters is associated with a corresponding partition identifier and includes a resource allocation threshold parameter indicating a maximum or minimum threshold for controlling allocation of resources or management of contention for resources for a software execution environment associated with the corresponding partition identifier; the at least one resource control parameter constraint includes a threshold upper limit constraint indicating a threshold upper limit value; in response to a parameter update request requesting an update of the resource allocation threshold parameter, the given memory system component is configured to prohibit the resource allocation threshold parameter from being updated to indicate, as the maximum threshold or the minimum threshold, a threshold value greater than the threshold upper limit value indicated by the threshold upper limit constraint; In response to the memory transaction issued by the processing circuit, and when the memory transaction is a constrained type of memory transaction and the resource allocation threshold parameter violates the threshold upper constraint, the given memory system component is configured to control allocation of resources or management of contention for resources based on a constrained threshold that is less than or equal to the threshold upper limit value indicated by the threshold upper constraint. The device according to any one of claims 1 to 15.

17. In response to the parameter update request requesting the update of the resource allocation threshold parameter, the given memory system component: A new threshold value specified by the parameter update request; and the upper threshold value indicated by the upper threshold constraint; 17. The apparatus of claim 16, configured to set the resource allocation threshold parameter to indicate a minimum value of:

18. 18. The apparatus of claim 16 or 17, wherein in response to the memory transaction issued by the processing circuit, and when the memory transaction is a constrained type of memory transaction, the given memory system component is configured to control allocation of resources or management of contention for resources based on a minimum of a threshold indicated by the resource allocation threshold parameter and the threshold upper limit value indicated by the threshold upper limit constraint.

19. means for processing instructions from one of a plurality of software execution environments; means for processing memory transactions issued by said means for processing in response to said instructions; An apparatus comprising: In response to a memory transaction issued by the means for processing specifying a selected partition identifier dependent upon which software execution environment caused the memory transaction to be issued, the means for processing the memory transaction is configured to control allocation of resources for, or manage contention for, processing the memory transaction dependent upon a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters dependent upon the partition identifier specified by the memory transaction; the means for processing memory transactions includes means for programmably storing at least one resource control parameter constraint; The means for processing memory transactions based on the at least one resource control parameter constraint stored in the means for programmably storing, updating target memory system component resource control parameters; using the target memory system component resource control parameters to control the allocation of resources or to manage contention for the resources; 13. An apparatus configured to constrain at least one of:

20. Processing instructions from one of a plurality of software execution environments; processing issued memory transactions in response to said instructions; A method comprising: In response to a memory transaction that specifies a selected partition identifier depending on which software execution environment issued the memory transaction, a memory system component controls allocation of resources to process the memory transaction or manages contention for the resources depending on a selected set of one or more memory system component resource control parameters, the selected set being selected from among a plurality of sets of one or more memory system component resource control parameters depending on the partition identifier specified by the memory transaction; based on at least one resource control parameter constraint stored in the programmable constraint storage circuit; updating target memory system component resource control parameters; using the target memory system component resource control parameters to control the allocation of resources or to manage contention for the resources; The method of claim 1, further comprising:

Images