Partition identifier for page table walk memory transactions

Abstract

The memory transaction may be tagged with a partition identifier selected depending on which software execution environment issued the memory transaction. A memory system component may control allocation of resources for processing the memory transaction or manage resource contention depending on a selected set of memory system component parameters selected depending on the partition identifier specified by the memory transaction, or may control whether performance monitoring data is updated in response to the memory transaction depending on the partition identifier specified by the memory transaction. A page table walk memory transaction may be assigned a partition identifier that is different from the partition identifier assigned to the corresponding data / instruction access memory transaction.

Description

[Background technology]

[0001] Technical Field The present technology relates to the data processing field.

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

[0003] At least some examples provide an apparatus comprising: a processing circuit that processes instructions from one of a plurality of software execution environments; and at least one memory system component for processing a memory transaction issued by the processing circuit in response to the instructions, wherein in response to the memory transaction issued by the processing circuit specifying a selected partition identifier in response to which software execution environment caused the memory transaction to be issued, the at least one memory system component is configured to control allocation of resources for processing the memory transaction or manage contention for such resources in response to a selected set of memory system component parameters selected in response to the partition identifier specified by the memory transaction, or control whether performance monitoring data is updated in response to the memory transaction in response to the partition identifier specified by the memory transaction, wherein when a page table walk memory transaction is issued by the processing circuit to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the processing circuit can assign the page table walk memory transaction a different partition identifier to the partition identifier assigned to the corresponding data / instruction access memory transaction.

[0004] At least some examples provide an apparatus comprising: means for processing instructions from one of a plurality of software execution environments; and at least one 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 a designation of a partition identifier selected in response to which software execution environment caused the memory transaction to be issued, the at least one means for processing the memory transaction is configured to control allocation of resources for processing the memory transaction or manage contention for such resources in response to a selected set of memory system component parameters selected in response to the partition identifier specified by the memory transaction, or control whether performance monitoring data is updated in response to the memory transaction in response to the partition identifier specified by the memory transaction, and wherein when a page table walk memory transaction is issued by the means for processing to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the means for processing can assign to the page table walk memory transaction a partition identifier that is different from the partition identifier assigned to the corresponding data / instruction access memory transaction.

[0005] At least some examples provide a method including 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 responsive to which software execution environment caused the memory transaction to be issued, at least one memory system component controls allocation of resources for processing the memory transaction or manages contention for such resources responsive to a selected set of memory system component parameters selected responsive to the partition identifier specified by the memory transaction, or controls whether performance monitoring data is updated responsive to the memory transaction responsive to the partition identifier specified by the memory transaction, wherein when a page table walk memory transaction is issued to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the partition identifier assigned to the page table walk memory transaction can be a different partition identifier than the partition identifier assigned to the corresponding data / instruction access memory transaction. [Brief description of the drawings]

[0006] [Figure 1] 1 is a schematic diagram of an example of a data processing system including a memory system; [Diagram 2] FIG. 1 is a diagram illustrating an example of controlling the division of memory system resources according to a partition identifier assigned to a software execution environment associated with a memory transaction. [Diagram 3] FIG. 2 illustrates an example of a processing circuit for issuing memory transactions that specify a partition identifier. [Figure 4] FIG. 2 illustrates an example of different software execution environments executed by a processing circuit. [Diagram 5]FIG. 13 is a diagram illustrating an example of assigning partition identifiers to different software execution environments. [Figure 6] FIG. 2 illustrates an example of a control register for controlling which partition identifier is specified for a given memory transaction. [Figure 7A] 1 is a flow diagram illustrating a method for issuing a data access memory transaction from a master device. [Figure 7B] 1 is a flow diagram illustrating a method for issuing an instruction fetch memory transaction from a master device. [Figure 8] FIG. 2 illustrates a schematic diagram of the selection of a partition identifier register depending on the current operating state of the processing circuit; [Figure 9] FIG. 2 illustrates a schematic diagram of an example of mapping virtual partition identifiers to physical partition identifiers. [Figure 10] 4 is a flow diagram illustrating a method for mapping a virtual partition identifier to a physical partition identifier. [Figure 11] FIG. 13 illustrates a schematic diagram of an example of generating separate partition identifiers for instruction and data memory transactions. [Figure 12] 1 is a flow diagram illustrating a method for responding to a memory transaction in a memory system component. [Figure 13] FIG. 2 illustrates an example of a cache that controls allocation of cache resources according to a partition identifier and / or updates selected performance monitoring data based on the partition identifier. [Figure 14] 1 is a flow diagram illustrating a method for controlling allocation to a cache according to a capacity threshold selected according to a partition identifier. [Figure 15] FIG. 13 illustrates an example of controlling which part of a cache data can be allocated depending on a partition identifier. [Figure 16] FIG. 13 illustrates a first example in which several partition identifier registers are provided that are dedicated to page table walk memory transactions. [Figure 17] FIG. 13 illustrates an alternative example in which configuration information is provided to control whether a page table walk transaction uses a partition identifier from a partition identifier register associated with the current privilege level or a privilege level of greater privilege. [Figure 18] FIG. 13 illustrates a method for controlling which partition identifier is used for a page table walk memory transaction.

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

[0008] Thus, the processing circuitry may present a partition identifier as a label for memory transactions depending on which software issued the transaction. This means that resources in the memory system can be divided between software execution environments, preventing one software execution environment from exceeding its fair share of resources and addressing the noisy neighbor problem described above.

[0009] However, the inventors have recognized that not all memory transactions issued when executing a given software execution environment access information related to that environment. As discussed in more detail below, in the case of a page table walk memory transaction issued to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the page table data may be managed by a software execution environment executing at a higher level of privilege than the execution environment that issued the data or instruction access memory transaction. If the memory resources consumed by the page table walk memory transaction are consumed as part of the resource allocation of the lower privilege execution environment that issued the page table walk request, this may take away resources that could be used for other memory transactions issued by that software execution environment, resulting in an imbalance in the relative amounts of memory resources assigned to different software execution environments. For example, this may actually result in a performance imbalance among software execution environments that may have been provided with substantially equal resource allocations, where the first of two or more software execution environments that share access to common page table data may consume some of its resources because it was the first to access the page table data, and then other execution environments that use the same page table data may have more resources because their data / instruction access memory transactions were able to use page table data that was already cached in response to the first software execution environment.

[0010] Accordingly, several embodiments are described below that enable the processing circuitry to assign a different partition identifier to a page table walk memory transaction than the partition identifier assigned to the corresponding data / instruction access memory transaction, thereby allowing the resource partitioning to more accurately correspond to the way page table data is managed for different software execution environments, providing a more fair resource partitioning.

[0011] Before considering control of partition identifiers for page table walk memory transactions, a general architecture for setting partition identifiers for a software execution environment and using those partition identifiers to control resource allocation or management and / or performance monitoring within a memory system will first be described. After the general architecture is described, the functionality for controlling page table walk memory transactions will be described below in a section entitled "Control of Partition Identifiers for Page Table Walk Memory Transactions."

[0012] A Generic Architecture for Memory Resource and Performance Monitoring Partitioning. 1 shows a schematic diagram of an example of a data processing system 2 including N (N is 1 or more) processing clusters 4, each including one or more processing units 6, such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). 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 will be appreciated that this is only one example of a possible cache hierarchy and that other cache configurations may be used. Processing units 6 in the same cluster are coupled by a cluster interconnect 14. The cluster interconnect may include a cluster cache 16 for caching data accessible to either processing unit.

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

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

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

[0016] When multiple software execution environments running on a processing element 6 share access to a memory system, it may be desirable to prevent one software execution environment from using more than its fair share of resources to prevent the other execution environments from perceiving a loss in performance. This may be particularly important for data center (server) applications where there is an increasing demand to reduce capital expenditures by increasing the number of independent software processes interacting with a given amount of memory capacity in order to increase utilization of the data center servers. Nevertheless, there is still a demand to achieve tail latency targets for web applications, so it is undesirable if one process running on a server can monopolize memory system resources to the extent that other processes suffer. Similarly, in networking applications, it is increasingly common to combine multiple functions that would previously have been in separate SoCs into a single SoC. This again leads to a desire to limit performance interactions between software execution environments and monitor how these independent processes need to be allowed to access the shared memory while limiting performance interactions.

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

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

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

[0020] These control schemes are described in more detail below. Of course, these are merely two examples of ways in which control of memory system resources can be partitioned based on the software execution environment that issued the corresponding transaction. In general, allowing different processes to "see" different partitioned portions of the resources provided by the memory system can limit performance interactions between processes to help address the issues discussed above.

[0021] Similarly, performance monitoring within a memory system can be partitioned using partition identifiers associated with memory transactions so that a separate set of performance monitoring data can be tracked for each partition identifier to allow information specific to a given software execution environment (or group of software execution environments) to be identified, making the cause of a potential performance interaction easier to identify than if performance monitoring data was recorded across all software execution environments. This can also aid in diagnosing the effects of potential performance interactions and identifying possible solutions.

[0022] An architecture is described below for controlling the setting of partition identifiers, labeling memory transactions based on the partition identifiers set for corresponding software execution environments, routing the partition identifiers through a memory system, and providing partition-based control in memory system components within the memory system. This architecture is extensible for a wide range of uses of partition identifiers. The use of partition identifiers is intended to overlay, unaltered, existing architectural semantics of the memory system, so that the addressing, coherence, and required ordering of memory transactions imposed by the particular memory protocol used by the memory system are not affected by the resource / performance monitoring partitioning. When a partition identifier is used to control resource allocation, this may affect the performance achieved when servicing memory transactions for a given software execution environment, but it does not affect the outcome of architecturally significant computations. That is, the partition identifier does not change the outcome or result of a memory transaction (e.g., what data is accessed), but merely affects the timing or performance achieved for that memory transaction.

[0023] 3 shows an example of a processing unit 6 in more detail. The processor includes a processing pipeline including several pipeline stages, including a fetch stage 40 for fetching instructions from an instruction cache 10, a decode stage 42 for decoding the fetched instructions, an issue stage 44 including an issue queue 46 for queuing instructions while waiting for operands to become available and issuing instructions for execution when the operands become available, an execution stage 48 including a number of execution units 50 for executing different classes of instructions to perform corresponding processing operations, and a writeback stage 52 for writing results of the processing operations to data registers 54. Source operands for data processing operations may be read from registers 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 for loading data from a memory system into registers 54 or store operations for storing data from registers 54 into the memory system. Of course, these are just a few examples of possible execution units and other types can be provided. Similarly, other examples can have different configurations of pipeline stages. For example, the faulty processor can provide additional register renaming stages to remap architectural register specifiers specified by instructions to physical register specifier identification registers 54 provided in hardware, as well as a reorder buffer to track the execution and commitment of instructions executed in a different order than the order in which they were fetched from the cache 10. Similarly, other mechanisms not shown in FIG. 1 can still be provided, for example, a branch prediction function can be provided in the fetch stage to control the generation of the next fetch address 61 based on the predicted outcome of the branch instruction.

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

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

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

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

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

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

[0030] FIG. 4 then illustrates several different software execution environments 80, 82, 84, 94, 96, 98 that may be executed on the system. Each of these software execution environments may be assigned a given partition identifier (partition ID or PARTID), or a group of two or more software execution environments may be assigned a common partition ID. In some cases, individual parts of a single process (e.g., different functions or subroutines) may be considered separate execution environments and assigned separate partition IDs. For example, in the example shown in FIG. 5, virtual machine VM3 and two applications 3741, 3974 running under it are all assigned PARTID1, a particular process 3974 running under a second virtual machine VM7 is assigned PARTID2, and VM7 itself and another process 1473 running under it are assigned PARTID0. It is not necessary to assign individual partition IDs to all software execution environments. A default partition ID may be designated for use for software execution environments that are not assigned a dedicated partition ID. Control of what portion of the partition ID space is assigned to each software execution environment is performed by software at a higher privilege level; for example, a hypervisor running at EL2 controls the assignment of partitions to virtual machine operating systems running at EL1. In some cases, however, the hypervisor may allow lower privilege level operating systems to set their own partition IDs for some of their own code or applications running under them. Also, in some examples, secure world 90 may have a partition ID space entirely separate from normal world 92, controlled by the secure world OS or monitor program EL3.

[0031] As shown in Figure 3, the CPU may include MPAM generation logic 77 for generating MPAM-related information associated with a given memory access transaction. The MPAM-related information may include at least a PARTID, but in some examples may include other information as well. The MPAM generation logic 77 may include MPAM register selection logic 78 that selects between partition ID registers in the MPAM control registers 68 to determine which registers to use to generate the MPAM-related information, and partition ID virtualization logic 79 to control the mapping of virtual partition IDs to physical partition IDs. The MPAM register selection logic 78 and partition ID virtualization logic 79 are described in more detail below with respect to Figures 8 and 9, respectively. The MPAM generation logic 77 generates several alternative MPAM related information, including instruction MPAM related information (I-MPAM) used for instruction fetch accesses, data MPAM related information (D-MPAM) used for data accesses, instruction page table walk MPAM related information (I-PTW-MPAM) used for page table walk accesses triggered by instruction fetches, and data page table walk MPAM related information (D-PTW-MPAM) used for data page table walk MPAM related information. The selection between I-PTW-MPAM and D-PTW-MPAM is described in more detail below with reference to Figures 16-17.

[0032] 6 illustrates an example of the MPAM control registers 68. The MPAM control registers 68 include several partition ID registers 100 (also known as MPAM system registers), each corresponding to a respective operating state of the processing circuit. The MPAM control registers 68 also include a hypervisor control register (HCR), MPAMHCR_EL2 116, a virtual partition ID valid register (MPAMVPMV_EL2) 124, and a set of virtual partition ID mapping registers 126. In this example, there are eight virtual partition ID mapping registers 126, MPAMVPM0_EL2 through MPAMVPM7_EL2, although it will be appreciated that other implementations may provide a different number.

[0033] In this example, partition ID register 100 includes registers MPAM0_EL1 through MPAM3_EL3 corresponding to respective exception levels EL0 through EL3. In this example, partition ID register 100 may be shared between the secure and non-secure worlds for a given exception level, although another approach may be to provide a dedicated partition ID register for secure world processing at a given exception level separate from the partition ID register used for the same exception level in the non-secure world.

[0034] Each partition ID register 100 contains fields for up to three partition IDs, as shown in Table 1 below.

[0035] [Table 1] Table 2 below summarizes which partition ID register 100 is used for memory transactions performed in each operational state and from which operational states each partition ID register 100 is controlled (i.e., which operational states can update the information specified by that register).

[0036] [Table 2]

[0037] The naming convention MPAMx_Ely for the partition ID register indicates that the partition ID specified in the partition ID register MPAMx_ELy is used for memory transactions issued by the processing circuitry 6 when in the operational state ELx, and that state ELy is the lowest exception level that can access that partition ID register MPAMx_ELy. However, if the current exception level is EL0 in the non-secure domain, MPAM0_EL1 can be overridden, and if the setting value GSTAPP_PLK set in the control register (MPAMHCR_EL2 116 described below) is set to 1, the partition ID in MPAM1_EL1 is used. Thus, if necessary, the control of EL1 can override the control of EL0. This can be useful to restrict all applications running in a particular virtual machine to use the same partition ID, so that MPAM0_EL1 does not need to be updated every time there is a context switch between applications in the same virtual machine. Although in this example the configuration parameter GSTAPP_PLK is described as being stored in the MPAMHCR_EL2 116 control register, it may also be stored in another MPAM control register 68 (e.g., the partition ID register corresponding to the higher exception level for which the configuration parameter is set).

[0038] In general, when switching between different processes running in the same state (e.g., different applications at EL0 or different guest operating systems at EL1), an exception event triggers a switch to the higher exception state in which the process is running in that state (e.g., the operating system at EL1 or the hypervisor at EL2), and then updates the partition ID in the associated partition ID register 100 before returning processing to the lower exception state to allow the new process to continue. Thus, the partition ID associated with a given process can effectively be considered part of the context information associated with that process, and this context information is saved and restored as part of the processor's architectural state when switching to or from that process.

[0039] However, by providing multiple partition ID registers 100 corresponding to different operational states of the system, it is not necessary to update the contents of a single partition ID register every time there is a change in operational state, other than at a context switch, such as when an operating system (OS) temporarily traps to the hypervisor for the hypervisor to perform some action before returning to the same OS. Such traps to the hypervisor can be quite common in virtualized systems, for example when the hypervisor needs to intervene to present to the OS a different view of the physical resources than is actually presented in the hardware. Thus, by providing multiple partition ID registers 100, performance is improved since the labeling of memory system transactions with partition IDs automatically tracks changes in exception levels or secure / non-secure state, and therefore it is not necessary to update the partition ID every time there is a change in exception levels or security state.

[0040] Also, while in most cases control information such as the partition ID and any associated configuration information specified in a partition ID register 100 associated with a given operating state are set in response to an instruction executing at a higher exception level than the exception level associated with that partition ID register 100, in some cases it may be desirable for code executing in a given operating state to set its own partition ID in the corresponding partition ID register. Control flags may be set in the MPAM control register 68 to control which exception levels can write to a given partition ID register 100 and / or to control whether a write to a given partition ID register 100 from a given exception level will trigger a trap to a higher exception level, which may then be able to determine whether to perform the write requested by a lower exception level. Thus, an attempt to set the partition ID register 100 from within the same exception state when not permitted by the higher exception state may cause an exception event that triggers a switch to that higher exception state. An exception handler in the higher exception state can determine how to set the partition ID.

[0041] In general, when a memory transaction is generated by processing circuitry 6, one of the partition ID registers 100 is selected based on the current operating state as specified above. If the memory transaction is to access an instruction, the transaction is tagged with a partition ID derived from the PARTID_I field of the selected partition ID register. In some examples, a page table walk memory transaction triggered by a TLB 72 miss for an instruction access will use the same partition ID as the instruction access. However, other embodiments may allow an instruction-side page table walk memory transaction to specify a different partition ID for the instruction access itself, as described below with respect to Figures 16-18. If the memory transaction is to access data, the transaction is tagged with a partition ID derived from the PARTID_D field of the selected partition ID register 100 (a page table walk access triggered by the MMU after a data access may also use the same partition ID as the data access itself, or may specify a different partition ID for the data access, as described further below). Note that regardless of whether the MMU issuing the page table walk access itself supports resource / performance monitoring partitioning based on partition ID, it may still append an associated partition identifier to the corresponding memory transaction to allow memory system components in another part of the memory system to perform such partitioning. The PARTID_D and PARTID_I fields of a given partition ID register may be set to the same partition ID or different partition IDs.

[0042] It may be useful to allow separate partition IDs to be defined for data accesses and instruction accesses for the same software execution environment, allowing different resource control parameters to be used for the corresponding instruction and data accesses. An alternative approach is to have a single partition ID associated with the entire software execution environment, but append an additional bit of 0 or 1 depending on whether the access is for instructions or data, allowing the memory system components to select different control parameters for instruction and data accesses, respectively. However, for a given set of control parameters selected based on partition ID, this approach would mean that there must be a 50-50 split of the partition ID space between data and instructions. In practice, it is often desirable to have more data partitions than instruction partitions, since it may be relatively common for multiple software execution environments to run using the same code but with different data inputs, and thus it may be particularly useful to share a single instruction partition ID between multiple software execution environments, while allowing each environment to use a different data partition. The approach of appending a 0 or 1 bit to indicate the instruction for data access would, in that situation, require multiple sets of identical configuration information to be defined in the memory system components for each separate instance of the common code. In contrast, by providing separate instruction and data partition fields in the partition ID register 100 where the instruction and data partition IDs are selected from a common ID space, it is possible to reuse the same partition ID between different software execution environments and divide the partition ID space between data and instruction as needed, without limiting this to a 50 / 50 split.Although some additional storage capacity is required for the two partition ID fields in each partition ID register 100, this approach can conserve resources in the memory system components by sharing a single partition between instruction accesses of multiple execution environments, requiring a smaller set of control parameters (and therefore less storage capacity) in the memory system components.

[0043] In addition to providing a PARTID, the transaction is also tagged with a performance monitoring partition ID derived from the PMG_D or PMG_I field of the selected partition ID register 100 (the PMG field depends on whether the transaction is for a data access or an instruction fetch access). This allows memory system components to partition performance monitoring, for example, by using the performance monitoring ID of the memory transaction as part of the criteria for determining whether a particular performance monitor needs to be updated in response to a memory transaction. In one embodiment, the PMG_D or PMG_I field may be treated as being completely independent of the PARTID_D and PARTID_I fields. In this case, a memory system component implementing performance monitoring may determine whether a memory transaction causes an update of a given performance monitor depending only on the PMG_D or PMG_I identifier, independent of the PARTID_D or PARTID_I value specified for the same memory transaction. This nevertheless provides the advantage that different partitions for instruction / data accesses can share the same performance monitoring ID, which may support the collection of combined performance statistics for multiple processes requiring different instruction / data access configurations at a memory system component. Thus, by specifying a performance monitoring group ID separate from the partition ID used to control resource allocation in memory system components, a common set of performance counters can be used to track multiple different software execution environments even if resources are allocated separately.

[0044] Alternatively, another approach may be to interpret the PMG_D or PMG_I field as a suffix to be appended to the corresponding partition ID derived from the PARTID_D or PARTID_I field. In this approach, when a transaction is issued to memory, two IDs are appended to the transaction, one based on the selected PARTID_I or PARTID_D field and one based on the PMG field, but the PMG_I or PMG_D field is considered a characteristic of the PARTID and not an ID in itself. Thus, a memory system component may perform resource partitioning based on a first partition ID derived from PARTID_I or PARTID_D in this case, but may perform performance monitoring partitioning based on a combination of the first partition ID and a second partition ID derived from PMG_I or PMG_D. While this approach does not allow different memory resource partition IDs to share the same performance monitoring ID, an advantage is that a shorter PMG field can be used to save hardware costs since the instruction / data PMG field does not need to distinguish between all possible performance monitoring partitions, only partitions sharing the same instruction / data resource partition ID are distinguished by the instruction / data PMG field. For example, this can allow a 1 or 2 bit PMG field to be used rather than a larger field, which saves costs not only in the control registers 68 but also in the wires that carry memory transactions through the memory system. The above example can provide separate PMG suffix fields PMG_D and PMG_I corresponding to the PARTID_D and PARTID_I fields, respectively, to allow separate performance monitoring group properties to be defined for data accesses and instruction accesses, respectively; another approach could be to provide a single PMG field that is shared between data accesses and instruction accesses.

[0045] Either approach may benefit from the ability to define multiple performance monitoring partitions per data / instruction partition ID, while it will be appreciated that other examples may omit the separate performance monitoring ID field entirely and instead use the same partition ID to control both resource management and performance monitoring.

[0046] 7A is a flow diagram illustrating a method for controlling the issuance of data access memory transactions from a processing element, such as a CPU 6, GPU, or other master acting as a source of a memory transaction, and in particular, for controlling which partition ID is specified in the memory transaction. The approach illustrated in FIG. 7A may be used for data access memory transactions issued by at least load / store unit 50 (in the case of data side page table walk memory transactions triggered by such data access memory transactions, the selection of the MPAM register at step 112 may be handled differently, as described further below).

[0047] In step 110, the processing element issues a data access (load / store) memory access transaction, for example in response to a load / store instruction executed in the execution stage 48.

[0048] In step 112, the MPAM register selection logic 78 of the processing element selects one of the partition ID registers 100 depending on its current operating state 64 and the MPAM control information specified in the MPAM control register 68. Figure 8 shows generally an example of the MPAM register selection logic 78 selecting which partition ID register 100 should be used to generate the partition ID for the current memory transaction depending on at least the current exception level 64 and the following control parameters specified in the hypervisor control register MPAMHCR_EL 2 116: Parameter E2H 113, which is set to 1 for a Type 2 hypervisor running at EL2. When E2H is set to 1, instructions to access certain EL1 control registers return the corresponding EL2 version of the control register state, so that an unmodified operating system designed to run at EL1 can function as a Type 2 hypervisor running at EL2. ● Parameter TGE114, which, when TGE=1, indicates that types of exceptions that occur at EL0 that would normally be routed to EL1 (when TGE=0) should instead be routed to EL2, so that a type 2 hypervisor running at EL2 can manage applications at EL0 without involving the operating system at EL1. - Parameter GSTAPP_PLK 115 stored in MPAMHCR_EL2 116, which defines whether a process running at EL0 should use the MPAM0_EL1 partition ID or the MPAM1_EL1 partition ID.

[0049] The criteria for selecting register 100 to be the selected register are as follows: ●MPAM0_EL1 is selected if any of the following is true: ○Current exception level 64 is EL0, GSTAPP_PLK=0, or ○The current exception level 64 is EL0 and both E2H=1 and TGE=1.

[0050] Therefore, MPAM0_EL1 is selected if EL0&&((E2H&&TGE)||!GSTAPP_PLK).

[0051] ●MPAM1_EL1 is selected if any of the following is true: ○The current exception level 64 is EL1. or ○The current exception level 64 is EL0 and GSTAPP_PLK=1, and at least one of E2H and TGE=0.

[0052] Therefore, MPAM1_EL1 is selected if EL1&&(EL0&&GSTAPP_PLK&&!(E2H&&TGE)). ●If the current exception level 64 is EL2, MPAM2_EL2 is selected. ●If the current exception level 64 is EL3, MPAM 3_EL3 is selected. Providing the GSTAPP_PLK configuration parameter is optional, and on systems that do not support this feature, MPAM0_EL1 will be selected if the current exception level is EL0 instead of MPAM1_EL1. Similarly, support for Type 2 hypervisors may be optional, so other implementations may not have E2H / TGE control.

[0053] Also, in the embodiment described above having a separate secure partition ID register MPAM1_EL1_S, the selection also depends on the current security state, with register MPAM1_EL1_S being selected when processing at EL0 or EL1 in the secure domain, otherwise the selection is as described above.

[0054] In step 118 , since the current transaction is a data access transaction, the PMG_D and PARTID_D fields are read from the register 100 selected in step 112 .

[0055] In step 120, the processing element determines whether virtualization is implemented and enabled for the read partition ID in the current operating state. For EL2 and EL3, virtualization does not need to be performed. For EL0 and EL1, whether virtualization is enabled depends on the information specified in the hypervisor control register MPAMHCR_EL2 116, which includes virtualization enable flags EL0_VPMEN and EL1_VPMEN, specifying whether virtualization is enabled for EL0 and EL1, respectively. If virtualization is enabled for EL0 and the MPAM0_EL1 register was selected in step 112, or if virtualization is enabled for EL1 and the MPAM1_EL1 register was selected in step 112, in step 122, at least one of the partition IDs read in steps 116 or 118 is mapped to a physical partition ID attached to the memory transaction issued to the memory system. Otherwise, step 122 is omitted.

[0056] An example of partition ID virtualization mapping is shown in FIG. 9. The global partition ID space may be controlled by the hypervisor in EL2. In this example, virtualization is applied only to PARTID (memory resource partition ID), but not to PMG (performance monitoring partition ID). However, other embodiments may also provide virtualization of performance monitoring partition ID, for example.

[0057] The hypervisor may restrict guest operating systems running at EL1 to use only a narrow range of partition IDs (e.g., starting from zero), and the mapping registers 126 define a mapping table that provides several mapping entries for mapping the virtual partition IDs used by that guest operating system to physical partition IDs in the global ID space. Each mapping register may store mapping entries for one or more virtual IDs (depending on the relative size of the register compared to the width of a single partition ID). The mapping table is indexed based on the virtual partition ID used by the operating system and returns the corresponding physical partition ID to the global ID space. This allows each guest operating system to set its own application's ID without being aware of the fact that it is virtualized and running alongside other guest operating systems that may be using similar ID values. Each guest operating system may have their conflicting virtual IDs mapped to different global physical partition IDs by the mappings set in the mapping table by the hypervisor.

[0058] 9 illustrates an example of the partition virtualization logic 79 shown in FIG. 3, which is invoked when the current exception level is EL0 or EL1. The partition from the selected partition ID register 100 (selected by the register selection logic 78 as discussed above) is the virtual partition ID and is used to select the corresponding mapping entry from the mapping registers 126. In this example, each mapping register 126 contains four mapping entries, so two bits of the virtual partition ID select a particular mapping entry in the mapping registers 126, and the remaining bits select which mapping register 126 is selected. However, other examples may have a different number of entries per register. The physical partition ID is read from the selected mapping entry and provided to a multiplexer 132, which selects between the original virtual partition ID read from the selected partition ID register 100 and the corresponding remapped physical partition ID depending on the virtualization enable parameter EL0_VPMEN (if the selected register 100 was MPAM0_EL1) or EL1_VPMEN (if the selected register 100 was MPAM1_EL1). If virtualization is not enabled, the original virtual partition ID is output as the physical PARTID, if virtualization is enabled, the physical partition ID from mapping register 126 is used.

[0059] Each mapping entry is associated with a corresponding valid bit in the mapping valid register MPAMVPMV_EL 2124. The valid bit of a given mapping entry specifies whether its virtual-to-physical partition ID mapping is valid. When a processing element issues a memory transaction that specifies an invalid virtual partition ID, this may trigger the mapping logic to select an alternative valid partition ID instead. Thus, the hypervisor does not need to assign virtual-to-physical partition ID mappings for all possible virtual PARTIDs. Upon receiving an invalid virtual partition ID, the mapping circuitry may simply use an "on error" value of the physical partition ID, which is passed along with the corresponding memory request to the memory system component and treated as a valid partition ID. The predetermined physical partition ID may be a particular "default" value of the partition ID, e.g., the same default partition ID used for software execution environments where no special partition ID is assigned. For example, the predetermined physical partition ID may be zero. Alternatively, a control register (PARTID_ON_ERROR) may define a particular value of the physical partition ID to be used as the predetermined physical partition ID in the event of an error. An alternative approach would be to trap to the hypervisor at EL2 when an invalid virtual partition ID is received, but this may have a larger performance impact.

[0060] 6 shows an example in which the valid bit is stored in a register 124 separate from the mapping register 126, in other embodiments, each mapping entry may itself include a valid bit, which is then stored in the mapping register 126 along with the corresponding physical partition ID. In this case, the remapping valid register 124 may be omitted. Thus, in general, each mapping entry may be associated with a valid bit, although where the valid bit is stored may vary depending on implementation choice.

[0061] For simplicity, Figure 7A shows a sequential process with step 122 as a conditional step, but in practice, as shown in Figure 9, a physical partition ID may be calculated for each memory transaction, and both remapped and non-remapped versions of the partition ID may be provided to multiplexer 132, which selects between them based on associated enablement parameters. This may be faster than waiting to determine whether virtualization is enabled before looking up the physical partition ID.

[0062] FIG. 10 is a flow diagram showing step 122 in more detail. In step 140, it is determined whether the virtual partition ID being remapped is out of range. For example, the hypervisor control register 116 or another MPAM control register 68 (e.g., a discovery register MPAMIDR_EL1 142 that allows software to identify what capabilities are provided in the hardware) may specify the maximum ID value that can be specified in the current context. For example, the hypervisor may define a mappable range of partition IDs that may be used by the operating system running under it, based on, for example, how many mapping registers 126 are provided in the hardware. If the partition ID being remapped (i.e., the ID read from the register selected in step 112 of FIG. 7A) is out of range, in step 144 a valid virtual PART ID is selected to be used instead, and the method proceeds to step 149, described below. Which particular virtual PART ID is used may be arbitrary (e.g., the lowest valid PART ID).

[0063] If the virtual partition ID is within the permitted range, then in step 145 it is determined whether the corresponding mapping entry is valid, for example based on the corresponding valid bit in mapping valid register 124. If the virtual partition ID is valid, then the method proceeds to step 149, described below. If the virtual partition ID is not valid, then in step 146 virtual PARTID0 is selected (i.e. virtual PARTID equal to the numeric value of 0). In step 147 it is checked whether virtual PARTID0 is valid, and if so, the method continues to step 149. If virtual PARTID0 is invalid, then in step 148 physical PARTID0 (physical PARTID with all bits equal to 0) is used as the physical PARTID to be attached to the memory transaction.

[0064] In step 149 (which may follow any of steps 144, 145 or 147), the selected virtual PARTID is mapped to a physical ID specified in the mapping entry corresponding to the virtual PARTID, and the resulting physical PARTID is used to tag the memory transaction.

[0065] In another example, it is possible to proceed directly from step 145 to step 148 if the received virtual PARTID is invalid.

[0066] 11, PARTID_I and PARTID_D are specified separately in the partition ID register 100, but the mapping circuit 130 can use a common mapping table 126 for both types of IDs, thus eliminating the need for separate sets of mapping registers 126, 128 for instruction and data access.

[0067] In summary, by providing mapping hardware (mapping registers 126 and mapping circuitry 79) to map a smaller space of virtual IDs onto physical IDs in the global ID space used by memory system components, multiple guest operating systems can coexist while using conflicting partition IDs, improving performance because each memory transaction does not have to trap to the hypervisor to map a partition ID.

[0068] In step 150 of Figure 7A, not only is a memory transaction issued specifying the PMG and PARTID (either in the original form read from the selected partition ID register or after mapping in step 122), but a secure state indication indicates which security state the transaction was issued from. The secure state indication is included so that the partition IDs assigned to the secure domain can use a completely separate partition ID space from the partition IDs assigned to less secure domains (rather than assigning several partition IDs to secure processes from a single ID space, a non-secure process may be able to infer information about a provided secure process). A complete separation of the secure and less secure worlds can improve security. The security indication provided with the transaction indicates from which security state the transaction was issued.

[0069] This security indication may be provided separately from an address-based security indication that indicates whether the target address of the transaction is secure or non-secure. That is, regions of the memory address space may be designated as secure or non-secure, with the secure regions being accessible only from the secure domain, while the non-secure regions are accessible by both the secure and non-secure domains. If the memory system includes further control structures, such as a system MMU, that control access depending on whether the address is in the secure or non-secure region, such an address-based security indication may be included in the transaction. However, this address-based security indication is not sufficient to identify whether the process that issued the transaction is secure or non-secure, since the secure domain can access both the non-secure and secure regions of the address space. Thus, a memory transaction may separately identify both the domain from which the transaction was issued (MPAM_NS) and the security state (NS) associated with the target address.

[0070] [Table 3]

[0071] Upon receiving a memory transaction, a memory system component can use the MPAM_NS security indication to select between different parameter sets for each of the secure and non-secure domains, thereby avoiding sharing control parameters between domains, which could pose a security risk if non-secure code were to set performance control parameters or access performance monitoring data of secure code.

[0072] Figure 7B is a flow diagram illustrating a method for controlling the issuance of instruction fetch access memory transactions from a processing element such as a CPU 6, GPU, or other master, and in particular a method for controlling which partition ID is specified in the memory transaction. The approach illustrated in Figure 7B can be used for at least instruction fetch memory transactions issued by fetch stage 40. In the case of instruction side page table walk memory transactions triggered by such instruction fetch memory transactions, the selection of the MPAM register in step 112 can be handled differently, as described further below.

[0073] 7B, the processing circuitry issues an instruction fetch memory transaction to request the fetching of an instruction for a given address. The instruction fetch request may be made by the fetch stage 40 when the instruction actually needs to be fetched for execution, or some implementations may have prefetch circuitry that prefetches instructions into the instruction cache 10 ahead of the time the instruction is actually needed for execution, so that the prefetch circuitry may also generate the instruction fetch memory transaction.

[0074] Step 112 in FIG. 7B is the same as that shown in FIG. 7A for data access, and selects one of the MPAM Partition ID Registers 100 based on the current operating conditions (and other control parameters) as described above.

[0075] In step 116 of FIG. 7B, the PMG_I and PARTID_I fields of the selected partition ID register 100 are read.

[0076] Steps 120, 122 and 150 of FIG. 7B are the same as the corresponding steps of FIG. 7A, except that they are applied to the PMG_I / PARTID_I values ​​read in step 116 instead of the PMG_D and PARTID_D values.

[0077] Returning to Figure 6, discovery register MPAMIDR_EL1 142 identifies various capability parameters that identify the hardware capabilities of the corresponding processing element (PE). This allows software to query what MPAM resources are provided in a particular hardware implementation, allowing the same code to run on multiple different hardware platforms. For example, discovery register 142 may specify whether a particular MPAM feature is provided (e.g., virtualization, or separate secure / non-secure ID spaces), or what size resource is provided (e.g., number of bits in a partition ID, or number of mapping registers 126). For example, discovery register 142 may specify: ● PARTID_MAX: the maximum partition ID supported by the hardware implementation of the PE; • HAS_HCR: whether virtualization functionality is provided (and thus whether the hypervisor control register 116, the remapping enable register 124, the mapping register 126, and the mapping circuit 79 are provided); ● VPMR_MAX: The maximum virtual partition ID supported by the hardware implementation of the PE when virtualization is performed; ● PMG_MAX: The maximum PMG value supported by the hardware implementation of the PE.

[0078] The discovery register 142 may be readable from any exception state other than EL0, but is read-only and cannot be written since the discovery register 142 defines parameters that are specific to a particular hardware implementation. For example, the discovery register 142 may be hardwired during manufacture of the device.

[0079] If virtualization is supported, it may be desirable to prevent an operating system at EL1 from directly reading discovery register 142, since the actual value of PARTID_MAX may be larger than the range of partition IDs that the hypervisor has allowed the operating system to use. Thus, an instruction executed at EL1 that attempts to access discovery register 142 (or at least an attempt to access the PARTID_MAX field, which defines the maximum partition ID allowed to be specified in a memory transaction) may trigger an exception that traps to the hypervisor, which can provide another value (e.g., VPMR_MAX) instead of the maximum value to emulate the number of partition IDs visible to the operating system. The configuration parameter TRAP_MPAMIDR_EL1 can control whether such accesses to discovery register 142 from EL1 are trapped to EL2. By setting this configuration parameter, the hypervisor at EL2 or the secure monitor at EL3 can control whether a guest OS at EL1 can directly access discovery register (IDR) 142 or whether the hypervisor must step in. For example, when virtualization is disabled, providing the flexibility to choose whether IDR accesses trap to EL2 can be useful to improve performance when it is appropriate for the OS to access the IDR directly by avoiding unnecessary traps to EL2.

[0080] Although virtualization is described above in the context of EL2 setting up a virtual to physical ID mapping for use by EL1 or EL0, in general, this technique may be used for any pair of software execution environments of different privilege levels, such that the higher privilege level environment can control the mapping of virtual partition IDs to physical partition IDs for transactions issued by the lower privilege software execution environment. Also, unless otherwise specified, the techniques described above for partition IDs may also be used in some embodiments for performance monitoring groups, although this is not required. Thus, the term partition identifier may be interpreted to include performance monitoring group identifiers, unless otherwise specified.

[0081] The partition ID and performance monitor group attached to a given memory transaction, as well as a security state indication that specifies the security state under which the transaction was issued, flow with the memory transaction throughout the memory system. Thus, a node (e.g., an interconnect) of the memory system that passes a memory transaction to other components of the memory system provides an external memory transaction with the same partition ID, performance monitor group, and security state indication as the corresponding request received at such node. In the case of caches within the memory system, they have the behavior that they may generate a response to the request on a cache hit, and may pass it on to another part of the memory system on a cache miss. They may also allocate new entries based on the request. When allocating a new entry, the cache may store the partition ID, performance monitor group, and security indication of the request that caused the allocation along with the cached data itself. When the data is written back to a further cache or memory, a write-back transaction is generated specifying the partition ID, performance monitor group, and security indication associated with the evicted data in the cache, rather than the ID associated with the request that triggered the eviction. This allows resource allocation or performance monitoring for write-back to be controlled / monitored according to parameters specific to the software execution environment that allocated the corresponding data to the cache.

[0082] 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 may control resource allocation or monitor performance in a manner that is common to all software execution environments. Nonetheless, external requests are still appended with a partition ID in the same manner as discussed above, so that downstream memory system components that support partitioning can use the partition ID to select an appropriate set of parameters. Thus, regardless of whether a system designer actually chooses to use partition IDs in any given memory system component, the processing element architecture and partition ID routing scheme described above provide flexibility to support a range of implementations that implement partitioning at various locations in the memory system. However, for those memory system components that respond to partition IDs or performance monitoring group IDs, they can control resource allocation or contention management, or performance monitoring, based on the partition ID.

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

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

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

[0086] If the memory system component supports performance monitor partitioning by performance monitor group (step 208), then in step 210, each performance monitor implemented in the component tests the request against its filter parameters (which may include tests applied to the PMG field and the partition ID field). Each monitor that satisfies the filter parameters updates its internal state according to the measurement, count, or calculation that the monitor is designed to perform. For memory system components that do not support performance monitor partitioning, step 210 is omitted. As explained above, in some embodiments, both the partition ID field and the PMG field may be included in the filter parameters (so that the PMG field further restricts the partition ID field). Alternatively, the PMG may be interpreted as an independent ID separate from the partition ID field, in which case the filter parameters may take into account the PMG but not the partition ID.

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

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

[0089] The cache 300 has a cache storage (cache RAM) 302 for storing cached information. The cache RAM 302 has a certain number of storage entries 304. As shown in Figure 13, each entry can store: • Cached data 306 (this can be any cached information - including not only data values ​​but also instructions or address translation data depending on the type of cache); • A valid bit 308 that specifies whether the corresponding data in the entry is valid; • A tag field 310 indicating the portion of the address associated with the cached data; ● Partition ID 314 of the memory transaction that allocated data to the cache; ● Performance monitoring group ID 316 for allocated memory transactions; • A security state indication 318 of the allocation memory transaction (indicating from which security state the memory transaction was issued); • Any other information that the system design may need to maintain per cache line, e.g., coherence state and Address Space Indicator (ASI). When data is evicted from the cache, the ID fields 314, 316, 318 are used to derive the partition ID, performance monitoring group ID, and security state indication for the writeback transaction. Although not shown in Figure 13, each cache entry may also contain coherency information that specifies the coherency state of the cached data (e.g., whether the data is clean or dirty to determine whether a writeback is required) and / or victim selection data (e.g., data to track which entry was most recently used) to select a victim cache line in the event that an eviction is required.

[0090] Allocation of data into the cache can be controlled according to any known cache organization, including direct mapping, set associative, or fully associative. The example of FIG. 13 shows four set associative organization schemes, but it should be understood that this is only one example. Lookups into the cache are performed regardless of the partition ID associated with the corresponding memory transaction. Thus, when a memory transaction is received that specifies a given partition ID, the transaction can hit against any data in the indexed cache entry, regardless of the partition ID 314, non-secure ID indicator 318, and performance monitoring group 316 stored in the cache entry. Thus, partitioning of performance resources and / or performance monitoring does not interfere with various software processes sharing access to the cached data.

[0091] On the other hand, when allocating data to the cache, the cache controller 312 controls the allocation according to a set of resource control parameters selected based on the security state and partition ID of the corresponding memory transaction. The cache has a set of resource control parameter registers 320 as described above, with each register 320 storing resource control parameters for a corresponding software execution environment. A selector 322 selects one of the registers based on the partition ID and security state of the incoming memory transaction that requires allocation of data to the cache. The parameters stored in the selected register are used to control whether and how the data is allocated to the cache.

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

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

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

[0095] The resource control parameter register 320 may represent the maximum number of entries indicated by the maximum capacity threshold in a variety of ways. For example, the maximum number of entries that may be allocated to the corresponding partition ID data may be specified directly. Alternatively, the threshold may be specified in terms of a portion of the total cache capacity that may be allocated to that partition ID. For example, the parameter may represent a scaled percentage where the parameter width and scale factor are specified in the corresponding memory component ID register 362. For example, if a component supports 8-bit capacity control scaled by 256, then to allocate 30% of the capacity to a particular partition, the partition's maximum capacity parameter may be 30. * 256=76.8, which is rounded down to 76 so that the allocation does not exceed the desired percentage.

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

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

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

[0099] As shown at the top of FIG. 15, by setting different bitmaps 350 for different partition IDs, some portions of the cache can be reserved for a given partition ID, while other portions may be shared between partition IDs or not allocated at all. For example, in the subset of four cache portions shown in FIG. 15 (this is not the entire cache capacity), portion 0 of the cache is assigned only to partition 1, portion 1 is assigned to both partition 1 and partition 2, and thus may compete for allocation to this portion of the cache, portion 2 is assigned only to partition 2, and portion 3 is assigned to none of these partitions. Thus, when allocating data to the cache for partition 1, the cache controller 312 is limited to selecting locations in portions 0 or 1, but not portions 2 or 3. The "portions" defined by the bitmaps can be any group of one or more cache entries with the property that any given address can be assigned to at least one entry of the group, for example, an entire way in a set-associative cache (including all sets belonging to that way), or a subset of any more entries in a fully associative cache.

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

[0101] 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 mode). Other implementations may support the option of using both modes. For example, this may be useful when the particular cache organization being used does not support providing many portions (e.g., a relatively less associative set-associative cache), as overlaying a maximum capacity limit provides more control than portion division alone.

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

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

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

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

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

[0107] Similar to resource control partitioning, performance monitors in cache 300 may be partitioned based on performance monitor group (and partition ID in embodiments where PMG is a sub-property of partition ID) and security state. There may be several performance monitors 380, each configurable to measure, count, or calculate performance metrics based on filters programmed into a set of filter parameters 382 corresponding to that performance monitor 380. The filter parameters 382 may include fields to specify a PARTID and a PMG, and upon receiving a memory transaction, if the filter parameters 382 set a particular value for the PARTID / PMG field, the performance monitor may decide whether to update its metrics based on that transaction depending on whether the PARTID / PMG values ​​associated with that transaction match the values ​​set in the filter parameters 382. It should be noted that in implementations supporting a first cache allocation mode in which allocation counters 326 are provided to track whether an allocation threshold has been exceeded, the same allocation counters 326 may also be used for performance monitoring.

[0108] If cache 300 is an address translation cache, such as a TLB or page walk cache, dividing cache allocation resources in this manner may help to ensure that one software execution environment is not allocated more than its allocated percentage / part of the address translation cache capacity, thereby reserving space for other software execution environments and mitigating the "noisy neighbour" effect.

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

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

[0111] Memory Channel Bandwidth Division The bandwidth of the main memory channel may be divided. Two bandwidth control schemes may be provided. The memory channel may optionally implement one or both of the following: The minimum bandwidth a partition requires, even if there is contention The maximum bandwidth limit available to a partition when there is contention Any combination of these control methods may be used simultaneously on channels that support them, and each control method is described in the following sections.

[0112] Minimum Bandwidth Control Method The minimum bandwidth control scheme places requests from a partition priority when the current bandwidth falls below a minimum, and allows the request to compete with other regular requests when the minimum bandwidth is exceeded. Requests below the partition's minimum bandwidth are most likely to be scheduled on the channel. The minimum bandwidth control scheme tracks memory bandwidth during the accounting period. If the partition's tracked bandwidth usage during the accounting period is currently below the partition's minimum, then the request is preferentially selected to use channel bandwidth. If the partition's bandwidth usage tracked during the accounting period currently exceeds the partition's minimum, then the request will compete with other normal priority requests for the channel's bandwidth. Bandwidth not used by a partition during the accounting window does not accumulate. Registers in the memory system component can specify the minimum bandwidth limit for a given partition ID as scaled megabytes per second. The scaled value for megabytes per second is calculated as the target megabytes per second multiplied by a scale factor that may be defined in hardware.

[0113] Maximum Bandwidth Limit Control Method The maximum bandwidth limit control scheme gives a partition normal priority during an accounting period up to its maximum bandwidth limit. If a partition's bandwidth usage tracked during an accounting period is currently below the partition's maximum, its request competes for scheduling on the memory channel at normal priority. If a partition's bandwidth usage tracked during an accounting period is currently above the partition's maximum bandwidth limit, its request competes with other lower priority requests for bandwidth on the channel.

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

[0115] Again, the control parameter for the maximum bandwidth limit may be specified as scaled megabytes per second: the scaled value for megabytes per second is calculated as the target megabytes per second multiplied by a possibly hardware-defined scale factor.

[0116] When both minimum and maximum bandwidth limit control methods are implemented, the following table shows the priority of requests:

[0117] [Table 4]

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

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

[0120] In fixed window accounting, bandwidth is allocated to requests such that each partition gets bandwidth according to its partition's minimum and maximum values. Request or local priority can be used to resolve competing requests for bandwidth. When the accounting window duration is reached, a new window begins with no history, except for a queue of requests that have never been serviced before. The new window starts accumulating bandwidth from zero for each partition.

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

[0122] The minimum bandwidth allocation for all partitions can potentially result in more bandwidth than is available. This is not an issue if some partitions have unused bandwidth allocations, because the unused allocations are made available for other partitions. However, if the minimum bandwidth is over-allocated, the minimum bandwidth programmed for a partition may not always be met. To ensure that the programmed minimum bandwidth allocation can be reliably delivered by the system, software can ensure that the minimum bandwidth is not over-allocated.

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

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

[0125] Priority Split Unlike other memory system resources described in this document, priorities do not directly affect the allocation of memory system resources, but rather the contention that occurs for access to the resource. A properly configured system rarely experiences a significant performance impact due to prioritization, but priorities do play an important role in oversubscription situations, whether immediate or sustained. Thus, "priority partitioning" can be used as a tool to help isolate memory system impacts between partitions.

[0126] Partitions may be assigned priorities at each component in the memory system that supports priority partitioning. This partitioning control allows different parts of the memory system to be configured to handle requests with different priorities. For example, requests from the processor to the system cache may be configured to use a higher transfer priority than requests from the system cache to main memory.

[0127] Two types of priority can be identified for each partition ID. ● Internal priorities control the priorities used in internal operations of this memory system component. They can be used within the memory system component to prioritize internal operations. For example, a memory controller can use internal priorities to select between waiting requests when bandwidth allocation does not pick a clear winner. ● Downstream priority controls the priority communicated downstream to other memory system components (e.g., interconnect or memory controller). "Downstream" refers to the direction of communication for a request. An "upstream" response typically uses the same transfer priority as the request that generated it. Memory system components use downstream priority to indicate priority to downstream components that do not have a priority division. This can be used to set transfer priority in downstream interconnect components.

[0128] On the other hand, if a component does not implement priority splitting or does not implement downstream priorities, then a "through priority" can be used, where the downstream priority is the same as the incoming (upstream) priority or request. Similarly, a response passing through a memory system component (from downstream to upstream) has the same priority as the response received (from downstream).

[0129] Controlling partition identifiers for page table walk memory transactions The following example describes a technique for allowing a page table walk memory transaction to be assigned a different partition ID to the data or instruction access memory transaction that triggered the page table walk. As shown in FIG. 3, when the processing pipeline requests an instruction fetch or load / store operation, the virtual address specified for the instruction fetch or data access is passed to the MMU 70, which handles the address translation. The address translation can be a one-stage address translation where the virtual address (VA) is translated directly to a physical address (PA), or it can be a two-stage address translation where the virtual address is translated to an intermediate physical address (IPA) and then the intermediate address is translated to a physical address. If the MMU 70 has already cached page table information in its TLB 72, 73, 74 or page walk cache 75 that can be used to obtain the translated address (IPA or PA) from the VA, it only needs to issue a data or instruction access that specifies the selected physical address and partition ID as described above. However, if the page table data required to translate the virtual address is not already cached in the MMU 70, at least one page table walk (PTW) memory transaction can be issued to the memory system to request that the page table data be returned. In some cases, traversing the hierarchical page table structure may require several memory transactions as part of the page table walk operation performed to locate the relevant page table data.

[0130] One approach could be for PTW memory transactions to simply be assigned the same partition identifier as the corresponding data / instruction (D / I) access memory transactions. However, this can result in inefficient resource usage and potential unfairness between different software execution environments that share access to the same page table data.

[0131] For example, in one usage model, an operating system provider may define page table data to be shared among several applications running under that operating system. Partition-based resource constraints may be set with the intent of allocating roughly equal amounts of resources in the memory system to each application. However, if one of the applications is executed first and encounters a large number of misses in the address translation caches 72, 74 in the MMU, that first executing application may have to issue a relatively large number of PTW memory transactions. If the PTW memory transactions are tagged with the same partition ID as the D / I accesses, this will consume some of the memory resources allocated to that application. When a context switch is performed to another application running under the same operating system, the second application may benefit from any caching of page table data in the MMU 70 or data cache 8 that was executed using the resources allocated to the first executing application, so that the later executing application may not have to consume as much of its resource partition as the first application. This allows the second application to effectively see a higher level of performance than the first application, which may be undesirable in some cases.

[0132] Thus, the following embodiments provide techniques that allow PTW memory transactions to assign different partition IDs to corresponding D / I memory transactions. For example, this may allow a partition ID associated with an operating system to be assigned to PTW memory transactions issued by applications that run at a lower privilege level under the control of the operating system. Similarly, when multiple operating systems are managed by a shared hypervisor using the operating systems' shared page table data, a partition ID associated with the hypervisor may be specified for PTW memory transactions issued by the operating systems or their underlying applications separately from the partition IDs assigned to D / I accesses triggered by those operating systems or applications.

[0133] Thus, by allowing a different partition ID to be assigned to PTW memory transactions compared to D / I accesses, performance and fairness of resource partitioning may be improved. Thus, as shown in FIG. 3, MPAM generation logic 77 may output D / I page table walk specific MPAM related information that may differ from the MPAM related information used for the corresponding D / I access. For PTW memory transactions issued by page table walk unit 76, multiplexer 390 may select between data PTW MPAM information and instruction PTW MPAM information depending on whether the PTW memory transaction was triggered by a data access or an instruction fetch.

[0134] However, it is recognized that not all use cases may benefit from PTW memory transactions that specify different partition IDs for D / I accesses. Also, there are valid use cases where it may be desirable for a PTW memory transaction to specify the same partition ID as the corresponding D / I access. For example, in different programming models, an operating system may assign different page table structures to each application that runs therein, in which case, since there is no sharing of page table data between applications, it may make more sense for any memory resources consumed by a PTW memory transaction from a given application to be obtained from the resource allocation assigned to that particular application, rather than from the operating system's resource allocation.

[0135] Thus, in some embodiments, it may be useful for the processing circuitry to select whether to assign different or the same partition identifiers to the PTW memory transaction and the corresponding D / I access memory transaction based on programmable information that is programmable in response to instructions from at least one of the software execution environments. The setting of the programmable information may be controlled by instructions from at least one software execution environment that executes at a privilege level other than the at least privileged privilege level. Various examples of the programmable information are described below. In some cases, the programmable information may simply be a second partition ID field for the PTW memory transaction that may be set to the same partition ID as the partition ID field used for the D / I access, or may be set to a different partition ID. However, for backward compatibility reasons and ease of programming, it may be preferable to have some other control state that can control whether the partition ID should be assigned differently to the page table walk, apart from the fields that actually provide the partition ID itself for the D / I access and the PTW, respectively.

[0136] PTW specific MPAM information register Figure 16 shows a first example of an architecture technique for enabling specification of different partition IDs for PTW memory transactions. In this example, the number of partition ID registers 100 is expanded compared to the above example to include several additional registers. The partition ID registers still include the four registers shown in brackets 100 in Figure 6, which are used to provide a partition identifier for a D / I access memory transaction, with the associated register selected as described above when the D / I access transaction is issued.

[0137] In addition to these registers, however, registers 100 also include four page table walk partition identifier registers 400 that are used to provide the partition identifier to be used for a PTW memory transaction. Several PTW partition ID registers 400 are provided, with the particular register to be used being selected based on the current exception level when the PTW memory transaction is issued and which stage of address translation (stage 1 or stage 2) is being requested. This is discussed in more detail below.

[0138] 16, each of the PTW partition ID registers 400 specifies a separate partition ID for data accesses and instruction accesses, and a separate performance monitoring group ID for data accesses and instruction accesses, similar to the partition ID register 100 described above. Additionally, the page table walk partition ID registers 400 specify an enable field 402 that controls whether the PTW memory transaction uses the partition ID recorded in the PTW partition ID register 400, or whether the PTW memory transaction should use the partition ID specified in one of the other partition ID registers 100 selected for the data / instruction access transaction in the current execution state.

[0139] Therefore, several system registers 400 are provided to hold the MPAM state for use in the table walk stage. Software can choose to load each register with a different PARTID than that in any of the MPAMn_ELx registers 100, or with one or both of MPAM3_EL3.PARTID_{I,D}, MPAM2_EL2.PARTID_{I,D}, MPAM1_EL1.PARTID_{I,D}, or MPAM0_EL1.PARTID_{I,D}.

[0140] In one example, given the hierarchy of software execution environments supported by the architecture as shown in FIG. 4, the MMU may support the following stages of address translation: ● Secure EL3 stage 1, which is used to translate the Virtual Address (VA) of a transaction issued in Secure EL3 to a Physical Address (PA). ● Secure EL1&0 stage 1, used to convert VA to PA for transactions issued at secure EL1 or secure EL0. Non-secure EL2 stage 1, used to convert the VA to PA for transactions issued in non-secure EL2. Non-secure EL2&0 stage 1, used by some hypervisors to convert VAs issued at non-secure EL2 or non-secure EL0 to PAs when operating in a mode where the virtual memory configuration associated with EL0 is managed at EL2 rather than EL1. Non-secure EL1&0 stage 1, used to translate the VA of transactions issued at non-secure EL1 or non-secure EL0 to an intermediate physical address (IPA). • Non-secure EL1&0 stage 2, used to convert IPA from non-secure EL1&0 stage 1 to PA. If we collapse the two security states together, the count drops from 6 to 5. Also, EL2 Stage 1 and EL2&0 Stage 1 can be combined, since they cannot be used at the same time, reducing the count to 4: EL3 Stage 1 ●EL2 Stage 1 or EL2&0 Stage 1 ●EL1&0 Stage 2 ●EL1&0 Stage 1 Thus, the MPAM register may include four additional PTW partition ID registers 400 as follows: ●MPAMPTWS1_EL3: Used for EL3 stage 1 ●MPAMPTWS1_EL2: Used for EL2 stage 1 and EL2&0 stage 1 ●MPAMPTWS2_EL2: Used for EL1&0 stage 2 ●MPAMPTWS1_EL1: Used for EL1&0 stage 1 Here, the notation MPAMPTWSa_ELb indicates that a register is used in stage a of address translation, and that the lowest privilege state in which the contents of the register can be rewritten is ELb. All four of these registers have the same fields as shown in FIG.

[0141] [Table 5]

[0142] In summary, using the approach shown in Figure 16, the partition identifier registers that specify respective partition identifiers for different operating states can be supplemented with additional page table walk partition identifier registers. When a memory transaction is issued, the processing circuitry selects a partition identifier stored in the selected partition identifier register and assigns a partition identifier to the memory transaction depending on the selected partition identifier. Note that since virtualization of partition identifiers can still be supported as described above, at least for accesses initiated from EL0 or EL1, the memory transaction can be assigned a partition identifier value that can be different from that specified in the selected partition identifier register. The selected partition identifier can depend on the current privilege level at which the memory transaction is issued.

[0143] Thus, at least one page table walk partition identifier register may be selected as the selected partition identifier register that provides a selected partition identifier to use for the page table walk memory transaction. The processing circuit may support several stages of address translation, each stage of the address translation being based on a respective page table structure, and which partition identifier register is the selected partition identifier register for the page table walk memory transaction may depend on the stage of the address translation associated with the page table walk memory transaction. Different execution environments that manage the respective page table structures of different stages of the address translation may have different requirements for control of resource partitioning, which is why it may be useful to provide different partition identifiers for each stage of the address translation. Alternatively, several stages of the address translation may share the same partition identifier register, in which case it may be necessary to reprogram the register when switching execution contexts.

[0144] In some implementations, the enable field 402 above may not be necessary, and one approach could be for PTW memory transactions to always use a partition ID from one of the page table walk registers 400, rather than the normal partition ID register 100 used for D / I accesses. However, this could increase the programming load, as if a particular use case desires to assign the same partition ID to a PTW memory transaction as a D / I transaction, both registers would need to be written with the relevant partition ID. Also, for backward compatibility with code written for systems that do not have the additional page table walk partition ID register 400, new hardware implementations should operate like previous implementations until software supporting new hardware features enables those features. Therefore, providing an enable indication 402 can be useful. If not explicitly enabled by software, the system can reset the enable indication 402 to an invalid state, so that page table walk transactions use a partition ID selected from one of the other non-PTW partition ID registers 100.

[0145] Thus, for a given PTW memory transaction, the processing circuitry may determine whether the enable field of the corresponding PTW partition identifier register specifies a valid state or an invalid state. Which register is the corresponding PTW partition identifier register may depend on the current operating state (security state / privilege level) and stage of address translation at which the PTW memory transaction is issued, as described above. When the enable field indicates a valid state, the corresponding PTW partition identifier register itself may be used as the selected partition identifier register for the PTW memory transaction, and a partition ID may be selected from that register. On the other hand, when the enable field of the corresponding PTW partition identifier register indicates an invalid state, the selected partition ID register may be a partition ID register other than at least one PTW partition ID register 400. In particular, when the enable field of the corresponding partition ID register is in an invalid state, the selected partition ID register may be the same of the non-PTW partition ID register 100 that would have been selected if the data / instruction access memory transaction was issued from the current execution state.

[0146] It may be useful for the PTW partition ID registers to specify separate data and instruction partition IDs. This allows, for example, different applications or operating systems to share the same partition ID for instruction page table walks, but use different partition IDs for data page table walks. Thus, for PTW memory transactions corresponding to data access memory transactions, the selected partition ID may be based on the data partition identifier specified by the PARTID_D field of the selected partition ID register MPAMPTWSn_ELx, and for PTW memory transactions corresponding to instruction access memory transactions, the selected partition identifier may be the instruction partition identifier from the PARTID_I field of the selected partition ID register MPAMPTWSn_ELx.

[0147] Alternatively, other examples may choose not to provide separate instruction and data fields in the PTW partition ID register, but simply have the same partition ID used for both PTW memory transactions associated with data accesses and PTW memory transactions associated with instruction accesses.

[0148] Also, as in the general embodiment described above, FIG. 16 shows a separate performance monitoring group (PMG) compared to the PARTID used for resource control, other approaches may provide for the same partition ID to be used for both resource control and performance monitoring.

[0149] Configurable sources of MPAM information FIG. 17 illustrates a second example that allows a PTW memory transaction to use a different partition ID than the corresponding D / I memory transaction. In this example, rather than providing an additional partition ID register specifically for PTW transactions, the PTW memory transaction may share the same partition ID register used for D / I access memory transactions. However, as shown in FIG. 17, some additional control states 410-416 are provided in some of the partition ID registers 100 to redirect the PTW transaction from a given execution environment, if necessary, to use a partition identifier specified in one of the partition ID registers 100 other than the current execution environment.

[0150] This approach comes from the observation that exception levels beyond the current exception level already contain MPAM information associated with the software environment that executes at those levels. This means that no additional MPAM information needs to be stored in the CPU, and while this feature provides control to select which exception level to obtain MPAM information for during different kinds of translation table accesses, it does not even contain additional registers or register bits to hold MPAM partition IDs beyond what is already present in the general scheme above.

[0151] The MPAM information used depends on the current exception level and the stage of translation in use. A two-stage translation scheme uses two stages during the translation process, and the MPAM information used may need to be different for each stage. The source of MPAM information is controlled separately for each stage in the two-stage scheme.

[0152] Each MPAMn_ELx register gets one or two new fields that control the source of MPAM information for page table walks. There is one field (S1PTWSRCn) in each of the MPAM2_EL2 and MPAM1_EL1 registers. S1PTWSRCn is the source of MPAM information for a single stage page table walk performed by execution in ELn, or for the first stage of a two stage PTW. A second field (S2PTWSRCn) is in each of the MPAM2_EL2 and MPAM1_EL1 registers. The second field controls the source of MPAM information for a stage 2 PTW performed by execution in ELn. Each of these settings is basically as follows: Backwards compatibility (i.e. PTW transactions use the same partition information as the corresponding data / instruction accesses) Use MPAM information for execution ELn for PTW transactions ●Use the MPAM information of execution ELn+1 for the PTW transaction.

[0153] Therefore, new control fields are added to some of the MPAM Partition ID Registers 100. The register fields beginning with "S1PTW" control the source of MPAM information for the stage 1 page table walk, those beginning with "S2PTW" control the stage 2 page table walk. The last digit indicates the execution EL at which the setting is used.

[0154] As shown in FIG. 17, MPAM1_EL1 has the S1PTWSRC0 and S2PTWSCR0 fields added (4 bits), and MPAM2_EL2 has the S1PTWSRC1 and S2PTWSCR1 fields added (4 bits). S1PTWSRC0 (bits [51:50]): Stage 1 page table walk (hypervisor) source control for EL0 S1PTWSRC0 is a field 412 added to register MPAM1_EL1 that controls whether the MPAM0_EL1 or MPAM1_EL1 register is used as the source of the PARTID for the stage-1 page table walk. MPAM1_EL1.S1PTWSRC0 is not used if TGE=='1' (TGE is a flag in the Hypervisor Control Register (HCR) 116 that indicates that a type of exception that occurs at EL0 that would normally be routed to EL1 (if TGE=0) should instead be routed to EL2). S1PTWSRC0 412 can take the following values ​​(each represented as a 2-bit binary value):

[0155] [Table 6] S1PTWSRC1 (bits [51:50]): Stage 1 page table walk (hypervisor) source control for EL1 An additional field 416 is added to MPAM2_EL2. S1PTWSRC1 controls whether the MPAM1_EL1 or MPAM2_EL1 register is used as the source of the PARTID for stage 1 table walks caused by execution at EL1. S1PTWSRC1(bits[51:50])

[0156] [Table 7] S2PTWSRC0 (bits [53:52]): Stage 2 page table walk (hypervisor) source control for EL0 An additional field 410 is added to MPAM1_EL1 and is defined as follows: S2PTWSRC0 (bits[53:52]): Stage 2 page table walk source control

[0157] [Table 8] S2PTWSRC1 (bits [53:52]): Second-phase page table walk (hypervisor) source control for EL1 An additional field 414 is added to MPAM2_EL2 and is defined as follows: S2PTWSRC1 (bits [53:52]): Second-phase page table walk (hypervisor) source control for EL1

[0158] [Table 9]

[0159] Thus, in this approach for PTW memory transactions issued from the current privilege level, the processing circuitry may select a partition ID register associated with a privilege level of greater privilege than the current privilege level as the selected partition ID register used to generate a partition identifier for the PTW memory transaction. Although this may require slightly more complex selection logic to select which partition ID to use for a given memory transaction, less register storage space is required, and therefore the hardware cost of implementing support for different partition IDs for PTW memory transactions may be reduced.

[0160] The processing circuitry may select whether the selected partition ID register should be the partition ID register associated with the current privilege level or the partition ID register associated with a privilege level of greater privilege than the current privilege level based on programmable configuration information. This programmable configuration information may be programmable by instructions executed at a privilege level of greater privilege. Thus, for example, an operating system may set programmable states 410, 412 to control whether an application running therein uses its own partition ID register for PTW memory transactions or references a register used for D / I memory transactions within the operating system. Similarly, a hypervisor may use states 414, 416 to control which partition ID register 100 is selected for use by a stage 1 or stage 2 PTW transaction issued by the operating system at EL1.

[0161] 17, in some cases, there may be several programmable configuration information 410, 412, 414, 416, each associated with a different combination of privilege level, security state, and address translation stage. Thus, for a given PTW memory transaction, one of the items of programmable configuration information may be selected depending on at least one of the current privilege level, the current security state, and the current stage of address translation at which the PTW memory transaction is issued. Based on the selected item of programmable configuration information, the processing circuitry may select whether the selected partition ID register should be the one associated with the current privilege level or the partition ID register associated with a privilege level of greater privilege.

[0162] FIG. 17 shows a particular example of how these items of programmable configuration information 410-416 may be stored within the MPAM control registers 68, although it is possible to use a different layout of control states or to store the programmable configuration information 410-416 in registers separate from the partition ID register 100 itself.

[0163] FIG. 18 shows a flow diagram illustrating a method for processing partition ID assignment for a PTW memory transaction. In step 500, a PTW memory transaction is issued by the MMU 70. In step 502, the processing circuitry checks whether programmable information (which may be set to a privilege level of greater privilege than the current privilege level, for at least some privilege levels) indicates whether a PTW transaction for the current translation stage and privilege level should have a different partition ID than the corresponding data / instruction access memory transaction. This programmable information may be one of the fields 410-416 shown in FIG. 17 that directs the PTW transaction to the corresponding D / I instruction access to reference a different MPAN register 100, or may be, for example, the enable field 402 of a dedicated PTW partition ID register shown in FIG. 16.

[0164] If the programmable information selected for the current access is in an invalid state, indicating that the PTW transaction should be processed in the same manner as the D / I access memory transaction, the same partition ID as assigned to the corresponding D / I access memory transaction is assigned to the PTW memory transaction in step 504. For example, a partition ID register can be selected based on the current exception level and the GSTAPP_PLK field using the approach shown in Figure 8 as described above, and the associated one of the partition IDs (instruction or data) can be assigned to the PTW memory transaction.

[0165] However, if in step 502 it is determined that the programmable information indicates that the option to provide separate partition IDs for PTW transactions at the current privilege level and translation stage is enabled, then in step 506 a different partition ID is assigned to the PTW memory transaction compared to the corresponding D / I access memory transaction. For example, if the approach shown in Figure 16 is used, a dedicated PTW partition ID register can be referenced to obtain the partition ID value used (virtualized mapping of the value), or in the approach shown in Figure 17, a partition ID register of a privilege level other than the current privilege level can be referenced to obtain the partition ID used to derive the partition ID value to assign to the memory transaction.

[0166] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that can perform a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform a function. "Configured to" does not mean that the apparatus elements have to be modified in some way to provide the defined operation.

[0167] Although exemplary embodiments of the present 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 by those skilled in the art without departing from the scope and spirit of the present invention as defined by the appended claims.

Claims

1. An apparatus comprising: a processing circuit for processing instructions from one of a plurality of software execution environments; at least one memory system component for processing memory transactions issued by the processing circuitry in response to the instructions; Equipped with in response to a memory transaction issued by the processing circuit that specifies a partition identifier selected responsive to which software execution environment caused the memory transaction to be issued, the at least one memory system component is configured to: control allocation of resources for processing the memory transaction or manage contention for the resources responsive to a selected set of memory system component parameters selected responsive to the partition identifier specified by the memory transaction, or control whether performance monitoring data is updated responsive to the memory transaction responsive to the partition identifier specified by the memory transaction; An apparatus, wherein when a page table walk memory transaction is issued by the processing circuit to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the processing circuit can assign to the page table walk memory transaction a partition identifier that is different from the partition identifier assigned to the corresponding data / instruction access memory transaction.

2. The processing circuitry performs the programmable operation based on programmable information that is programmable in response to instructions from at least one of the plurality of software execution environments. assigning different partition identifiers to the page table walk memory transaction and the corresponding data / instruction access memory transaction; or Assign the same partition identifier to the page table walk memory transaction and the corresponding data / instruction access memory transaction The apparatus of claim 1 , configured to select:

3. 3. The apparatus of claim 2, wherein the programmable information is programmable in response to instructions from at least one software execution environment executing at a privilege level other than a least privileged privilege level.

4. A plurality of partition identifier registers, each for specifying a respective partition identifier. Equipped with 4. The apparatus of claim 2 or 3, wherein upon issuing a memory transaction, the processing circuitry is configured to select a partition identifier stored in a selected partition identifier register and assign a partition identifier to the memory transaction in response to the selected partition identifier stored in the selected partition identifier register.

5. 5. The apparatus of claim 4, wherein the processing circuitry is configured to execute instructions from one of a plurality of privilege levels and to select the selected partition identifier register based at least on a current privilege level at which the memory transaction was issued.

6. 6. The apparatus of claim 4, wherein the plurality of partition identifier registers includes at least one page table walk partition identifier register selectable as the selected partition identifier register to provide the selected partition identifier for use in a page table walk memory transaction.

7. The processing circuitry is configured to support multiple stages of address translation, each stage of address translation based on a respective page table structure: the plurality of partition identifier registers include a plurality of page table walk partition identifier registers, each of which is associated with at least one stage of address translation; 7. The apparatus of claim 6, wherein in the case of a page table walk memory transaction, the processing circuitry is configured to select which partition identifier register is the selected partition identifier register based on the stage of an address translation associated with the page table walk memory transaction.

8. Each page table walk partition identifier register includes an enable field that specifies one of a valid state and an invalid state; For a given page table walk memory transaction, the processing circuitry is configured to determine whether the enable field of a corresponding page table walk partition identifier register specifies the valid state or the invalid state; if the enable field of the corresponding page table walk partition identifier register indicates the valid state, the selected partition identifier register is the corresponding page table walk partition identifier register; 8. The apparatus of claim 6, wherein the selected partition identifier register is a partition identifier register other than the at least one page table walk partition identifier register if the enable field of the corresponding page table walk partition identifier register indicates the invalid state.

9. Each page table walk partition identifier register specifies a data partition identifier and an instruction partition identifier; when the selected partition identifier register is one of the at least one page table walk partition identifier register; For a page table walk memory transaction corresponding to a data access memory transaction, the processing circuitry is configured to select the data partition identifier specified by the selected partition identifier register as the selected partition identifier; 9. The apparatus of claim 6, wherein in the case of a page table walk memory transaction corresponding to an instruction access memory transaction, the processing circuitry is configured to select the instruction partition identifier specified by the selected partition identifier register as the selected partition identifier.

10. the processing circuitry is configured to execute instructions from one of a plurality of privilege levels; 10. The apparatus of claim 4, wherein for a page table walk memory transaction issued from a current privilege level, the processing circuitry is capable of selecting as the selected partition identifier register a partition identifier register associated with a privilege level of greater privilege than the current privilege level.

11. the processing circuitry is configured to execute instructions from one of a plurality of privilege levels; 11. The apparatus of claim 4, wherein, for a page table walk memory transaction issued from a current privilege level, the processing circuitry is configured to select, based on the programmable information, whether the selected partition identifier register is a partition identifier register associated with the current privilege level or a partition identifier register associated with a privilege level of greater privilege than the current privilege level.

12. 12. The apparatus of claim 11, wherein the programmable information is programmable by instructions executed at the greater privilege level.

13. the programmable information includes a plurality of items of programmable configuration information; For a page table walk memory transaction, the processing circuitry: the privilege level at which the page table walk memory transaction is issued; and a security state of the processing circuit to which the page table walk memory transaction is issued; and any one of a plurality of stages of address translation associated with the page table walk memory transaction, each stage of the address translation being based on a respective page table structure; configured to select one of the items of programmable configuration information in response to at least one of 13. The apparatus of claim 11 or 12, wherein the processing circuitry is configured to control, based on the selected item of programmable configuration information, whether the selected partition identifier register is a partition identifier register associated with the current privilege level or a partition identifier register associated with a privilege level of greater privilege than the current privilege level.

14. The at least one memory system component comprises: a cache configured to control allocation of data to the cache in response to the memory transactions according to the selected set of memory system component parameters; an interconnect or memory controller configured to control allocation of bandwidth or buffer occupancy for processing the memory transactions in response to the selected set of memory system component parameters; 14. The apparatus according to claim 1 , further comprising at least one of:

15. An apparatus comprising: means for processing instructions from one of a plurality of software execution environments; at least one means for processing memory transactions issued by said means for processing in response to said instructions; Equipped with in response to a memory transaction issued by the means for processing a designation of a partition identifier selected responsive to which software execution environment caused the memory transaction to be issued, the at least one means for processing a memory transaction is configured to: control allocation of resources for processing the memory transaction or manage contention for the resources responsive to a selected set of memory system component parameters selected responsive to the partition identifier specified by the memory transaction; or control whether performance monitoring data is updated responsive to the memory transaction responsive to the partition identifier specified by the memory transaction; An apparatus, wherein when a page table walk memory transaction is issued by the means for processing a request for access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the means for processing can assign to the page table walk memory transaction a partition identifier that is different from the partition identifier assigned to the corresponding data / instruction access memory transaction.

16. 1. A method comprising: Processing instructions from one of a plurality of software execution environments; Processing memory transactions issued in response to said instructions; Including, In response to a memory transaction specifying a partition identifier selected responsive to which software execution environment issued the memory transaction, at least one memory system component controls allocation of resources for processing the memory transaction or manages contention for the resources responsive to a selected set of memory system component parameters selected responsive to the partition identifier specified by the memory transaction, or controls whether performance monitoring data is updated responsive to the memory transaction responsive to the partition identifier specified by the memory transaction; A method, wherein when a page table walk memory transaction is issued to request access to page table data necessary to obtain a translated target address of a corresponding data / instruction access memory transaction, the partition identifier assigned to the page table walk memory transaction can be a different partition identifier than the partition identifier assigned to the corresponding data / instruction access memory transaction.

Images