Constraints on control parameters for updating or using memory system component resources

Abstract

A partition identifier can be used to mark a memory transaction, selected based on which software execution environment caused the memory transaction to be issued. A memory system component can control resource allocation for processing the memory transaction or manage contention for the resources based on a selected set of memory system component parameters chosen according to the partition identifier specified by the memory transaction. A programmable constraint memory circuit stores at least one resource control parameter constraint used to constrain the updating or use of memory system component resource control parameters.

Description

Background Technology Technical Field

[0002] This technology relates to the field of data processing. Technical Background

[0004] Two or more software execution environments (such as applications or virtual machines) can run on the same data processing system through access to a shared memory system. For some systems, a significant issue is that the performance of one software execution environment cannot be maintained due to another software execution environment consuming excessive resources in the shared memory system. This problem can be referred to as the "noisy neighbor" problem and can be particularly pronounced in, for example, enterprise networks or server systems. Summary of the Invention

[0005] At least some examples provide an apparatus comprising: processing circuitry for processing instructions from one of a plurality of software execution environments; and a memory system component for processing memory transactions issued by the processing circuitry in response to the instructions; wherein: in response to a memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the memory system component is configured to: control resource allocation or management of contention for the processing of the memory transaction based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; the memory system component includes programmable constraint storage circuitry to store at least one resource control parameter constraint; and based on the at least one resource control parameter constraint stored in the programmable constraint storage circuitry, the memory system component 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 resource allocation or management of contention for the resource.

[0006] 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; wherein: in response to the memory transaction issued by the means for processing specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the means for processing the memory transaction is configured to: control resource allocation or management of contention for the resource for processing the memory transaction based on a selected set of one or more memory system component resource control parameters, the selected set being selected from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; the means for processing the memory transaction includes 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 resource allocation or management of contention for the resource.

[0007] At least some examples provide a method comprising: processing instructions from one of a plurality of software execution environments; and processing a memory transaction issued in response to the instructions; wherein: in response to the memory transaction specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, a memory system component controls resource allocation or management of contention for the resource for processing the memory transaction based on a selected set of one or more memory system component resource control parameters, the selected set being selected from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; and constraining at least one of the following based on at least one resource control parameter constraint stored in a programmable constraint memory circuit: updating a target memory system component resource control parameter; and using the target memory system component resource control parameter to control the resource allocation or management of contention for the resource.

[0008] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings. Attached Figure Description

[0009] Figure 1 An example of a data processing system including a memory system is illustrated schematically;

[0010] Figure 2 An example of partition control of memory system resources based on partition identifiers assigned to the software execution environment associated with memory transactions is illustrated.

[0011] Figure 3 An example of processing circuitry for issuing a memory transaction with a specified partition identifier is shown schematically.

[0012] Figure 4 Examples of different software execution environments executed by processing circuitry are shown;

[0013] Figure 5 An example of assigning partition identifiers to different software execution environments is shown;

[0014] Figure 6 An example is shown 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;

[0015] Figure 7 A programming interface for updating memory system component resource control parameters is shown;

[0016] Figure 8 This is a flowchart illustrating a method for responding to memory transactions at a memory system component;

[0017] Figure 9 An example of a cache is shown, which controls the allocation of cache resources and / or updates of performance monitoring data selected based on the partition identifier.

[0018] Figure 10 This is a flowchart illustrating a method for controlling cache allocation based on a capacity threshold selected according to a partition identifier;

[0019] Figure 11 An example is shown where data can be allocated to which parts of the cache are controlled based on the partition identifier;

[0020] Figure 12 An example of a memory system component is shown, having a programmable constraint storage circuit for storing at least one resource control parameter constraint;

[0021] Figure 13 This is a flowchart illustrating a method for programming resource control parameter constraints;

[0022] Figure 14 This is a flowchart illustrating a method for controlling the updating of resource control parameters of memory system components based on resource control parameter constraints;

[0023] Figure 15 An example of resource control parameter update constraints based on partial resource allocation control parameters is shown;

[0024] Figure 16 An example of a resource control parameter update constraint for a fraction-based capacity threshold setting is shown, provided as an example of a resource control parameter for a memory system component.

[0025] Figure 17 An example of applying constraints to minimum and maximum bandwidth thresholds is shown;

[0026] Figure 18 This is a flowchart illustrating the method of applying resource control parameter constraints when using resource control parameters to control resource allocation or contention management for memory transactions; and

[0027] Figure 19 An example of an identifier specified by a storage transaction is shown, which can be used to determine whether the transaction will be subject to resource control parameters. Detailed Implementation

[0028] An apparatus may include processing circuitry for processing instructions from one of multiple software execution environments, and a memory system component for processing memory transactions issued by the processing circuitry in response to the instructions. Memory transactions may be assigned to a partition identifier selected based on which software execution environment caused the memory transaction. The memory system component may use the partition identifier to control resource allocation or manage contention for resources based on a set of memory system component parameters selected using the partition identifier. Additionally, the partition identifier may be used to control whether performance monitoring data is updated in response to a memory transaction.

[0029] Therefore, this processing circuit can present the partition identifier as a label for the memory transaction based on the software that issues the memory transaction. This means that resources in the memory system can be allocated among software execution environments to prevent one software execution environment from acquiring more resources than its reasonable share, thereby solving the aforementioned "noisy neighbor" problem.

[0030] However, it is possible that more than one software execution environment exists, which is allowed to control the setting of a corresponding set of memory system component parameters used by the memory system components to control resource allocation or manage contention for resources for corresponding partition identifiers. Therefore, while one software execution environment can set a corresponding set of memory system component parameters to allow a software execution environment associated with one partition identifier to have a larger share of resources than one associated with another partition identifier, this may be ineffective if another controlling software execution environment can subsequently update the memory system component parameters to provide a different share of resources. This could affect the operation of the software execution environment that is expected to be allocated a larger share of resources.

[0031] For example, in one use case, a first control software execution environment might program memory system component parameters to allocate a dedicated portion of a resource for use by a real-time process, a dedicated portion of which should not be used by other processes. This helps provide a guarantee of the maximum time expected for certain operations performed by the real-time process. However, if a second control software execution environment subsequently changes the memory system component parameters to allow other non-real-time processes to access the dedicated resource, this could violate the dedicated use expected by the real-time software execution environment, potentially making it more difficult for real-time processing to meet its time-to-time guarantees. A similar problem arises between secure and insecure software that programs control settings, where any resource allocation used to enforce secure access to data from the secure software is only affected if another process is able to rewrite the memory system component parameters to allow insecure software to access resources expected to be allocated for the secure software.

[0032] In the techniques discussed below, the memory system component (MSC) is provided with a programmable constraint storage circuit for storing at least one resource control parameter constraint, which can be used to constrain the updating or use of resource control parameters of a target memory system component. Therefore, the resource control parameter constraint provides a way to impose certain limits on: (i) allowing updates to resource control parameters maintained for a given MSC, and / or (ii) valid values ​​of resource control parameters used to control resource allocation or manage contention for resources when processing memory transactions. This addresses the problems discussed above and provides the guarantee that once a specific set of resource control parameters has been established, another control software execution environment cannot change those parameters outside the limits specified in the programmable constraint storage circuit (or if parameters are changed beyond the limits, these updated parameters will not be observed during use), thus ensuring compliance with the previously set resource control parameters.

[0033] Before discussing the use of such resource control parameter constraints in more detail, a general architecture for setting partition identifiers for the software execution environment and using these partition identifiers to control resource allocation or management and / or performance monitoring in the memory system is first described. After describing the general architecture, the characteristics of controlling the updating or use of resource control parameters of memory system components based on resource control parameter constraints will be discussed in a section titled "Resource Control Parameter Constraints".

[0034] A general architecture for memory resource and performance monitoring partitioning

[0035] Figure 1An example of a data processing system 2 comprising N processing clusters 4 (N being 1 or more) is schematically shown, wherein each processing cluster includes one or more processing units 6, such as CPUs (Central Processing Units) or GPUs (Graphics Processing Units). Each processing unit 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 should be understood that this is only one example of a possible cache hierarchy, and other cache arrangements may be used. The processing units 6 within the same cluster are coupled by a cluster interconnect 14. This cluster interconnect may have a cluster cache 16 for caching data accessible by any processing unit.

[0036] The System-on-Chip (SoC) interconnect 18 is coupled to the N clusters and any other master device 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 by any host connected to it. The SoC interconnect 18 controls the consistency between the respective caches 8, 10, 12, 16, and 20 according to any known consistency protocol. The SoC interconnect is also coupled to one or more memory controllers 24, each controlling access to a corresponding memory 25 (such as DRAM or SRAM). The SoC interconnect 18 can also route transactions to other slave devices, such as cryptographic units for providing encryption / decryption functionality.

[0037] Therefore, the data processing system 2 includes a memory system for storing data and providing access to the data in response to transactions initiated by the processing unit 6 and other master devices 22. Caches 8, 10, 12, 16, and 20, interconnects 14 and 18, the memory controller 24, and the memory device 25 can each be considered as components of this memory system. Other examples of memory system components may include a memory management unit or translation buffer (within the processing unit 6 itself or further down within the system interconnect 18 or another part of the memory system) for translating memory addresses for accessing memory, and thus may also be considered part of the memory system. Typically, memory system components may include any components of the data processing system used to service memory transactions to access memory data or to control the processing of those memory transactions.

[0038] The memory system may have various resources for processing memory transactions. For example, caches 8, 10, 12, 16, and 20 may have storage capacity available for caching the data required by a given software execution environment executed on one of the processors 6, to provide faster access to data or instructions than if they had to be retrieved from main memory 25. Similarly, the MMU / TLB may have capacity available for cache address translation data. Furthermore, interconnects 14 and 18, the memory controller 24, and the memory device 25 may each have a certain amount of bandwidth available for processing memory transactions.

[0039] When multiple software execution environments (QEs) running on processing element 6 share access to the memory system, it may be desirable to prevent one QE from using more resources than its fair share, thereby preventing other QEs from experiencing a performance penalty. This can be particularly important for data center (server) applications, where there is a need to improve data center server utilization by increasing the number of independent software processes interacting with a given amount of memory capacity to reduce the increase in capital expenditure. However, tail latency targets for web applications still need to be met, and it is undesirable if a process running on the server monopolizes memory system resources to a degree that is detrimental to other processes. Similarly, for networking applications, it is increasingly common to combine multiple functions that were previously on separate SoCs onto a single SoC. This again leads to the desire to limit the performance interactions between QEs, and to monitor how these QEs need to allow those independent processes access to shared memory while limiting performance interactions.

[0040] Figure 2 This illustration schematically demonstrates an example of dividing control over the allocation of memory system resources based on the software execution environment that issues the corresponding memory transaction. In this context, the software execution environment can be any process or part of a process executed by a processing unit within a data processing system. For example, a software execution environment can 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 a sub-part of any of these types of processes (e.g., a single virtual machine can have different parts that are considered separate software execution environments). Figure 2 As shown, a partition identifier 30 can be assigned to each software execution environment, and the partition identifier, along with the memory transactions associated with the software execution environment, is transmitted to the memory system component.

[0041] Within a memory system component, resource allocation or contention resolution operations can be controlled based on one of several memory system component parameter groups selected according to a partition identifier. For example, ... Figure 2As shown, each software execution environment can be assigned an allocation threshold, which represents the maximum amount of cache capacity that can be allocated for the data / instructions associated with that software execution environment. The relevant allocation threshold is selected based on the partition identifier associated with a given transaction when servicing that transaction. For example, in Figure 2 In this context, a transaction associated with partition identifier 0 can allocate up to 50% of the cache's storage capacity, leaving at least 50% of the cache available for other purposes.

[0042] Similarly, in a memory system component (such as memory controller 24) with a limited amount of bandwidth available for servicing memory transactions, minimum and / or maximum bandwidth thresholds can be specified for each partition identifier. If, within a given time period, a memory transaction specifying a given partition identifier has already used less than the minimum bandwidth, the memory transaction associated with that partition identifier can be prioritized; if the maximum bandwidth or more has already been used for a memory transaction specifying the same partition identifier, a lower priority can be applied to that transaction.

[0043] These control mechanisms will be discussed in more detail below. It should be understood that these are merely two examples of ways to partition memory system resources based on the software execution environment that issues the corresponding transaction. Generally, by allowing different processes to “see” different partitions of the resources provided by the memory system, this allows for limiting performance interactions between processes to help address the problems discussed above.

[0044] Similarly, partition identifiers associated with memory transactions can be used for partition performance monitoring within a memory system. This allows for the tracking of separate sets of performance monitoring data for each partition identifier, enabling the identification of information specific to a given software execution environment (or group of software execution environments). This makes it easier to identify sources of potential performance interactions than when performance monitoring data is recorded for all software execution environments as a whole. This can also aid in diagnosing potential performance interaction effects and in identifying possible solutions.

[0045] The following describes the architecture for setting control partition identifiers, marking memory transactions based on partition identifiers for the corresponding software execution environment, routing partition identifiers through the memory system, and providing partition-based control at memory system components within the memory system. This architecture can be extended to a wide range of uses of partition identifiers. The use of partition identifiers is designed to override them without changing the existing architectural semantics of the memory system, and therefore any required addressing, consistency, and ordering of memory transactions imposed by the specific memory protocols used by the memory system will not be affected by resource / performance monitoring partitioning. When using partition identifiers to control resource allocation, although this may affect the performance achieved when servicing memory transactions for a given software execution environment, it does not affect the results of architecturally efficient computations. That is, partition identifiers do not change the effect or result of a memory transaction (e.g., what data is accessed), but only affect the timing or performance implemented for that memory transaction.

[0046] Figure 3 An example of processing unit 6 is shown in more detail. The processor includes a processing pipeline comprising multiple pipeline stages, including: a fetch stage 40 for fetching instructions from instruction cache 10; a decode stage 42 for decoding the fetched instructions; a dispatch stage 44 including a dispatch queue 46 for queuing instructions while waiting for their operands to become available, and issuing instructions for execution when operands become available; an execution stage 48 including multiple execution units 50 for executing different types of instructions to perform corresponding processing operations; and a write-back stage 52 for writing the results of processing operations to data register 54. Source operands for data processing operations can be read from register 54 by execution stage 48. In this example, execution stage 48 includes an ALU (Arithmetic / Logic Unit) 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 that load data from the memory system into register 54 or store data from register 54 into the memory system. It should be understood that these are merely some examples of possible execution units, and other types may be provided. Similarly, other examples may have different pipeline-level configurations. For example, in an out-of-order processor, an additional register renaming level could be provided to remap the architecture register qualifiers specified by instructions to the physical register qualifiers that identify register 54 provided in the hardware, and a reordering buffer could be provided to track the execution and commit of instructions executed in a different order than that fetched from cache 10. Similarly, it is still possible to provide... Figure 1 Other mechanisms, not shown, could include providing branch prediction functionality at the fetch level to control the generation of the next fetch address 61 based on the prediction results of the branch instruction.

[0047] Processor 6 has multiple control registers 60, including, for example: a program counter register 62, which stores a program counter indicating the current execution point of the program being executed; an exception level register 64, which stores an indication of the current exception level at which the processor is executing instructions; a security status register 66, which stores an indication of whether the processor is in a non-safe or safe state; and a memory partitioning and monitoring (MPAM) control register 68 (discussed in more detail below), which controls memory system resources and performance monitoring partitioning. It should be understood that other types of control registers may also be provided. The program counter register 62... Figure 3 The register is shown as being maintained by the acquisition level 40, but it can also be accessed by other levels, such as the execution level 48.

[0048] The processor has a memory management unit (MMU) 70, which controls 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. This 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 lookup buffers (TLBs) 72, 73, and 74. The TLBs may include a data TLB 74 used for data access initiated by the load / store unit 50, an instruction TLB 73 used for instruction fetch access initiated by fetch level 40, and a master TLB 72 used for both instruction and data access in a shared level 2 TLB, accessed on a miss basis in level 1 TLBs 73 and 74. Each of TLBs 72 to 74 stores multiple TLB entries. Each TLB entry identifies not only mapping data that identifies how an address is translated, but also associated access permission data that defines whether the processor is allowed to read or write an address in the corresponding page of the address space. In some examples, multiple address translation levels can exist, and therefore multiple TLBs can exist. For example, a Level 1 TLB provides a first translation level for mapping virtual addresses generated by load / store unit 50 to intermediate physical addresses, and a Level 2 TLB provides a second translation level for mapping intermediate physical addresses to physical addresses used by the memory system to identify the data to be accessed. The mapping data for the Level 1 TLB can be set under the control of the operating system, while the mapping data for the Level 2 TLB can be set under the control of the hypervisor, for example, to support virtualization. It should be understood that... Figure 3 The TLB arrangement shown is just an example, and other specific implementations may have different TLB groups.

[0049] In addition to TLBs 72, 73, and 74, the MMU may also include other types of caches, such as a page walk cache 75, which caches data used to load mapping data into the TLBs during page table walks. The memory system can store page tables containing address mapping data for each page in a specified virtual memory address space. TLBs 72, 73, and 74 can cache subsets of these page table entries for multiple recently accessed pages. If the processor issues a memory transaction to a page that does not have corresponding address mapping data stored in TLBs 72, 73, and 74, the page table walk unit 76 initiates a page table walk. This can be relatively slow because it may be necessary to traverse multiple levels of page tables in memory to identify the address mapping entry for the required page. To speed up page table walks, the most recently accessed page table entries can be placed in the page walk cache 75. These entries are typically page table entries other than the final-level page table entries, which actually specify the mapping for the required page. These higher-level page table entries typically specify where other page table entries for the corresponding address range can be found in memory. By caching at least some levels of the page tables traversed in previous page table walks in page walk cache 75, page table walks to other addresses that share the same initial portion of a page table walk can be performed faster. Alternatively, page walk cache 75 does not cache the page table entries themselves, but can cache the addresses of those page table entries that can be found in memory, thus allowing access to a given page table entry to be performed even faster than having to first access other page table entries in memory to identify those addresses.

[0050] Figure 4 Examples of different software execution environments that can be executed by processor 6 are shown. In this example, the architecture supports four different exception levels EL0 to EL3, which are sequentially elevated in privilege levels (such that EL3 has the highest privilege exception level, and EL0 has the lowest privilege exception level). Generally, higher privilege levels have greater privileges than lower privilege levels and therefore can access at least some data that is not available at lower privilege levels and / or perform some processing operations that are not available at lower privilege levels. Application 80 executes at the lowest privilege level EL0. Many guest operating systems 82 execute at privilege level EL1, where each guest operating system 82 manages one or more applications among application 80 at EL0. The virtual machine monitor (also known as the hypervisor or host operating system) 84 executes at exception level EL2 and manages the virtualization of the corresponding guest operating system 82. Some applications at EL0 can be directly managed by the host operating system at EL2 without the intermediate operating system at EL1.

[0051] A transition from a lower exception level to a higher exception level may be caused by an exceptional event (e.g., an event handled by the hypervisor or host operating system may cause a transition to EL2), while a transition back to a lower level may be caused by returning from handling an exceptional event. Some types of exceptional events can be served at the same exception level as the level at which they were acquired, while others may trigger a transition to a higher exception state. The current exception level register 64 indicates which level of exception level EL0 to EL3 the processing circuitry 6 is currently executing code at.

[0052] In this example, the system also supports a partition between a secure domain 90 and a normal (less secure) domain 92. Sensitivity data or instructions can be protected by assigning them to memory addresses marked as accessible only by the secure domain 90, where the processor has hardware mechanisms to ensure that a process executing in the less secure domain 92 cannot access that data or instructions. For example, access permissions set in the MMU 70 can control the partition between secure and non-secure domains, or alternatively, a completely separate secure memory management unit can be used to control the security state partitioning, where separate secure and non-secure MMUs 70 are provided for sub-control within the respective security states. The transition between the secure domain 90 and the normal domain 92 can be managed by a security monitor process 94 executing at the highest privilege level EL3. This allows for tight control over the transition between domains to prevent application 80 or guest operating system 82 from accessing data from the secure domain, for example. In other examples, hardware techniques can be used to perform separation between secure state and polling transitions, allowing code in the normal domain 92 to be directly transferred to code in the secure domain 90 without transitioning via a separate security monitor process 94. However, for ease of explanation, the following description will refer to an example that does indeed use a security monitor process 94 at EL3. Within security domain 90, the secure world operating system 96 executes at exception level EL1, and one or more trusted applications 98 can execute at exception level EL0 under the control of the secure world operating system 96. In this example, there is no exception level EL2 in security domain 90 because virtualization is not supported in this security domain, but virtualization can still be provided if needed. An example of an architecture used to support such a security domain 90 could be Arm from Cambridge, UK. ® TrustZone provided by Limited ® Architecture. However, it should be understood that other techniques may also be used. Some examples may have more than two security states, providing three or more states with different levels of security associated with them. The security state register 66 indicates whether the current domain is secure domain 90 or non-secure domain 92, and this instructs the MMU 70 or other control units on which access permissions are used to control whether certain data can be accessed or permitted operations.

[0053] therefore, Figure 4 Several different software execution environments that can execute on the system are illustrated, such as application 80, guest operating system 82, host operating system 84, security monitor process 94, secure world operating system 96, and trusted application 98. Each of these software execution environments can be assigned a given partition identifier (partition ID or PARTID), or a group of two or more software execution environments can be assigned a common partition ID. In some cases, a separate part of a single process (e.g., a different function or subroutine) can be considered a separate execution environment and assigned a separate partition ID. For example, Figure 5 An example is shown where virtual machine VM 3 and the two applications 3741 and 3974 running under it are all assigned PARTID 1, a specific process 3972 running under a second virtual machine VM 7 is assigned PARTID 2, and VM 7 itself and another process 1473 running under it are assigned PARTID 0. Custom partition IDs do not need to be assigned to each software execution environment. A default partition ID can be specified for software execution environments that are not assigned partition IDs. Control over which portions of the partition ID space are assigned to each software execution environment is exercised by software with a higher privilege level, such as a hypervisor running in EL2 controlling the allocation of partitions to the virtual machine operating system running in EL1. However, in some cases, the hypervisor may allow the operating system with a lower privilege level to set its own partition IDs for portions of its own code or for applications running under it. Furthermore, in some examples, secure world 90 may have a partition ID space completely separate from normal world 92, controlled by the secure world OS or the monitoring program EL3.

[0054] like Figure 3As shown, the CPU may include MPAM generation logic 77 for generating MPAM-related information to be associated with a given memory access transaction. The MPAM-related information may include at least a PARTID, but in some examples may also include other information (e.g., a performance monitoring group ID used to select which set of performance monitoring parameters the memory system component should 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 in the MPAM control register 68 to determine which register should be used to generate the MPAM-related information; and partition ID virtualization logic 79 for controlling the mapping of virtual partition IDs to physical partition IDs based on information in the MPAM control register 68, which is used by the memory system component to select resource control settings. MPAM generation logic 77 generates multiple alternative MPAM-related parameters, including instruction MPAM-related parameters (I-MPAM) for instruction fetch access, data MPAM-related parameters (D-MPAM) for data access, instruction page table walk MPAM-related parameters (I-PTW-MPAM) for page table walk access triggered by instruction fetch, and data page table walk MPAM-related parameters (D-PTW-MPAM) for data page table walk MPAM. Providing separate MPAM-related parameters (I-PTW-MPAM and D-PTW-MPAM) for page table walk memory access can be useful, allowing page table walk memory accesses to control their resource usage based on memory system component parameters defined for the process managing the page tables, rather than the currently executing process.

[0055] It should be understood that the precise mechanisms used to determine which partition identifier to assign to a given memory request based on the software execution environment associated with the request can vary considerably, and any such mechanism can be used at the processing element (CPU). From the perspective of memory system components such as caches, interconnects, or memory controllers, how the partition identifier specified in a given memory request is selected at the CPU is not important.

[0056] The partition ID and performance monitoring group (and in some implementations, a security status indicator specifying the security status from which the transaction originated) attached to a given memory transaction flow throughout the memory system with the memory transaction. Thus, nodes (e.g., interconnects) that pass memory transactions to other parts of the memory system provide the outgoing memory transaction with the same partition ID, performance monitoring group, and security status indicator as the corresponding request received at such nodes. For caches within the memory system, these nodes sometimes generate a response to a request if a cache hit occurs, and at other times, if a cache miss occurs, these nodes pass the request to another part of the memory system. They may also sometimes allocate new entries based on requests. When allocating a new entry, the cache may store the partition ID, performance monitoring group, and security indicator that caused the allocation along with the cached data itself. When data is written back to another cache or memory, a write-back transaction is generated that specifies the partition ID, performance monitoring group, and security indicator associated with the evicted data in the cache, rather than the ID associated with the request that triggered the evictation. This allows for resource allocation or performance monitoring of write-backs to be controlled / monitored based on parameters specific to the software execution environment that allocates the corresponding data to the cache.

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

[0058] Performance monitors operate differently from resource partitioning control. Performance monitors measure, count, or compute performance metrics based on filters programmed into the monitor. Filter parameters can include partition IDs and performance monitoring groups (or performance monitoring groups, but not including partition IDs). For example, a performance monitor that counts bytes transferred to memory can filter measurements to count only reads with a partition ID of 5 and a performance monitoring group of 2. Therefore, performance measurements can be collected for different software execution environments or different groups of software execution environments that share the same partition ID and performance monitoring group.

[0059] 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. Memory system component parameters can be resource control parameters used to control the allocation of memory system resources (such as bandwidth, cache capacity, etc.) or competition for these resources (for example, the selected memory system component parameters can be a set of transaction definition priorities associated with the corresponding partition ID).

[0060] Figure 6 An example is shown of using memory system component parameters selected based on partition ID (PARTID) to control resource partitioning. Memory system component 100 includes a regulator 102 for controlling access to controlled resources 104 (e.g., cache capacity, bandwidth). Memory system component 100 has a configuration table 106 that provides multiple entries, each corresponding to a given partition ID. Configuration table 106 is indexed based on the PARTID specified in a received memory access request. Although Figure 6 A settings table is shown, but other examples of controlling more than one form of resource control may have a settings table 106 for resource control in each implementation. Each entry in the settings table specifies one or more partition control settings (memory system component resource control parameters) 108 for the corresponding PARTID. These settings may, for example, specify how much cache (or how much memory bus bandwidth) is available for a request associated with the corresponding PARTID. Some forms of control (e.g., maximum cache occupancy based on a given PARTID) may depend on resource usage measurements performed by measurement circuitry 110 (e.g., a count of how many cache entries have been allocated for a given PARTID). Other forms of control may not require measurement circuitry 110 (e.g., for part-based cache control mechanisms described further below, no measurement is required). Therefore, based on the limitations on resource usage for a given PARTID as defined in settings table 106, regulator 102 controls how request processing function 112 processes incoming requests to avoid allocating more than its reasonable share of the controlled resources 104 to a particular software process for a given PARTID.

[0061] If the memory system component is cache 8, 10, 16, or 20, then the controlled resource 104 can be the cache storage capacity. Based on a set of memory system component resource control parameters 108 selected from the configuration table of the relevant PARTID, the regulator 102 can control the allocation of data to the cache in response to memory transactions. If the memory system component is interconnect 14, 18, or memory controller 24, then the regulator 102 can control the allocation of bandwidth or buffer usage for processing memory transactions based on a set of memory system component resource control parameters 108 selected from the configuration table of the relevant PARTID.

[0062] Figure 7 A programming interface 120 for updating control settings in one or more setting tables 106 is shown. In this example, there are two separate setting tables 106-A and 106-B for controlling corresponding regulators 102-A, 102-B to control access to controlled resources 104-A, 104-B of corresponding types. The programming interface 120 includes a PARTID selector 130 and multiple setting interface registers 132-A, 132-B. To set or read a control setting for a given PARTID, the register within the PARTID selector 130 is first written with the given PARTID, and then a read or write operation is performed on 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, while 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 setting table 106 for writing or reading based on the PARTID specified in its PARTID selection register.

[0063] The registers of programming interface 120 are memory-mapped registers, accessed by CPU 6 issuing load / store operations that specify the memory address mapped to the corresponding register to be read / written as its destination address. Therefore, PARTID selector 130 connects a common set of interface registers 132 to the relevant rows of setup table 106, thus avoiding the need for separate interface registers for each individual PARTID. PARTID selector 130 effectively moves up and down in the table to access the "keyholes" of setup table 106 to select the entry to read or write.

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

[0065] Figure 8A method for controlling the operation of a memory system component based on a partition ID is illustrated. At step 200, the memory system component receives a memory transaction specifying a partition ID, a performance monitoring group (PMG), and a security status 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 status. The performance monitoring group is not considered in this step. At step 206, the selected set of resource control parameters is used to control resource allocation, or to manage contention for these resources. If memory system resource partitioning is not supported, steps 204 and 206 are omitted.

[0066] If the memory system component supports performance monitoring grouping for performance monitoring partitioning (step 208), then at step 210, each performance monitor implemented in that component tests the request against its filter parameters (which may include tests to be applied to the PMG and partition ID). Each monitor that meets its filter parameters updates its internal state based on the measurements, counts, or calculations the monitor is designed to perform. For memory system components that do not support performance monitoring partitioning, step 210 is omitted. In some embodiments, both the partition ID field and the PMG field may be included in the filter parameters (such that the PMG field further restricts the partition ID field). Alternatively, the PMG may be interpreted as a separate ID from the partition ID field, in which case the filter parameters may consider the PMG but not the partition ID.

[0067] Each memory system component supporting resource monitoring partitioning can have a set of parameter registers that store different memory system component parameter groups selected based on partition IDs. The control parameters used for partitioning control are logically a series of control parameters indexed by partition ID. The interface for setting the control parameters can be arranged as a series of memory-mapped registers, or it can be arranged with selector registers, with each control parameter having only a single configuration register. In the latter case, the configuration software first stores the partition ID to be configured in the selector register, and then stores the desired control parameters in one or more control parameter configuration registers.

[0068] Figure 9 An example of cache 300 as an example of a memory system component is shown. Cache 300 can be a cache for caching instructions or data, such as a Level 1 data cache 8, a Level 1 instruction cache 10, or a Level 2 cache 12, a cluster cache 16, or a system cache 20 for a given processing element 6. Cache 300 can also be a cache for address translation, such as a TLB 72 or a page-walk cache 74 in the MMU 70. Although Figure 3 An example of providing the MMU 70 within a given processor core is shown, but the system MMU can also be provided further down the memory system, for example, within the SoC interconnect 18.

[0069] Cache 300 has a cache memory device (cache RAM) 302 for storing information to be cached. Cache RAM 302 has a number of storage entries 304. For example... Figure 9 As shown, each entry can store:

[0070] Cache data 306 (This can be any cached information, including not only data values ​​but also instruction or address translation data, depending on the type of cache).

[0071] The valid bit 308 specifies whether the corresponding data in the entry is valid.

[0072] Tag field 310 indicates a portion of the address associated with cached data.

[0073] Partition ID 314 for the memory transaction that allocates data to the cache.

[0074] Performance monitoring group ID 316 for memory allocation transactions

[0075] The security state indicator ID 318 for allocating memory transactions (it indicates from which security state the memory transaction originated);

[0076] System design may require additional information to be maintained for each cache line, such as consistency status or address space indicator (ASI).

[0077] When evicting data from the cache, fields 314, 316, and 318 are used to derive the partition ID, performance monitoring group ID, and security status indication used for the write-back transaction. Although in Figure 9 Not shown, but each cache entry may also store consistency information that specifies the consistency state of cached data (e.g., whether the data is clean or dirty to determine whether it needs to be written back) and / or sacrifice selection data for selecting sacrificed cache lines when eviction is required (e.g., for tracking which entries have been least recently used).

[0078] Data allocation to the cache can be controlled based on any known cache organization, including direct mapping, set-associative, or fully associative. Figure 9 The example illustrates a group-associative organization scheme with four approaches, but it should be understood that this is only an example. Cache lookups are performed independently of the partition ID associated with the corresponding memory transaction. Therefore, when a memory transaction specifying a given partition ID is received, the transaction can hit any data within an indexed cache entry, regardless of the partition ID 314, security status indicator ID 318, and performance monitoring group ID 316 stored in the cache entry. Therefore, the partitioning of performance resources and / or performance monitoring does not prevent different software processes from sharing access to cache data.

[0079] On the other hand, when data is allocated to the cache, the cache controller 312 controls the allocation based on a set of resource control parameters selected according to the security state and the partition ID of the corresponding memory transaction. The cache has a set of resource control parameter registers 320 (examples from the setup table 106 above), each register 320 storing resource control parameters for the corresponding software execution environment. The selector 322 selects a register based on the partition ID and the security state of the incoming memory transaction for which data needs to be allocated to the cache. The parameters stored in the selected register control whether and how data is allocated to the cache.

[0080] In the first cache partition control mode, a maximum capacity threshold is used to control allocation. This threshold is selected using the partition ID and identifies the maximum number of entries of data associated with the corresponding partition ID that can be allocated within the cache capacity. In specific implementations supporting both secure and insecure states, this threshold can define the maximum capacity of data that can be allocated with a given combination of partition ID and insecure ID indicators. For example, the maximum capacity threshold can be set by a higher-privilege process; that is, the threshold for a given operating system can be set by the hypervisor, and the threshold for a given application can be set by the operating system.

[0081] For example, Figure 2 Examples are shown where 50%, 50%, and 40% of the maximum capacity thresholds are allocated to partition IDs 0, 1, and 2, respectively. Note that the sum of the maximum capacity thresholds defined for different software execution environments can exceed 100%, because these thresholds are only maximum limits on the amount of data that the cache can store for a given partition ID, not guaranteed allocations. In this case, the corresponding software execution environments will not use their maximum allocations simultaneously.

[0082] Return to Figure 9The cache 300 has a set of allocation counters 326 that track how many cache entries 304 have been allocated for data associated with each partition ID. These counters can be further subdivided based on security states when security is supported. The allocation counter 326 increments when a data value for a given partition ID is allocated to the cache. The allocation count for the corresponding partition ID decrements when data becomes invalid, is evicted, or replaced. When a cache miss occurs in response to a given memory transaction, the cache controller 312 reads the allocation counter 326 corresponding to the partition ID specified by the memory transaction and the resource control parameter register 320, compares the allocation count to a maximum capacity threshold, and then controls allocation based on the result of the comparison. If the current allocation has not exceeded the threshold, the required data can be allocated to the cache. However, if the allocation count is equal to or exceeds the threshold, the cache controller 312 can either determine not to allocate any data for the new request or evict or replace other data associated with the same partition ID from the cache before allocating new data to prevent the cache allocation from exceeding the threshold level of entries associated with that partition ID. If eviction or replacement is required, the partition ID 314 stored in each entry of the cache (and, if provided, sacrifice selection information) can be used to determine which data to evict. It should be understood that the above method of counting capacity is merely an example, and other techniques can be used to track cache capacity.

[0083] Resource control parameter registers 320 can represent the maximum number of entries indicated by a maximum capacity threshold in different ways. For example, they can directly specify the maximum number of entries that can be allocated to the corresponding partition ID data. Alternatively, they can specify the threshold based on a portion of the total cache capacity that can be allocated to that partition ID. For example, the parameter can represent a scaling percentage, where the width and scaling factor of the parameter are specified in the ID register 362 of the corresponding memory unit. For example, a unit may support 8-bit capacity control scaling at 256. In this case, allocating 30% of the capacity to a given partition would result in a maximum capacity parameter of 0.30 * 256 = 76.8, rounded to 76 to prevent allocation of more than the desired percentage.

[0084] In implementations that support multiple security states, the security state indicator is also used in conjunction with the partition ID to select the appropriate resource control parameter register 320 and allocation counter 326.

[0085] Figure 10A method for controlling cache allocation based on a maximum capacity threshold in a first partition control mode is illustrated. 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, an allocation count maintained by an allocation counter 326 for the corresponding security state and partition ID is compared with 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 it is not greater, then at step 338, in response to the cache miss, the requested data is allocated to the cache. Alternatively, if the allocation is greater than or equal to the allocation threshold, at step 340, data allocation to the cache is prevented, or alternatively, at step 342, data associated with the same partition ID as the current request can be replaced or evicted to make way for newly allocated data, and at step 338, the data can be allocated normally (although steps 340 or 342 provide a limit, the allocation count may sometimes exceed the threshold, for example, if the threshold has been recently updated). The choice between proceeding to step 340 or 342 is an implementation choice for a given specific implementation of the cache.

[0086] Alternative locations, such as Figure 11 As shown, a second cache control mode can be used, where a cache capacity portion bitmap 350 selected based on partition ID is used to control cache allocation. Bitmap 350 has multiple fields 352, each specifying whether a corresponding portion of the cache storage device 302 is allowed to be allocated for storing data associated with the corresponding partition ID. For example, Figure 11 The bitmap 350 shown in the lower part of the example has 32 fields 352, each corresponding to 1 / 32 of the cache capacity. Each field can be set to 0 to indicate that a transaction specifying the corresponding partition ID cannot allocate data to that part of the cache, or set to 1 to indicate that the part is allowed to allocate data for that partition ID.

[0087] like Figure 11 As shown in the top section, by setting different bitmaps 350 for different partition IDs, this allows some parts of the cache to be reserved for a given partition ID, while other parts can be shared between partition IDs or not allocated at all. For example, for Figure 11The four cache portions shown are subsets (not the entire cache capacity). Cache portion 0 is allocated only to partition 1, portion 1 is allocated to both partitions 1 and 2, allowing them to compete for allocation to this portion of the cache, portion 2 is allocated only to partition 2, and portion 3 is not allocated to any of these partitions. Therefore, when allocating data to the cache used for partition 1, the cache controller 312 is restricted to selecting a location within either portion 0 or 1, but not in portions 2 or 3. The “portion” defined by this bitmap can be any group of one or more cache entries, characterized in that any given address can be allocated to at least one entry in that group, for example, the entire path in a set-associative cache (including all sets belonging to that path), or a more arbitrary subset of entries in a fully associative cache.

[0088] Therefore, using the second allocation control mode, when a cache miss is detected, a set of control parameters for the corresponding partition ID and security state are selected. However, at this time, the cache bitmap is read and used to control which parts of the cache can be allocated data.

[0089] Some cache implementations may support only one of the first and second cache allocation control modes described above (e.g., a direct-mapped cache may implement the first mode but not the second). Other implementations may support the option of using both modes. For example, this can be useful because if the particular cache organization being used does not support providing many parts (e.g., a set-associative cache with relatively low associativity), covering the maximum capacity limit provides better control than individual part partitioning.

[0090] As described above, cache 300 may have a memory-mapped configuration register 360 for controlling how resource partitioning is performed. This is an example of the programming interface 120 described above. Configuration register 360 includes 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 be updated, and one or more configuration registers 366 for specifying the parameters to be written to the selected set of resource control parameters.

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

[0092] When setting a set of resource control parameters for a given partition ID, the software writes the partition ID to selector register 364 and the parameters to be written to the corresponding configuration register 366, specifically by issuing a memory transaction specifying the memory addresses mapped to these registers 364 and 366. In response, cache 300 reads the parameters from configuration register 366 and writes them to the corresponding resource control parameter register 320 identified by the relevant partition ID. When a secure state is supported, selector register 364 and configuration register 366 can be backed up, allowing different versions to provide separate options for secure and less secure states, where a security indication associated with the memory transaction selects which set of registers to access.

[0093] Note that the selector register 364 and configuration register 366 used to set resource control parameters are merely one example of how resource control parameters can be set. The advantage of this approach is that it saves address space usage in the memory system components. However, an alternative would use a wider interface, where a series of control settings are displayed as a series of N control setting registers, where N is the maximum number of supported partition IDs. This is simpler because the control configuration can be updated for partitions with a single write, and therefore mutual exclusion is not needed to prevent one processor from accessing selector register 364 and configuration register 366 while another processor configures the memory system components. For example, if the maximum number of partition IDs is 2... 16 Furthermore, since a typical memory system component has 2 to 4 controls, this method can use 256KB of address space for this series of resource control parameters.

[0094] Access to the memory-mapped configuration register 360 can be controlled by the MMU 70, for example, to restrict which operational states can issue memory transactions to update the configuration register 360. For instance, instructions executing in EL0 might not be allowed to access the configuration register 360, but hypervisors in EL2 might be permitted to do so. When partition ID virtualization is supported, the partition ID used within cache 300 is the physical partition ID, while the operating system attempting to set resource control parameters for the corresponding application's partition ID will specify a virtual partition ID. Therefore, to prevent the operating system from updating incorrect resource control parameters, an access to the address mapped to configuration register 360 can be trapped, and an exception can be triggered to switch processing to the hypervisor in EL2. The exception handler in the hypervisor can then issue the corresponding memory transaction with the correct physical partition ID to update the relevant set of parameters 320 at cache 300. To achieve this, during the two-level MMU translation process, the address associated with the memory-mapped register 360 can be placed on a Level 2 address page, different from other address spaces used by memory system components.

[0095] Using a similar approach to resource control partitioning, performance monitoring within cache 300 can be partitioned based on performance monitoring groups (and partition ID in implementations where PMG is a sub-attribute of partition ID) and security status. Multiple performance monitors 380 can be provided, each configured to measure, count, or compute performance metrics based on filters programmed in a set of filter parameters 382 corresponding to the performance monitor 380. Filter parameters 382 can include fields specifying PARTID and PMG, and upon receiving a memory transaction, if filter parameters 382 have already set specific values ​​for the PARTID / PMG fields, the performance monitor can determine whether to update its metrics based on whether the PARTID / PMG value associated with the transaction matches a matching value in filter parameters 382. Note that in specific implementations supporting the first cache allocation mode, the same allocation counter 326 can also be used for performance monitoring, provided that an allocation counter 326 is provided to track whether an allocation threshold has been exceeded.

[0096] In the case where cache 300 is an address translation cache (such as a TLB or page walk cache), allocating cache resources in this way can be useful to ensure that a software execution environment cannot allocate more than a percentage / part of the address translation cache capacity allocated to it, thereby leaving room for other software execution environments and reducing the "noisy neighbor" effect.

[0097] Although Figure 9An example of cache 300 is shown, but other memory system components may have a similar set of memory mapping configuration registers 360 for configuring memory system component parameters associated with a given partition ID / performance monitoring group / security status, and resource control parameter registers 320 for specifying configuration data groups for the corresponding partition ID.

[0098] Specifically, for other memory system components (such as memory controller 24 or interconnects 14, 18), any of the following forms of resource partitioning can be implemented:

[0099] Memory channel bandwidth allocation

[0100] The bandwidth of the main memory channel can be allocated. Two bandwidth control schemes can be provided. The memory channel can optionally implement one or both of the following:

[0101] The minimum bandwidth required for partitioning, even in the presence of contention.

[0102] Maximum bandwidth limit available to a partition when contention exists

[0103] Any combination of these control schemes can be used simultaneously on the channels supporting them. Each control scheme is described in the section below.

[0104] Minimum bandwidth control scheme

[0105] When a partition's current bandwidth is below its minimum, the minimum bandwidth control scheme prioritizes requests from that partition, and when it is above its minimum bandwidth, its requests are allowed to compete with other normal requests. Therefore, requests from partitions below their minimum bandwidth are most likely to be scheduled on the channel. The minimum bandwidth control scheme tracks memory bandwidth during counting.

[0106] If the bandwidth of a partition being tracked during a counting period is currently less than the minimum value for that partition, then its request to use the channel bandwidth is prioritized.

[0107] If the bandwidth of a partition being tracked during the counting period is currently greater than the minimum value for that partition, its request will compete with other normal priority requests for bandwidth on the channel.

[0108] Bandwidth not used by a partition during the counting window is not accumulated. Registers within the memory system component can specify a minimum bandwidth limit for a given partition ID as megabytes per second (MB / s). The MB / s scaling value is calculated as the required megabytes per second multiplied by a hardware-defined scaling factor.

[0109] Maximum bandwidth limiting control scheme

[0110] The maximum bandwidth limit control scheme provides normal priority to partitions that reach at most their maximum bandwidth limit during the counting period. If the bandwidth usage of a partition being tracked during the counting period is currently less than the maximum value for that partition, its request competes for scheduling on the memory channel with normal priority. If the bandwidth usage of a partition being tracked during the counting period is currently greater than the maximum bandwidth limit for that partition, its request competes with other less preferred requests for bandwidth on the channel.

[0111] When a partition's bandwidth usage is below the maximum bandwidth limit, the maximum bandwidth limit control scheme gives normal priority to requests from that partition, and gives non-priority to requests when bandwidth usage exceeds the maximum bandwidth limit. Therefore, a partition can use more bandwidth than its maximum when there is no contention for channel bandwidth. Bandwidth requests from partitions using bandwidth below their maximum limit are scheduled using normal priority; therefore, not all bandwidth requested by a partition below its maximum limit will be granted by the channel scheduler based on contention. Bandwidth not used by a partition during the counting window is not accumulated.

[0112] Similarly, the control parameter used for maximum bandwidth limiting can be specified as megabytes per second scaling. The megabytes per second scaling value is calculated as the required megabytes per second multiplied by a scaling factor that can be defined by hardware.

[0113] The following table shows the priority of requests when both the minimum bandwidth control scheme and the maximum bandwidth limit control scheme are implemented:

[0114]

[0115] *Note that while priority can typically be defined as “high,” “medium,” or “low” to increase the likelihood of serving a “high” priority request before a “medium” or “low” priority request, implementations can still deviate from the priority order when serving requests to meet other objectives of the implementation, such as avoiding starvation.

[0116] For all the schemes discussed above, the control parameters for the bandwidth partitioning scheme can all be expressed in a given unit, such as megabytes per second. This value is also equal to bytes transmitted per microsecond. An implementation might need to multiply each bandwidth partitioning control parameter by a constant scaling factor and then program the resulting value into a bandwidth control register in the memory system component used for partition IDs. Whether the implementation requires scaling control parameters and scaling factors (if scaling is needed) can be specified in a discovery register within this memory system component (similar to discovery register 362 of the cache mentioned above).

[0117] For all the memory bandwidth partitioning schemes described above, memory channel bandwidth adjustment can occur within a counting cycle. The counting cycle can be fixed or a moving window. The width of this window can be a discoverable constant, which can be read from a discover register in the memory system component. For example, the counting cycle can be at least one microsecond and can be as long as 20 microseconds or more. Longer counting cycles may require more hardware, especially in moving window implementations, while shorter counting cycles may have more boundary effects, especially in fixed window implementations.

[0118] In fixed-window computation, bandwidth is allocated to requests such that each partition receives bandwidth based on its minimum and maximum values. Requests or local priorities are used to resolve requests that conflict over bandwidth. When a counting window period is reached, a new window initially has no history other than any previously unserved request queues. For each partition, the new window begins accumulating bandwidth from zero.

[0119] As the window is moved, the computation maintains a bandwidth history for each partition from all commands issued within the past window width. Instead of resetting the bandwidth calculation for each partition, bandwidth is added as a command is processed and removed from the calculation when the command moves out of the window's history. This continuous computation is relatively free of boundary effects, but requires more hardware to track the command history within the window, in addition to the bandwidth counter for each partition ID required for a fixed window.

[0120] The sum of the minimum bandwidth allocations for all partitions can exceed the available bandwidth. This is not a problem when some partitions do not use their bandwidth allocations, as the unused allocations are available for other partitions. However, when the minimum bandwidth is over-allocated, it is impossible to always meet the minimum bandwidth programmed for a partition. Software can ensure that the minimum bandwidth is not over-allocated to ensure that the system can reliably deliver the programmed minimum bandwidth allocations.

[0121] Because available bandwidth can depend on one or more clock frequencies across many systems, such as the DDR clock, software may want to reallocate bandwidth when the clock that affects available bandwidth is changed. Reducing the clock rate without changing the allocation can lead to over-allocation of bandwidth. Note: Available bandwidth on a DRAM channel is not constant but varies with the clock rate and is a mixture of read and write operations and library hit rates.

[0122] Those skilled in the art will see that this type of bandwidth control is not limited to use only at the memory channel controller, but can be deployed to control bandwidth at any memory system component.

[0123] Priority Division

[0124] Unlike other memory system resources listed in this document, priority does not directly affect the allocation of memory system resources, but rather influences conflicts that occur when accessing resources. A properly configured system should rarely suffer a significant performance impact due to priority, but priority does play a significant role in cases of oversubscription, whether transient or persistent. Therefore, "priority partitioning" can be used as a tool to help isolate memory system impacts between partitions.

[0125] Priorities can be assigned to partitions at each component of the memory system (with priority partitioning supported). This partitioning control allows different parts of the memory system to be configured to handle requests with different priorities. For example, a request from the processor to the system cache can be configured to use a higher transfer priority than a request from the system cache to main memory.

[0126] Two types of priority can be identified for each partition ID:

[0127] Internal priority controls the priorities used in the internal operations of this memory system component. They can be used within the memory system component to prioritize internal operations. For example, when bandwidth allocation does not select an obvious winner, the memory controller can use internal priorities to select among waiting requests.

[0128] Downstream priority controls the priority of transmission to another memory system component (such as an interconnect or memory controller). "Downstream" refers to the direction of communication used to make a request. An "upstream" response typically uses the same transmission priority as the request that generated the response. Memory system components use downstream priorities to indicate priority to downstream components that do not have priority divisions. This can be used to set transmission priorities for downstream interconnect components.

[0129] On the other hand, if a component does not implement priority division, or it does not implement downstream priority, it can use "pass-through priority," where the downstream priority is the same as the incoming (upstream) priority or request. Similarly, the priority of a response transmitted through a memory system component (from downstream to upstream) is the same as the priority of a response received (from downstream).

[0130] Resource control parameter constraints

[0131] The examples above illustrate various memory system component (MSC) resource control parameters that can be used to control resource allocation or manage contention for resources within the MSC. For instance, resource control parameters may include those described above. Figures 9 to 11 The cache examples show threshold-based capacity control or partial control, or may include, for example, Figure 2The examples shown above illustrate minimum or maximum bandwidth control for memory bandwidth allocation, or may include priority-based control. Figure 9 As illustrated in the example, memory access to certain memory-mapped registers of the MSC can be used to update resource control parameters. Memory mappings, defined by page tables (which are used by the MMU 70 to control memory access), specify which software processes are allowed to access memory addresses mapped to configuration registers used to set resource control parameters for a given MSC. For example, one approach could be that, in a particular operating state of the processing circuitry, the resource control parameters of a software process can be accessed by the highest-privilege-level software associated with that operating state. For instance, resource control parameters associated with a security partition identifier can be updated by a highest-privilege-level code (or second-highest-privilege) operating in a security domain such as a hypervisor or operating system. Writing non-secure codes to memory-mapped registers that control updates to resource control parameters associated with a security state may not be permitted. Conversely, highest-privilege (or second-highest-privilege) codes operating in a non-secure domain may be allowed to set resource control parameters associated with a non-secure partition.

[0132] Therefore, by setting resource control parameters associated with the partition identifier of the security software's execution environment, software within a security domain may be able to reserve certain portions of resources (such as a portion of cache capacity) for its exclusive use. For example, security software may be configured as follows: Figure 11 The cache partition bitmap shown is configured to reserve at least a portion of the cache that can be allocated to the secure process, while the partition bitmaps for other processes specify that this portion cannot be allocated to those other processes. Specifically, the security software can set the partition bitmap for non-secure partition IDs to reserve this dedicated portion of the cache that has not been allocated for those other partition IDs.

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

[0134] Similar problems may exist when some real-time software is granted exclusive access to certain resources, but subsequently, by updating the memory system component resource control parameters used for those other partition IDs to allocate access to reserved portions for partition identifiers associated with other processes, it may make it difficult for the real-time software to meet its service guarantees.

[0135] In the following example, the Memory System Component (MSC) is provided with a programmable constraint storage circuit that stores at least one resource control parameter constraint. This constraint can be used to constrain updates to resource control parameters used to manage resource allocation or contention, or to constrain the use of resource control parameters during memory transactions. Access to the resource control parameter constraints stored in the programmable constraint storage circuit is restricted to a specific subset of operating states, such as security domains. This allows the subset of operating states to limit which resource control parameters are permitted in other states, reducing the chance that previously set resource partitioning will be affected by subsequent updates to the resource control parameters. This can be particularly useful for enforcing specific use of cache or bandwidth resources in certain security or real-time software.

[0136] Figure 12 An example of a memory system component is shown, which may be one of cache memories 8, 12, 16, 20 or a memory controller 24 as in the example above. For the cache example, it should be understood that, although Figure 12 Not shown in the image, but Figure 12 MSCs may also include Figure 9 Some of the components shown include cache storage device 302, allocation counter 326, memory mapping status and configuration register 360, and performance monitoring storage devices 380 and 382.

[0137] The MSC has a set of resource control parameter storage circuitry 400 (e.g., registers) that stores a corresponding set of resource control parameters for a given partition identifier. Multiplexer 402 selects from the set of control parameters based on the partition identifier (and security domain indicator) associated with a request to use memory system resources. The partition identifier and security indicator are generated by the processing element issuing the request, as discussed above. Resource control circuitry 404 uses the selected set of resource control parameters to control resource allocation for processing memory transactions associated with a specified partition identifier or for managing contention for resources. The specific controls performed by the resource control circuitry can vary depending on the type of memory system component; for example, for a cache, control might be which cache entries can be allocated to store data associated with a memory transaction, while for a memory controller, control might be whether bandwidth on the bus can be allocated to a transaction.

[0138] The MSC has a resource control parameter update circuit 410 for controlling the update of 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 memory transaction that specifies the memory address of a resource control parameter register already mapped into the resource control parameter register 400 as its destination address. Alternatively, in examples using memory mapping status or configuration register 360, as in... Figure 9 In the example shown, parameter update request 412 can specify the address of a configuration register mapped to configuration register 360, and updates to these configuration registers 360 can then control resource control parameter update circuitry 410 to update the corresponding resource control parameter register 400. This method using configuration registers helps reduce the number of addresses that need to be exposed to memory mappings compared to a scenario where each corresponding resource control parameter register has its own memory-mapped address. Therefore, it should be understood that there are multiple ways in which resource control parameters can be updated in response to parameter update requests.

[0139] 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 update circuit 410 controls whether to allow the update of the target resource control parameter based on at least one resource control parameter constraint stored in the programmable constraint storage circuit 420. For example, the resource control parameter constraint may limit the minimum or maximum value that can be set for certain resource control parameters, or may specify whether certain portions of a memory system resource are allowed to update their corresponding resource control parameters to indicate that that portion of the resource is allowed to be allocated to any partition identifier. Therefore, when updating the target resource control parameter in response to parameter update request 412, the resource control parameter update circuit 410 considers whether the requested update would satisfy the constraints specified in the programmable constraint storage circuit 420, and if the parameter update request would violate these constraints, the resource control parameter update circuit 410 may reject the request, or the resource control parameter update circuit 410 may execute the request only to the extent permitted by the constraints. For example, instead of setting a value that violates the constraints, the resource control parameter update circuit 410 may set the resource control parameter to a value different from the requested value, where the different value does indeed satisfy the constraints.

[0140] Therefore, in this way, constraints can be used to ensure that once a specific set of resource control parameters is established within the MSC's register 400, subsequent updates cannot update these parameters outside the constraint limits defined in the programmable constraint storage circuit 420. This provides better guarantees for the desired resource allocation for specific critical security software, such as security software executing in security domain 90, or real-time critical software that requires specific limits, such as response latency.

[0141] Alternatively, instead of applying constraints when updating resource control parameters, resource control circuitry 404 may apply constraints when using resource control parameters 400 to control the processing of memory transactions. This will be discussed in conjunction with the following. Figure 18 Further description.

[0142] Regardless of whether 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 circuitry of a given processing element 6. For example, the programmable constraint storage circuit 420 may include one or more memory-mapped registers within the MSC, which can be updated by issuing a memory transaction that specifies the memory address mapped to one of these registers as its target address. The programmable constraint storage circuit can be programmable in response to the constraint update request when the processing circuitry 6 issues the constraint update request 422 in an operating state that excludes at least one operating state of the processing circuitry 6 within a restricted subset of operating states. Therefore, if the processing circuitry 6 issues the constraint update request 422 in an operating state other than one of these restricted subsets of operating states, programming of the programmable constraint storage circuitry can be disabled in response to the constraint update request 422. This ensures that any software execution environment that is allowed to set resource control parameter 400 but is not in a restricted subset of the operating states is forced to comply with the constraints set by the software executing in an operating state that is in a restricted subset of the operating states. This provides a stronger guarantee for the resource control parameter constraints enforced by the restricted subset of the operating states.

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

[0144] In one example, constraint update request 422 can be successfully implemented only when it is issued from a restricted subset of operating states (such as security domains) by controlling the memory mapping defined in the page table used by memory management unit 70. For example, addresses mapped to registers corresponding to programmable constraint memory circuitry 420 can be defined in any page table structure as being accessible only to secure code and potentially inaccessible to non-secure code. Furthermore, these addresses can be further restricted based on permission levels, such that only secure code associated with a given permission level or higher can access the memory-mapped registers used for storage resource control parameter constraints.

[0145] When the programmable constraint storage circuit 420 is reprogrammed to update resource control parameter constraints to new values, it is possible that the current values ​​of some memory system component resource control parameters stored in register 400 may violate the new values ​​of the constraints set in the programmable constraint storage circuit 420. In this case, despite violating the new constraints, it is not necessary to change the old values ​​of the resource control parameters in register 400. Preferably, the MSC retains the current value of any given MSC resource control parameter that violates the new values ​​of the constraints, regardless of the fact that it is now outside the limits indicated by the resource control parameter constraint 420. This ensures that security software or other software capable of setting constraints can first set certain resource-rich settings in the resource control parameters, which can manage their own resource allocation or manage the allocation of certain preferred software execution environments (such as real-time software), and then set the resource control parameter constraint 420 to a less resource-rich threshold so that any future updates are constrained to the resource control parameters in register 400 while still maintaining the previously set resource-rich controls. If the constraint control software subsequently needs to add new resource-rich settings to resource control parameters 400 that violate the current constraint value, the constraint control software may temporarily relax or remove (e.g., for at least a subset of partitions, such as security partitions) the constraints defined in the programmable constraint storage circuit 420, then add the new resource-rich resource control parameters to register 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.

[0146] Figure 13This is a flowchart illustrating a method for responding to a constraint update request 422, which requests an update to resource control parameter constraints in the programmable constraint storage circuit 420. At step 450, the constraint update request is received, and at step 452, it is determined whether the constraint update request originated from a secure domain or a less secure domain. In one example where access to the programmable constraint storage circuit 420 is controlled via memory mapping used by the MMU 70, steps 450 and 452 can then be efficiently performed by the MMU 70 rather than by the MSC receiving the constraint update request. Alternatively, regardless of which domain the request is detected to have originated from, the constraint update request can be forwarded to the MSC, accompanied by indicators showing the domains 90 and 92 from which it originated, and then some circuitry at the MSC can check whether the constraint update request originated from a secure domain. In this case, step 452 is performed at the MSC itself.

[0147] Therefore, if it is determined at step 452 that the constraint update request originated from the less secure domain 92, then the constraint update request 42 is rejected at step 454. If the constraint update request originated from a secure domain, then at step 456, the MSC executes the constraint update request, updating at least one resource control parameter constraint stored in the programmable constraint storage circuit 420 to one or more new values ​​as specified in the constraint update request. After the constraint is updated, at step 458, in response to the constraint update request, any old values ​​of the MSC resource control parameter 400 are retained even if they violate the new values ​​of the constraint set in the programmable constraint storage circuit 420. This ensures that any previously allocated resource-rich settings are preserved even if future updates are restricted.

[0148] Figure 14 A flowchart is shown illustrating the processing of a parameter update request 412 received at the MSC, requesting an update of resource control parameters. In this embodiment, resource control parameter constraints are used as resource control parameter update constraints, which constrain the processing of the parameter update request. At step 470, resource control parameter update circuitry 410 receives parameter update request 412, which may be, for example, a memory-mapped storage transaction as discussed 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. At step 472, resource control parameter update circuitry 410 checks whether the specified new parameter value violates any resource control parameter update constraints set in programmable constraint storage circuitry 420. If not, at step 474, the new parameter value can be written to the target resource control parameter in register 400 to provide the new partition control setting.

[0149] On the other hand, if at step 472 the new parameter value violates any resource control parameter update constraints specified in the programmable constraint storage circuit 420, different options are available to respond to the event. In one option, at step 476, parameter update request 412 can be simply rejected, thereby preserving any previous value of the target resource control parameter and not performing the update requested by parameter update request 412.

[0150] Alternatively, as shown in step 478, instead of simply rejecting the parameter update request, the parameter update request can be executed to the extent permitted by the resource control parameter update constraints. Therefore, in response to parameter update request 412, when a new value of the target memory system component resource control parameter violates the resource control parameter update constraints, the MSC's resource control parameter update circuit 410 sets the target MSC resource control parameter to a value that satisfies the resource control parameter update constraints, rather than using a new value that violates the constraints. For example, the resource control parameter update circuit 410 may attempt to set the target MSC resource control parameter to allow as much access to the memory system resources as the constraints allow. For example, the target MSC resource control parameter may be set to a value that matches a threshold defined in the resource control parameter update constraints, rather than being set to a new parameter value specified in the parameter update request. Therefore, using this method, if a given software process requests an update parameter to grant too many resources to a given partition identifier, instead, the MSC grants as much access to resources as is permitted within the limits of the constraints set in the programmable constraint memory circuit 420. This method can improve performance (avoiding unnecessary resource scarcity settings for processes that can be granted more resources while still adhering to certain constraints such as security codes and software-enforced constraints).

[0151] Regardless of which option in steps 476 and 478 is chosen, at step 480, the resource control parameter update circuit 410 determines whether constraint error reporting is supported and enabled for that particular MSC. If constraint errors are supported and enabled, an error reporting action is performed at step 482. This error reporting action can be at least one of the following: recording error reporting information in an error reporting storage element and / or signaling an interruption. On the other hand, if error reporting is not supported or is not currently enabled in a specific implementation that does support error reporting, no error reporting action is performed at step 484.

[0152] Generally speaking, it can be useful for software to know whether a parameter update request has not been fully executed because it specifies a new parameter value that violates parameter update constraints. This can be useful for debugging purposes, allowing the cause to be determined if the software does not function as expected, for example, because the software accesses memory system resources less than expected. This can aid in code development.

[0153] Some hardware implementations may not support error reporting at all, and in such cases, error reporting may not be performed when a new parameter value used for a parameter update request violates the parameter update constraint, and therefore for such implementations, the method always proceeds to step 484.

[0154] However, for other implementations that do support error reporting, this can be useful for improving debugging capabilities, allowing the software to receive a notification if a request for an update to resource control parameters has been degraded due to constraints set in the programmable constraint storage circuitry. Some such implementations that do support error reporting can permanently enable it, causing the method to always proceed to step 482 and never execute step 484.

[0155] However, in other specific implementations that do 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 of the MSC that stores parameters for enabling or disabling error reporting. In some cases, this configuration may simply be whether error reporting is fully implemented. In other examples, the configuration information may specify more detailed attributes of error reporting, such as defining specific error reporting actions to be taken (e.g., it may be configurable 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 if no interrupt is signaled). Another error reporting configuration option may be to report the occurrence of some types of errors while excluding others. Thus, constrained errors can be configured to be reported or not reported.

[0156] Figures 12 to 14 The examples provided provide a general overview of resource control parameter constraints. Figures 15 to 17 Examples of more specific types of constraints that can be applied to the corresponding types of MSC resource control parameters are shown.

[0157] Figure 15 As discussed above, Figure 11 The example shown above updates the constraints to resource control parameters that use a partial bitmap, as in the example example. Figure 15 A cache portion bitmap (CPBM) 502 for a partition ID is shown, which can be used to control requests to allocate data to the cache associated with that partition ID. The bitmap includes multiple bits, each corresponding to a specific portion of the cache capacity. When a given bit has a value of 0, this indicates that software using the corresponding partition ID is not allowed to allocate data to the corresponding portion of the cache, while a value of 1 allows software using the corresponding partition ID to allocate data to the corresponding portion of the cache. Although Figure 15 An example of cache allocation control based on this partial bitmap is shown, but it is also possible to provide partial-based resource allocation control parameters for other types of memory system components. For example, partial-based control of memory bandwidth allocation can be imposed by providing multiple independent types of bus integrals and using a partial-based bitmap to indicate which type of bus integral is allowed for a particular partition identifier. Therefore, more generally, partial-based resource allocation control parameters can be provided that specify, for each of two or more portions of a resource, whether that portion of the resource is allowed to be allocated for use by the software execution environment associated with the corresponding partition identifier.

[0158] like Figure 15 As shown, when using part-based resource allocation control parameters, resource control parameter update constraints can also be defined as a bitmap 500 used as a mask, which masks updates to at least a subset of the resource control bitmap 502 designated as part-based resource allocation control parameters. The mask bitmap (CPMBM) 500 serves as a part-based constraint that, for each subset of resource portions having corresponding bits in the part bitmap 502, specifies whether updating any part-based resource allocation control parameter 502 for any partition ID is permitted, indicating whether that particular portion is allowed to be allocated for use. For example, in Figure 15 In the encoding shown, if position 504 of partial mask bitmap 500 is 0, then the corresponding bit of partial 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 resources. On the other hand, when position 506 of partial mask bitmap 500 has a value of 1, this indicates that the corresponding bit is not allowed to be set to 1. Note that mask bitmap 500 is shared among all partial bitmaps 502 associated with all partition identifiers. Figure 15 Only a partial bitmap 502 for one partition ID is shown, but other partition IDs will each have their own partial bitmaps, such that each partial bitmap is subject to the same update constraints defined in the partial mask bitmap 500.

[0159] Therefore, the partial mask bitmap 500 serves as a portion-based constraint that determines which updates can be made to the portion-based resource allocation control parameters 502 to limit the resources that can be requested in a later request. This means that once the security domain software has allocated itself or a specific other software execution environment with a dedicated purpose to a specific portion of the memory system component resources, and has set control parameters for another partition identifier to exclude that other partition from using the reserved dedicated resources, setting the constraint in the partial mask bitmap 500 with a bit equal to 1 in the location corresponding to the reserved portion will prevent any other control software from subsequently updating the resource control bitmap 502 for any partition ID to change the bit corresponding to the reserved portion from 0 to 1.

[0160] In one exemplary implementation, when attempting to update a portion bitmap 502, where an attempt is made to set a given bit of portion bitmap 502 to 1, but the corresponding bit of the portion mask bitmap 500 indicates that this is prohibited, the given bit of portion bitmap 502 retains its previous value (therefore, if it was previously set to 0, it will remain 0 even though the corresponding bit of the new portion bitmap value 508 is 1, but if the given bit of the portion bitmap was 1 before the update, it can retain its value of 1 after the update). However, this behavior is not required.

[0161] A second approach is to clear any "masked" bits in partial bitmap 502 (which correspond to "1" bits 506 in partial mask bitmap 500 that indicate prohibiting setting the corresponding bit of partial bitmap 502 to 1) to 0 when updating partial bitmap 502, regardless of their previous state. In other words, when an update is applied to partial bitmap 502, mask bitmap 500 is applied, and any "disallowed bit" 506 in mask bitmap 500 forces the corresponding "masked" bit in partial bitmap 502 to be cleared (to indicate that the portion with the corresponding partition ID may not have been allocated resources). Therefore, if this approach is used, the previous values ​​of the "masked" bits in partial bitmap 502 are irrelevant. This can be useful because the relevant entries in the control settings table may be being updated since the corresponding PARTID has been recycled to the new software environment. Therefore, it may be preferable to ensure that any previously assigned settings in the previous software environment that violate the constraints defined in the partial mask bitmap 500 are cleared. Thus, for this embodiment, the “masked” bit identified by the partial mask bitmap 502 indicates that the new value 508 of the partial bitmap 500 does not allow the partition ID to allocate resources to that portion, such that after any subsequent write to the partial bitmap 500 used for the partition ID, the corresponding bit of the newly written partial bitmap 500 should indicate that the portion that is not allowed to allocate resources (e.g., in this embodiment, the bit should be 0).

[0162] In this second method, the constraint on updating the partial bitmap 502 can be enforced by combining the new bitmap value 508 specified in the parameter update request and the constraint partial mask bitmap 500, causing a bitwise AND operation to be performed between the new value and the corresponding bits of the inverted partial mask bitmap 500. In other words, ,in This is the new value set for bit j of part bitmap 500 of the partition ID i after the requested update. Bit j of the new value 508 of the partial bitmap 500 requested to be written to partition ID i, and This is the value of bit j in the constrained partial mask bitmap 502. This method means that any bit in the new bitmap value 508 that corresponds to a bit that is 1 in the partial mask bitmap 500 is cleared to 0. For example, in... Figure 15 In the specific instance shown, the new partial bitmap value 508 specified in the parameter update request requests an update to bitmap 502 to indicate that resource portions 0 and 1 can be assigned to the corresponding partition identifier. However, since bits 0 and 1 in the partial mask bitmap 500 are set to 1, this constrains the update and instead clears bits 0 and 1 of the corresponding partition's partial bitmap 502 to 0.

[0163] Note that having the same number of bits as partial bitmap 502 is not required for partial bitmap 500. In implementation, the software controlling the constraint storage circuit 420 is unlikely to impose constraints to prevent the entire partial bitmap 502 from changing from 0 to 1, as it would typically require allocating at least some resources in cache or memory components for other software execution environments. In implementation, there are hardware costs associated with implementing the storage of partial bitmap 500 within the programmable constraint storage circuit 420, and also with implementing the logic for combining the corresponding bits of partial bitmap 500 with the new value 508 of the partial bitmap. To limit these hardware costs, there may be a limit to the number of portions that can be constrained by the partial bitmap, and therefore, for any bit of partial bitmap 502 extending beyond the range covered by partial bitmap 500, it may be implicitly assumed that the partial mask bits for those portions are equal to 0, such that updates to those portions for memory system component resources are unconstrained. That is, a partial mask bitmap (based on partial constraints) can effectively constrain updates to only a specific subset of the resource, and this subset can exclude at least a portion of the resource, which can be more efficient in terms of hardware. In this case, if the security software controlling the constraints then wishes to reserve certain portions of the resource for its own use or for use by other specified software execution environments, it may be forced to select one of the portions corresponding to the bits explicitly stored in the partial mask bitmap 500 as the reserved portion of the resource.

[0164] Therefore, in summary, when memory system component resource control parameters include portion-based resource allocation control parameters, specifying whether each of two or more portions of a resource is allowed to be allocated to a software execution environment associated with a corresponding partition identifier, constraints may then include portion-based constraints specifying whether updating the corresponding portion-based resource allocation control parameters is allowed for each subset of portions to indicate that allocation of that portion is permitted. If a parameter update request requests updating the portion-based resource allocation control parameters to indicate that allocation of a given portion of the resource is permitted, and the portion-based constraints specify prohibiting updating a given portion to indicate that allocation to a given portion is permitted, then instead, the portion-based resource allocation control parameters may be set to indicate that allocation of the given portion of the resource is prohibited. Figure 15 The bottom shows an example of this situation, where the requested update that sets bits 0 and 1 of partial bitmap 502 to equal 1 is rejected, and instead those bits are set to equal 0 in the new value written to partial bitmap 502, because setting bits 0 and 1 of partial mask bitmap 500 to 1 indicates that partial 0 and 1 for available resources prohibits 0-to-1 conversion based on partial constraints.

[0165] It should be understood that Figure 15 The specific encoding shown is not required. For example, other implementations may reverse the meaning of 0s and 1s in one or both of partial bitmap 502 and partial mask bitmap 500.

[0166] like Figure 16 As shown, and as discussed above, other MSCs can define score-based resource control parameters that limit the maximum score of resources allowed to be allocated to software associated with a corresponding partition identifier. For example, Figure 16 An example is shown where the maximum score for cache allocation for a given partition identifier is defined by a cache allocation threshold 520, in which the cache allocation threshold is set to 40% of the cache capacity. When a capacity score limit is imposed in the MSC resource control parameters, the corresponding parameter update constraint can be another score 522, which sets a limit on the maximum score allowed specified in score control 520. Similarly, constraint 522 can be shared between the corresponding score control parameters 520 for each partition ID (for simplicity, ...). Figure 16 The fractional control parameter 520 is shown for only a single partition ID. For example, in Figure 16In this context, the maximum fraction that can be set in resource control parameter 520 is set to 50% in constrained storage 522. Therefore, attempts to update resource control parameter 520 to allocate any partition with more than 50% storage can be rejected, or only partially executed to the extent permitted within the upper limit set in programmable constraint 522. Using this method, when parameter update request 412 specifies a new value 524 to be written to the fraction-based control 520, this new value 524 can be combined with a limit specified in parameter update constraint 522 by minimum value determination circuit 526, which outputs the minimum of values ​​522 and 524, and then writes the resulting minimum value 528 to the capacity threshold fraction value 520 for the corresponding partition identifier. Therefore, if the requested new value 524 is less than or equal to the limit specified in parameter update constraint 522, the new value is simply written to the relevant resource control parameter 520; however, if the new value exceeds the limit, the limit value is written instead, preventing any more resources than allowed by the constraint from being allocated to the corresponding partition.

[0167] like Figure 17 As shown, in an example of a memory controller or other memory system component having minimum and maximum bandwidth thresholds 530, 532 as discussed above, corresponding minimum and maximum constraint limits 534, 536 can be provided within programmable constraint circuitry 420, each limiting the maximum value that can be written to in the minimum and maximum bandwidth values ​​530, 532. Similarly, a single instance of the minimum threshold limit 534 or the maximum threshold limit 536 can be shared among the bandwidth controls 530, 532 for all partition IDs. Similar to... Figure 16 The minimum value determination circuits 542 and 544 combine the constraint values ​​534 and 536 with new values ​​538 and 540 to be written to one of the minimum and maximum bandwidth limits 530 and 532. This ensures that, for both minimum and maximum bandwidth, the values ​​written to the resource control parameters 530 and 532 are limited to the levels specified in the corresponding constraint values ​​534 and 536. Therefore, by limiting updates to the maximum bandwidth to a certain level, this prevents the allocated memory bandwidth share for a given partition from exceeding the memory bandwidth share allowed by constraint control software (such as security domain codes). Furthermore, by preventing the minimum bandwidth from being set above a certain threshold level, this ensures that the extent to which memory transactions can increase their priority when the allocated bandwidth is less than the minimum threshold is limited.

[0168] therefore, Figure 16 and Figure 17An example is a memory system component resource control parameter group that includes a resource allocation threshold parameter. This resource allocation threshold parameter indicates a maximum or minimum threshold for controlling resource allocation used by the software execution environment associated with a corresponding partition identifier or for managing contention for resources. This resource allocation threshold parameter can be a maximum threshold, where it would result in the corresponding software execution environment being allocated a value greater than the maximum threshold (as in...). Figure 16 and Figure 17 If the resource quantity shown in Examples 520 and 532 is insufficient, further resource allocation will be prevented. Alternatively, the resource allocation threshold parameter may indicate a minimum threshold, such as in... Figure 17 In Example 530 shown, the priority of a request issued by the corresponding software execution environment can be increased 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.

[0169] Regardless of the method used, and regardless of whether the threshold is minimum or maximum, the resource control parameter update constraint can specify a threshold upper limit constraint (such as...). Figure 16 and Figure 17 Examples 522, 534, and 536 are shown. If a parameter update request requests an update to resource allocation threshold parameters 520, 530, and 532, the memory system component may prohibit the update of resource allocation threshold parameters 520, 530, and 532 to indicate a threshold greater than the threshold upper limit value indicated by threshold upper limit constraints 522, 534, and 536 as the maximum or minimum threshold. More specifically, when updating 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, and 540 specified by the parameter update request and the threshold upper limit values ​​522, 534, and 536 indicated by the threshold upper limit constraints.

[0170] It should be understood that, although Figures 15 to 17 Examples of MSC resource control parameter types and corresponding examples of constraints that can be set to include updates to those parameters are shown, but these are not the only examples available. In another example, a proportional span resource can be defined. A proportional span resource control has a span minus 1 parameter (STRIDEM1). STRIDEM1 is represented as a non-negative integer. A STRIDEM1 value of 0 grants maximum access to the resource. A STRIDEM1 value of 1 grants half access to the resource, a STRIDEM1 value of 3 grants one-quarter access to the resource, and so on. Constraints for proportional span resource control are also non-negative integers. When a new value for STRIDEM1 is written to PARTID, the value stored in the control settings storage is the maximum of the new value and the constraint.

[0171] When the processing system is reset (e.g., upon power-up, or when a reset signal indicating that the device will be reset to a known predetermined state is received), the contents of the programmable constraint storage circuit 420 can be reset to values ​​indicating that updates to the corresponding groups and memory system component resource control parameters 400 are unconstrained. Therefore, this allows the system firmware to be executed only after power-up or reset to set the corresponding groups of resource control parameters 400 without any restrictions, thereby enforcing any dedicated access to certain portions of the resources before setting constraints 420, which then protect those resource control settings from subsequent updates by other software.

[0172] Alternatively, in some implementations, there may be no hardware circuitry to force a reset of the constraints to values ​​indicating unconstrained updates to the MSC resource control parameters. In this case, after the reset, the firmware or other platform software executing on the device may be responsible for setting the device accordingly by setting the constraint register 420 to allow unconstrained updates to the resource control parameters until any partitioning of the dedicated resource has been performed, and then subsequently setting constraints in the programmable constraint storage circuitry 420 to suppress subsequent updates.

[0173] Therefore, in one possible use of the programmable constraint storage circuit, after the device's reset firmware is established, the constraint registers 420 can be configured such that they do not constrain the control settings in the resource control parameters 400 at all. For example, for Figure 15 A partial bitmap, which can be a partial mask bitmap 500 where all bits can be set to 0. For Figure 16 In the example of score-based threshold control, this could be setting the limit value specified in constraint register 522 to its maximum allowed value, and similarly, for Figure 17 For example, constraint registers 534 and 536, which limit the minimum and maximum bandwidth parameters, can be set to the maximum allowed constraint values. If the system firmware subsequently needs to allocate some resources from the early stages of the boot process for dedicated use, it can then set appropriate resource control parameters 400 to allow itself or certain other partitions exclusive access to certain portions of the memory system resources, or to grant a relatively high percentage of resources to itself or other processes, depending on the control type. After the resource control parameters have been set as needed, the system firmware can then set constraints to reduce the flexibility of subsequent updates to the control parameters, such as by... Figure 15 In the partial mask bitmap 500, some bits are set to be equal to 1, or as follows: Figure 16 and Figure 17 The thresholds defined in parameter update constraint registers 522, 534, and 536 are lowered as in the example.

[0174] Once the system is in normal operation, subsequent updates to the constraints can be restricted to a segment of control software, such as a small potential segment of software executing in the security domain that acts as the constraint controller. The constraint controller can receive constraint update requests from both secure and non-secure software and decide whether to grant or deny them. This software can then modify the contents of constraint register 420 in a specific memory system component as needed to enforce the constraints.

[0175] In another example, multiple constraints can be set for a given resource, each controlled by a different controller and applied only to access from lower-privilege environments. For instance, in a system with secure / non-secure domains, constraints from a secure controller can apply to lower privilege levels in the secure domain and to all privilege levels in the non-secure domain. A non-secure controller can specify constraints that apply to lower privileges in the non-secure environment but not to the secure environment.

[0176] While the foregoing has discussed several different types of constraints corresponding to different types of resource control parameters, it should be understood that any platform implementation may not use all of these examples, depending on the specific memory system components and resource partitioning controls included. Furthermore, some implementations may have some memory system components using one type of constraint and others using a different type (depending on the type of resource partitioning control implemented at each memory system component).

[0177] The above text Figures 14 to 17 The example illustrates the constraints applied when updating resource control parameters for a given partition identifier. For example... Figure 18 As shown, an alternative approach is to allow unconstrained setting of resource control parameters, but to use constraints defined in the programmable constraint storage circuit 420 to constrain the use of resource control parameters when processing memory transactions. For example, if memory transactions are to be controlled based on a given resource control parameter, and constraints have been defined to impose limits on that given resource control parameter, then even if the stored value of the given resource control parameter violates the constraints defined by the constraints, the given resource control parameter can be interpreted as having a constraint value within the constraints defined by the constraints, and this constraint value can be used to control resource allocation or manage competition between resources, rather than the actual value stored for the given resource control parameter.

[0178] Therefore, in Figure 18 In the example, it can be with Figures 14 to 17 The example defines resource control parameter constraints in a similar way (e.g., using a partial mask bitmap 500 or threshold upper limits 522, 534, 536), but this constraint can be interpreted as a resource control parameter usage constraint rather than a resource control parameter update constraint.

[0179] Figure 18A more detailed illustration is shown in one implementation where, in Figure 8 Step 206 uses resource control parameters to control resource allocation or manage contention for resources. At step 600, the memory system component determines whether the memory transaction being processed is a constrained type memory transaction subject to any constraints defined in the programmable constrained memory circuitry.

[0180] like Figure 19 As shown, in addition to partition identifier 602, a memory transaction may specify one or more identifiers, such as a permission level identifier 604 indicating the permission level associated with the memory transaction, a security domain identifier 606 indicating the security domain associated with the memory transaction, and / or a constraint exemption identifier 608 indicating whether the memory transaction is exempted from constraints based on the corresponding resource control parameter constraints. It should be understood that these are merely examples, and not all of these identifiers must be used. 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, and 608 specified by the memory transaction. For example, some specific PARTIDs may be exempted from constraints, while others may be constrained. Furthermore, determining whether a constraint applies may be based on whether the memory transaction originates from a security domain or a non-security domain (e.g., a secure transaction may be unconstrained, but a less secure transaction may be constrained). Another approach could be that memory transactions originating from permission levels below a certain threshold may be constrained, but processes with higher permissions may allow their memory transactions to be unconstrained. Additionally, constraint exemption identifier 608 allows some software processes to individually identify specific transactions as exempt from constraints, while other transactions from the same software process can be constrained. In some examples, constraint exemption identifier 608 can be used in combination with one of the other identifiers 602, 604, and 606, such that only certain software processes (e.g., security processes or processes with permissions greater than a threshold) are allowed to selectively exempt their transactions from constraints, while other software processes can constrain all their transactions, regardless of the value of constraint exemption identifier 608.

[0181] There are numerous options available. In some implementations, determining whether a memory transaction is constrained or unconstrained can depend on programmable configuration data stored in a control register. For example, the permissions process can program the configuration data to specify a PARTID, permission level, or security domain to which constraints should or should not be applied, or set a “mode” indicator that indicates a particular mode to determine whether a memory transaction is constrained (e.g., one mode may determine whether a transaction should be constrained based on a PARTID, another mode may determine whether a transaction should be constrained based on a permission level, and other modes may use combinations of identifiers, such as the combination of exemption identifier 608 and permission level 604).

[0182] Therefore, regardless of the precise mechanism used to distinguish between constrained and unconstrained types of memory transactions, it is determined at step 600 whether the specific memory transaction being processed is a constrained type of memory transaction. By providing a mechanism for exempting some memory transactions from constraints, this allows some preferred processes (such as security domain processes or real-time critical processes) to use relatively resource-rich settings, while other processes are constrained to use settings within certain limits.

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

[0184] If the memory transaction is a constrained type memory transaction, then at step 612, it is determined whether a given resource control parameter in the selected set of resource control parameters violates the resource control parameter constraints stored in the programmable constraint storage circuit 420. If the given resource control parameter does not violate the constraint, then at step 614, the given resource control parameter (unmodified) can be used to control resource allocation or manage contention for the resource. If the given resource control parameter does violate the constraint, then at step 616, the constraint value of the resource control parameter, which is determined based on the resource control parameter constraint and is less lenient than the stored value of the resource control parameter in allowing resource allocation, can be used to control resource allocation or manage contention for the resource. For example, for threshold-based resource control parameters, the constrained resource control parameter used at step 616 could be an upper limit of the threshold specified by the constraint. For partial resource control parameters, the constrained resource control parameter used at step 616 could be a modified bitmap, where any bits indicated to be masked by the corresponding partial masking bitmap are assumed to be cleared, such that the corresponding portion of the resource cannot be allocated to the memory transaction. At step 618, if error reporting is both hardware-supported and enabled (the decision on whether error reporting is enabled or disabled depends on the configuration settings), then an error reporting action is taken (e.g., logging error reporting information and / or signaling an interrupt), as in... Figure 14 Like step 482.

[0185] Figure 18The logical flow at steps 612, 614, and 616 is illustrated, where it is first determined whether a resource control parameter violates a constraint, and then resource allocation or competition for resources is controlled using either the unmodified or constrained resource control parameter. If error reporting is not required, an equivalent approach could be to omit any determination of whether a given resource control parameter violates a constraint, but instead simply combine the given resource control parameter with the constraint in such a way that the result of the combination is either the original given resource control parameter (if the parameter does not violate the constraint) or a constraint corresponding to the limitation indicated by the constraint (if the parameter does violate the constraint). For example, for a part-based approach, a valid value for the part bitmap 502 used to control resource allocation can be generated by performing a bitwise AND operation on the part bitmap 502 using the inverse of the mask bitmap 500 representing the constraint, similar to the bitwise AND function described above for controlling updates to the part bitmap 502 in the previous example (alternatively, different functions of logical operators can be used to combine the part bitmap 502 or the mask bitmap 500 with different encodings to generate valid values ​​for resource control). For threshold-based methods, the effective value of the cache capacity or minimum / maximum bandwidth allocation threshold used for handling resource allocation or contention management can be determined as the minimum of the stored value of the threshold and the threshold represented by the constraint (similar to...). Figure 16 and Figure 17 (The method in the text). Therefore, it should be understood that if error reporting is not required, it is not necessary to actually determine whether the stored resource control parameters violate constraints.

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

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

Claims

1. A data processing apparatus, the apparatus comprising: Processing circuitry for processing instructions from one of multiple software execution environments; as well as A memory system component for processing memory transactions issued by the processing circuit in response to the instruction; wherein: In response to a memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the memory system component is configured to: control resource allocation for processing the memory transaction or manage contention for the resources based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; The memory system component includes programmable constraint storage circuitry to store at least one resource control parameter constraint, the at least one resource control parameter constraint specifying at least one of the following: During the update of the target memory system component resource control parameters, the limits of the values ​​that the target memory system component resource control parameters are allowed to be set are included. When processing memory system transactions, the target memory system component resource control parameters are limits on the effective values ​​used to control resource allocation or manage competition for the resources; and 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 the following: Update the target memory system component resource control parameters; and The target memory system component resource control parameters are used to control resource allocation or manage competition for the resources.

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

3. The apparatus of claim 2, wherein 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 to the secure domain; and The restricted subset of operating states includes at least one operating state in which the processing circuit operates within the security domain.

4. The apparatus according to any one of claims 1 to 3, wherein when the programmable constraint storage circuit is reprogrammed to update the at least one resource control parameter constraint to a new value, and the 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: The memory system component is configured to retain the current value of the given memory system component resource control parameter, regardless of any violation of the constraint indicated by the new value constrained by the at least one resource control parameter.

5. The apparatus according to any one of claims 1 to 3, wherein: In response to a parameter update request that requests an update of the target memory system component resource control parameters, the memory system component is configured to constrain the update of the target memory system component resource control parameters based on the at least one resource control parameter constraint stored in the programmable constraint memory circuit.

6. The apparatus according to claim 5, wherein: In response to a parameter update request that requests updating the target memory system component resource control parameters to a new value, 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 parameters to a value that satisfies the at least one resource control parameter constraint.

7. The apparatus according to claim 5, wherein: In response to a parameter update request that requests updating the resource control parameters of the target memory system component to a new value, the memory system component is configured to perform an error reporting action when the new value violates at least one resource control parameter constraint; The error reporting action includes at least one of the following: Error report information is recorded in the error report storage element; as well as Send a signal to notify of the interruption.

8. The apparatus of claim 7, wherein in response to the parameter update request requesting to update the target memory system component resource control parameters to a new value, 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 based on programmable configuration information stored in a configuration storage element.

9. The apparatus according to any one of claims 1 to 3, wherein, in response to the memory transaction issued by the processing circuitry, when the memory transaction is a constrained type memory transaction, the memory system component is configured to: When a given resource control parameter from a selected set of one or more memory system component resource control parameters satisfies the corresponding resource control parameter constraint, the resource allocation or competition for the resource is controlled based on the given resource control parameter; and When the given resource control parameters violate the corresponding resource control parameter constraints, the resource allocation or management of competition for the resources is controlled according to the constrained resource control parameters determined based on the corresponding resource control parameter constraints.

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

11. The apparatus of claim 10, wherein the at least one identifier comprises at least one of the following: The partition identifier; A permission level identifier, which indicates the level of permission associated with the memory transaction; A security domain identifier, which indicates the security domain associated with the memory transaction; as well as A constraint exemption identifier, which indicates whether the memory transaction is exempted from constraints based on the corresponding resource control parameter constraint.

12. The apparatus according to any one of claims 1 to 3, wherein, in response to a reset signal indicating that the apparatus will 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 an update or use of the resource control parameters of the plurality of sets or one or more memory system components without constraint.

13. The apparatus according to any one of claims 1 to 3, wherein for a given memory system component, each group 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, which specify, for each of a plurality of portions of the resource, whether the portion of the resource is allowed to be allocated 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, which specifies, for each subset of portions of the resource, at least one of the following: Whether to allow updating the portion-based resource allocation control parameters to indicate that the portion of the resource is allowed to be allocated; as well as When the portion-based resource allocation control parameters are used to control the allocation of resources for constrained type memory transactions, whether the given memory system component should prevent the allocation of the portion of the resource, even if the portion-based resource allocation control parameters specify that the allocation of the portion of the resource is allowed.

14. The apparatus of claim 13, wherein a subset of the excluded resources comprises at least one portion of the plurality of portions.

15. The apparatus according to claim 13, wherein: In response to a request to update the resource allocation control parameters based on a portion to indicate that a given portion of resources is allowed to be allocated, when the portion-based constraint specifies that updating the resource allocation control parameters based on the portion to indicate that the allocation of the given portion is allowed, the given memory system component is configured to set the resource allocation control parameters based on the portion to indicate that the allocation of resources is prohibited for the given portion.

16. The apparatus according to any one of claims 1 to 3, wherein for a given memory system component, each group of one or more memory system component resource control parameters is associated with a corresponding partition identifier, and includes a resource allocation threshold parameter, the resource allocation threshold parameter indicating a maximum or minimum threshold for controlling resource allocation or managing competition 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 that indicates a threshold upper limit value; as well as At least one of the following: In response to a parameter update request that requests an update to the resource allocation threshold parameter, the given memory system component is configured to prohibit updating the resource allocation threshold parameter, indicating a threshold greater than the upper threshold value indicated by the upper threshold constraint as the maximum or minimum threshold. as well as In response to a memory transaction issued by the processing circuitry, when the memory transaction is a constrained type memory transaction and the resource allocation threshold parameter violates the upper threshold constraint, the given memory system component is configured to control resource allocation or manage resource contention based on a constrained threshold less than or equal to the upper threshold value indicated by the upper threshold constraint.

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

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

19. A data processing apparatus, the apparatus comprising: A means for processing instructions from one software execution environment from multiple software execution environments; as well as A means for processing memory transactions initiated by the means for processing in response to the instructions; wherein: In response to a memory transaction issued by the means for processing specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the means for processing the memory transaction is configured to: control resource allocation or manage contention for the resources for processing the memory transaction based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; The apparatus for processing memory transactions includes means for programmably storing at least one resource control parameter constraint, the at least one resource control parameter constraint specifying at least one of the following: During the update of the target memory system component resource control parameters, the limits of the values ​​that the target memory system component resource control parameters are allowed to be set are included. When processing memory system transactions, the target memory system component resource control parameters are limits on the effective values ​​used to control resource allocation or manage competition for the resources; and Based on the at least one resource control parameter constraint stored in the device for programmable storage, the device for processing memory transactions is configured to constrain at least one of the following: Update the target memory system component resource control parameters; and The target memory system component resource control parameters are used to control resource allocation or manage competition for the resources.

20. A data processing method, the method comprising: Process instructions from one software execution environment that come from multiple software execution environments; as well as Process memory transactions issued in response to the instruction; wherein: In response to a memory transaction specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, a memory system component controls resource allocation for processing the memory transaction or manages contention for the resources based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; A means for storing at least one resource control parameter constraint, the at least one resource control parameter constraint specifying at least one of the following: During the update of the target memory system component resource control parameters, the limits of the values ​​that the target memory system component resource control parameters are allowed to be set are included. When processing memory system transactions, the target memory system component resource control parameters are used to control the limits of effective values ​​for resource allocation or management of competition for the resources. Based on at least one resource control parameter constraint stored in the programmable constraint storage circuit, constrain at least one of the following: Update the target memory system component resource control parameters; and The target memory system component resource control parameters are used to control resource allocation or manage competition for the resources.

21. A data processing apparatus, the apparatus comprising: Processing circuitry for processing instructions from one of multiple software execution environments; as well as A memory system component for processing memory transactions issued by the processing circuit in response to the instruction; wherein: In response to a memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the memory system component is configured to: control resource allocation for processing the memory transaction or manage contention for the resources based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; The memory system component includes programmable constraint storage circuitry to store at least one resource control parameter constraint; and 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 the following: Update the target memory system component resource control parameters; and The target memory system component resource control parameters are used to control the allocation of resources or manage contention for the resources; wherein, for a given memory system component, each group of one or more memory system component resource control parameters is associated with a corresponding partition identifier, and includes part-based resource allocation control parameters, which specify, for each of a plurality of parts of the resource, whether the allocation of that part of the resource is permitted for use by the software execution environment associated with the corresponding partition identifier; The at least one resource control parameter constraint includes a portion-based constraint, which specifies, for each subset of portions of the resource, at least one of the following: Whether to allow updating the portion-based resource allocation control parameters to indicate that the portion of the resource is allowed to be allocated; and When the portion-based resource allocation control parameters are used to control the allocation of resources for constrained type memory transactions, whether the given memory system component should prevent the allocation of the portion of the resource, even if the portion-based resource allocation control parameters specify that the allocation of the portion of the resource is allowed.

22. A data processing apparatus, the apparatus comprising: Processing circuitry for processing instructions from one of multiple software execution environments; as well as A memory system component for processing memory transactions issued by the processing circuit in response to the instruction; wherein: In response to a memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the memory system component is configured to: control resource allocation for processing the memory transaction or manage contention for the resources based on a selected set of one or more memory system component resource control parameters, the selected set being chosen from multiple sets of one or more memory system component resource control parameters based on the partition identifier specified by the memory transaction; The memory system component includes programmable constraint storage circuitry to store at least one resource control parameter constraint; and 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 the following: Update the target memory system component resource control parameters; and The target memory system component resource control parameters are used to control the allocation of resources or manage competition for the resources; wherein for a given memory system component, each group of one or more memory system component resource control parameters is associated with a corresponding partition identifier and includes a resource allocation threshold parameter, which, for the software execution environment associated with the corresponding partition identifier, indicates a maximum or minimum threshold for controlling the allocation of resources or managing competition for resources. The at least one resource control parameter constraint includes a threshold upper limit constraint indicating a threshold upper limit value; and At least one of the following: In response to a parameter update request that requests an update to the resource allocation threshold parameter, the given memory system component is configured to prohibit updating the resource allocation threshold parameter, indicating a threshold greater than the upper threshold value indicated by the upper threshold constraint as the maximum or minimum threshold; and In response to a memory transaction issued by the processing circuitry, when the memory transaction is a constrained type memory transaction and the resource allocation threshold parameter violates the upper threshold constraint, the given memory system component is configured to control resource allocation or manage resource contention based on a constrained threshold less than or equal to the upper threshold value indicated by the upper threshold constraint.

Images