Partition identifier used for page table walk memory transactions

Abstract

A memory transaction may be tagged with a partition identifier selected based on which software execution environment caused the memory transaction to be issued. A memory system component may control allocation of resources used to process the memory transaction or manage contention for the resources based on a set of memory system component parameters selected based on the partition identifier specified by the memory transaction, or may control whether performance monitoring data is updated in response to the memory transaction based 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 Art Technical Field

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

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

[0005] At least some examples provide an apparatus comprising: processing circuitry for processing an instruction 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 circuitry in response to the instruction; wherein: in response to the memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the at least one memory system component is configured to: control allocation of resources for processing the memory transaction or manage contention for the resources based on a selected set of memory system component parameters, the selected set of memory system component parameters being selected based on the partition identifier specified by the memory transaction; or control whether performance monitoring data is updated in response to the memory transaction based on the partition identifier specified by the memory transaction; and when the processing circuitry issues a page table walk memory transaction to request access to page table data required to obtain a translation target address of a corresponding data / instruction access memory transaction, the processing circuitry is capable of assigning 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.

[0006] At least some examples provide an apparatus comprising: a device for processing an instruction from one of a plurality of software execution environments; and at least one device for processing a memory transaction issued by the device for processing in response to the instruction; wherein: in response to the memory transaction issued by the device for processing specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the at least one device for processing the memory transaction is configured to: control allocation of resources for processing the memory transaction or manage contention for the resources based on a selected set of memory system component parameters, the selected set of memory system component parameters being selected based on the partition identifier specified by the memory transaction; or control whether performance monitoring data is updated in response to the memory transaction based on the partition identifier specified by the memory transaction; and when the device for processing issues a page table walk memory transaction to request access to page table data required to obtain a translation target address of a corresponding data / instruction access memory transaction, the device for processing is capable of assigning 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.

[0007] At least some examples provide a method comprising: processing an instruction from one of a plurality of software execution environments; and processing a memory transaction issued in response to the instruction; wherein: in response to the memory transaction specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, at least one memory system component controls allocation of resources for processing the memory transaction or manages contention for the resources based on a selected set of memory system component parameters, the selected set of memory system component parameters being selected based on the partition identifier specified by the memory transaction; or controls whether performance monitoring data is updated in response to the memory transaction based on the partition identifier specified by the memory transaction; and when a page table walk memory transaction is issued to request access to page table data required to obtain a translation target address of a corresponding data / instruction access memory transaction, allowing the partition identifier assigned to the page table walk memory transaction to be a partition identifier different from the partition identifier assigned to the corresponding data / instruction access memory transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 2 schematically illustrates an example of partitioning control of memory system resources based on partition identifiers assigned to software execution environments associated with memory transactions;

[0010] Figure 3schematically illustrates an example of processing circuitry for issuing a memory transaction specifying a partition identifier;

[0011] Figure 4 shows examples of different software execution environments executed by processing circuitry;

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

[0013] Figure 6 shows an example of a control register for controlling which partition identifier is specified for a given memory transaction;

[0014] Figure 7A is a flow chart illustrating a method of issuing a data access memory transaction from a master device;

[0015] Figure 7B is a flow chart illustrating a method for obtaining memory transactions from a master device by issuing instructions;

[0016] Figure 8 schematically illustrates selection of a partition identifier register according to a current operating state of the processing circuitry;

[0017] Figure 9 An example of mapping virtual partition identifiers to physical partition identifiers is schematically shown;

[0018] Figure 10 is a flow chart illustrating a method of mapping a virtual partition identifier to a physical partition identifier;

[0019] Figure 11 schematically illustrates an example of generating separate partition identifiers for instruction and data memory transactions;

[0020] Figure 12 is a flow chart illustrating a method of responding to a memory transaction at a memory system component;

[0021] Figure 13 An example of a cache that controls allocation of cache resources based on a partition identifier and / or updates performance monitoring data selected based on the partition identifier is shown;

[0022] Figure 14 is a flow chart illustrating a method of controlling allocation to a cache according to a capacity threshold selected based on a partition identifier;

[0023] Figure 15 An example of controlling which portions of a cache may be allocated with data based on a partition identifier is shown;

[0024] Figure 16A first example of providing a plurality of partition identifier registers dedicated to page table walk memory transactions is shown;

[0025] Figure 17 An alternative example is shown in which configuration information is provided for controlling whether a page table walk transaction uses a partition identifier in a partition identifier register associated with a current privilege level or a higher privilege level; and

[0026] Figure 18 A method of controlling which partition identifier is used for a page table walk memory transaction is shown. DETAILED DESCRIPTION

[0027] An apparatus may include processing circuitry for processing instructions from one of a plurality of software execution environments, and at least one memory system component for processing memory transactions issued by the processing circuitry in response to the instructions. The memory transactions may be assigned to a partition identifier selected based on which software execution environment caused the memory transaction to be issued. The at least one memory system component may use the partition identifier to control resource allocation or contention management based 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 transactions.

[0028] Thus, the processing circuitry can present the partition identifier as a tag for a memory transaction, depending on the software issuing the transaction. This means that resources in the memory system can be distributed among the software execution environments to prevent one software execution environment from acquiring more than its fair share of resources, thereby resolving the "noisy neighbor" problem described above.

[0029] However, the inventors have recognized that not all memory transactions issued when executing a given software execution environment can access information related to that environment. As discussed in more detail below, for a page table walk memory transaction issued to request access to page table data required to obtain the translation target address of a corresponding data / instruction access memory transaction, that data can sometimes be managed by a software execution environment executing at a higher privilege level than the execution environment that issued the page table data or instruction access memory transaction. If any memory resources consumed by the page table walk memory transaction are consumed as part of the resource allocation for the lower privilege execution environment that issued the page table walk request, this may deduct resources that could be used for other memory transactions issued by the software execution environment, which may provide an unfair imbalance between the relative amounts of memory resources allocated to different software execution environments. For example, this may result in the first of two or more software execution environments sharing access to common page table data consuming some of its resources because it is the first to access the page table data, and then other execution environments using the same page table data may have greater resources because their data / instruction access memory transactions are able to use page table data that has been cached in response to the first software execution environment, so that the software execution environments can have substantially equal resource allocations and can actually end up with an imbalance in performance.

[0030] Therefore, some embodiments are discussed below that enable processing circuitry to assign a partition identifier to a page table walk memory transaction that is different from the partition identifier assigned to the corresponding data / instruction access memory transaction. This can enable resource partitioning to more accurately correspond to the manner in which page table data is managed for different software execution environments, thereby providing a fairer resource partitioning.

[0031] Before discussing the control of partition identifiers used for page table walk memory transactions, a general architecture for setting partition identifiers for software execution environments and using these partition identifiers to control resource allocation or management or performance monitoring in a memory system is first described. Having described this general architecture, features of controlling page table walk memory transactions are discussed below in the section entitled "Controlling Partition Identifiers Used for Page Table Walk Memory Transactions."

[0032] Common architecture for memory resource partitioning and performance monitoring

[0033] Figure 1An example of a data processing system 2 is schematically shown that includes N processing clusters 4 (N is 1 or more), each of which includes one or more processing units 6, such as CPUs (central processing units) or GPUs (graphics processing units). Each processing unit 6 may have at least one cache, such as a level 1 data cache 8, a level 1 instruction cache 10, and a shared level 2 cache 12. It should be understood that this is only one example of a possible cache hierarchy and that other cache arrangements may be used. Processing units 6 within the same cluster are coupled by a cluster interconnect 14. The cluster interconnect may have a cluster cache 16 for caching data that can be accessed by any processing unit.

[0034] 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 by any host connected to it. The SoC interconnect 18 controls the coherence between the respective caches 8, 10, 12, 16, 20 according to any known coherence protocol. The SoC interconnect is also coupled to one or more memory controllers 24, each of which is used to control access to a corresponding memory 25 (such as DRAM or SRAM). The SoC interconnect 18 can also direct transactions to other slave devices, such as a cryptographic unit for providing encryption / decryption functions.

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

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

[0037] When multiple software execution environments executing on 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, thereby preventing the other execution environments from perceiving a performance loss. 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 that interact with a given amount of memory capacity, thereby improving the utilization of data center servers. However, web application tail latency targets still need to be met, and it is undesirable if one process running on the server can monopolize memory system resources to the point of being detrimental to other processes. Similarly, for networking applications, it is increasingly common to combine multiple functions that were previously on separate SoCs onto a single SoC. This again leads to a desire to limit performance interactions between software execution environments, and monitoring how these software execution environments require allowing those independent processes access to shared memory while limiting performance interactions.

[0038] Figure 2 An example of dividing control over allocation of memory system resources according to the software execution environment that issues the corresponding memory transaction is schematically shown. In this context, a software execution environment can be any process or part of a process executed by a processing unit within a data processing system. For example, a software execution environment can include an application, a guest operating system or virtual machine, a host operating system or hypervisor, a security monitor program for managing different security states of the system, or sub-parts of any of these types of processes (e.g., a single virtual machine can have different parts that are considered to be separate software execution environments). Figure 2 As shown, each software execution environment may be assigned a given partition identifier 30, which is passed to the memory system component along with memory transactions associated with the software execution environment.

[0039] Within a memory system component, resource allocation or contention resolution operations may be controlled based on one of a plurality of memory system component parameter groups selected according to a partition identifier. Figure 2As shown, each software execution environment may be assigned an allocation threshold representing a maximum amount of cache capacity that may be allocated for data / instructions associated with the software execution environment, wherein the relevant allocation threshold when servicing a given transaction is selected based on a partition identifier associated with the transaction. Figure 2 In

[0064] , transactions associated with partition identifier 0 may allocate data to at most 50% of the cache's storage capacity, leaving at least 50% of the cache available for other purposes.

[0040] Similarly, in memory system components (such as memory controller 24) that have a limited amount of bandwidth available for servicing memory transactions, minimum and / or maximum bandwidth thresholds may be specified for each partition identifier. If, within a given time period, memory transactions specifying a given partition identifier have used less than the minimum amount of bandwidth, then memory transactions associated with that partition identifier may be prioritized, whereas if the maximum bandwidth has been used or has been exceeded for memory transactions specifying the same partition identifier, then a reduced priority may be used for that transaction.

[0041] These control mechanisms are discussed in more detail below. It should be understood that these are merely two examples of how control of memory system resources can be partitioned based on the software execution environment that issues the corresponding transactions. Generally, by allowing different processes to "see" different partitions of the resources provided by the memory system, this allows performance interactions between processes to be limited, helping to address the issues discussed above.

[0042] Similarly, partition identifiers associated with memory transactions can be used for partition performance monitoring within a memory system, allowing a separate set of performance monitoring data to be tracked for each partition identifier, allowing identification of information specific to a given software execution environment (or group of software execution environments), making it easier to identify sources of potential performance interactions than when performance monitoring data is recorded for all software execution environments as a whole. This can also help diagnose potential performance interaction effects and help identify possible solutions.

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

[0044] Figure 3 An example of a processing unit 6 is shown in greater detail. The processor includes a processing pipeline comprising a plurality of 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, which includes an issue queue 46 for queuing instructions while waiting for their operands to become available and issuing the instructions for execution when the operands become available; an execution stage 48, which includes a plurality of execution units 50 for executing different classes of instructions to perform corresponding processing operations; and a write-back stage 52 for writing the results of the processing operations to data registers 54. Source operands for data processing operations can be read from registers 54 by the execution stage 48. In this example, the 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 to load data from a memory system into registers 54 or store data from registers 54 to the memory system. It will be appreciated that these are only some examples of possible execution units, and that other types may be provided. Similarly, other examples may have different configurations of pipeline stages. For example, in an out-of-order processor, an additional register renaming stage may be provided that is used to remap architectural register qualifiers specified by instructions to physical register qualifiers identifying registers 54 provided in the hardware, and a reorder buffer for tracking the execution and commit of instructions that are executed in an order different from the order in which they were fetched from cache 10. Similarly, another embodiment may be provided. Figure 1 Other mechanisms not shown in the figure, for example, may provide a branch prediction function at the fetch stage to control the generation of the next fetch address 61 based on the prediction result of the branch instruction.

[0045] The processor 6 has a plurality of control registers 60 including, for example, a program counter register 62 for storing a program counter indicating the current execution point of the program being executed; an exception level register 64 for storing an indication of the current exception level at which the processor is executing instructions; a security state register 66 for storing an indication of whether the processor is in a non-secure state or a secure state; and a memory partitioning and monitoring (MPAM) control register 68 (discussed in more detail below) for controlling memory system resources and performance monitoring partitioning. It will be appreciated that other types of control registers may also be provided. The program counter register 62 is Figure 3 4 as being maintained by the fetch stage 40 , but this register may also be accessed by other stages, such as the execute stage 48 .

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

[0047] In addition to TLBs 72, 73, and 74, the MMU may also include other types of caches, such as a page walk cache 75, which is used to cache data for mapping data 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. TLBs 72, 73, and 74 may cache subsets of these page table entries for multiple recently accessed pages. If the processor issues a memory transaction to a page that does not have corresponding address mapping data stored in TLBs 72, 73, and 74, a page table walk unit 76 initiates a page table walk. This can be relatively slow because it may have to traverse multiple levels of page tables in memory to identify the address mapping entry for the desired page. To speed up page table walks, recently accessed page table entries may be placed in page walk cache 75. These entries are typically page table entries other than the final level of page table entries, which actually specify the mapping for the desired page. These higher-level page table entries typically specify where in memory to find other page table entries for the corresponding address range. Page table walks for other addresses that share the same initial portion of a page table walk may be performed more quickly by caching at least some levels of the page table that were traversed in a previous page table walk in the page walk cache 75. Alternatively, rather than caching the page table entries themselves, the page walk cache 75 may cache the addresses at which these page table entries may be found in memory, thus also allowing access to a given page table entry more quickly than having to identify these addresses by first accessing other page table entries in memory.

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

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

[0050] In this example, the system also supports a partition between the secure domain 90 and the normal (less secure) domain 92. Sensitive data or instructions can be protected by assigning them to memory addresses marked as accessible only by the secure domain 90, where the processor has a hardware mechanism for ensuring that processes executing 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 alternatively, a completely separate secure memory management unit can be used to control the secure state partition, where separate secure and non-secure MMUs 70 are provided for sub-control within the respective secure states. Transitions between the secure domain 90 and the normal domain 92 can be managed by a secure monitor process 94 executing at the highest privilege level EL3. This allows for tight control over transitions between domains to prevent, for example, non-secure operations 80 or the operating system 82 from accessing data from the secure domain. In other examples, hardware techniques can be used to implement a separation between secure states and polled transitions, so that code in the normal domain 92 can directly transition to code in the secure domain 90 without transitioning through a separate secure monitor process 94. However, for ease of explanation, the subsequent description below will refer to an example that does use a secure monitor process 94 at EL3. Within the secure domain 90, the secure world operating system 96 executes at exception level EL1, and one or more trusted applications 98 can execute at exception level EL0 under the control of the operating system 96. In this example, there is no exception level EL2 in the secure domain 90 because virtualization is not supported in this secure domain, but virtualization can still be provided if desired. An example of an architecture for supporting such a secure domain 90 can be the one provided by Cambridge, England. Limited architecture. However, it will be appreciated that other techniques may be used. Some examples may have more than two security states, providing three or more states with different levels of security associated with them. The security state register 66 indicates whether the current domain is a secure domain 90 or a non-secure domain 92, and this indicates to the MMU 70 or other control unit which access permissions are used to control whether certain data can be accessed or operations are allowed.

[0051] therefore, Figure 4 A plurality of different software execution environments 80, 82, 84, 94, 96, 98 are shown 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, separate portions of a single process (e.g., different functions or subroutines) may be treated as separate execution environments and assigned separate partition IDs. For example, Figure 5 An example is shown in which virtual machine VM 3 and two applications 3741 and 3974 executing thereunder are all assigned PARTID 1, a specific process 3974 executing under a second virtual machine VM 7 is assigned PARTID 2, and VM 7 itself and another process 1473 running thereunder are assigned PARTID 0. It is not necessary to assign a custom partition ID to each software execution environment. A default partition ID can be specified to be used for software execution environments that are not assigned a partition ID. Control over which portions of the partition ID space are allocated to each software execution environment is performed by software with a higher privilege level, such as a hypervisor running at EL2 controlling the allocation of partitions to virtual machine operating systems running at EL1. However, in some cases, the hypervisor may allow an operating system at a lower privilege level to set its own partition ID for portions of its own code or for applications running thereunder. Furthermore, in some examples, secure world 90 may have a partition ID space completely separate from normal world 92, with this partition ID space controlled by the secure world OS or monitor EL3.

[0052] like Figure 3 As shown, the CPU may include MPAM generation logic 77 for generating MPAM related information to be associated with a given memory access transaction. The MPAM related information may include at least a PARTID, but in some examples may also include other information. The MPAM generation logic 77 may include MPAM register selection logic 78, which is used to select between the partition ID registers of the MPAM control registers 68 to determine which register should be used to generate the MPAM related information, and partition ID virtualization logic 79, which is used to control the mapping of virtual partition IDs to physical partition IDs. Figure 8 and 9The MPAM register selection logic 78 and the partition ID virtualization logic 79 are discussed in more detail. The MPAM generation logic 77 generates a plurality of alternative MPAM related information, including instruction MPAM related information (I-MPAM) to be used for instruction fetch access, data MPAM related information (D-MPAM) to be used for data access, instruction page table walk MPAM related information (I-PTW-MPAM) to be used for page table walk access triggered by instruction fetch, and data page table walk MPAM related information (D-PTW-MPAM) to be used for data page table walk MPAM related information. Figures 16 and 17 The selection of I-PTW-MPAM and D-PTW-MPAM is discussed in more detail.

[0053] Figure 6 An example of the MPAM control registers 68 is shown. The MPAM control registers 68 include a plurality of partition ID registers 100 (also referred to 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, namely MPAMVPM0_EL2 through MPAMVPM7_EL2, but it should be understood that other implementations may provide a different number.

[0054] In this example, the partition ID register 100 includes registers MPAM0_EL1 to MPAM3_EL3, which correspond to the respective exception levels EL0 to EL3. In this example, the partition ID register 100 can be shared between the secure world and the non-secure world for a given exception level, but 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 for the same exception level in the non-secure world.

[0055] Each partition ID register 100 includes fields for up to three partition IDs, as shown in Table 1 below:

[0056] Table 1 :

[0057]

[0058]

[0059] Table 2 below summarizes which partition ID register 100 is used for memory transactions performed in each operating state, and from which operating states each partition ID register 100 is controlled (ie, which operating state can update the information specified by that register):

[0060] Table 2 :

[0061]

[0062] The naming convention for the partition ID registers, MPAMx_Ely, indicates that the partition ID specified in the partition ID register MPAMx_ELy is used for memory transactions issued by processing circuit 6 when in operating state ELx, and that state ELy is the lowest exception level at which the partition ID register MPAMx_ELy can be accessed. However, when the current exception level in the non-secure domain is EL0, MPAM0_EL1 can be overridden, and the partition ID in MPAM1_EL1 is used when the configuration value GSTAPP_PLK set in the control register (MPAMHCR_EL2 116, described later) is set to 1. Therefore, control over EL1 can override control over EL0 when necessary. This can be used to constrain all applications running under a particular virtual machine to use the same partition ID, avoiding the need to update MPAM0_EL1 each time a context switch occurs between applications within the same virtual machine. Although the configuration parameter GSTAPP_PLK is described in this example as being stored in the MPAMHCR_EL2 116 control register, it can also be stored in other MPAM control registers 68 (e.g., the partition ID register corresponding to the higher exception level for which the configuration parameter is set).

[0063] Typically, when switching between different processes executing in the same state (e.g., different applications at EL0 or different guest operating systems at EL1), an exception event triggers a switch to a higher exception state, where the process running in that state (e.g., an operating system at EL1 or a hypervisor at EL2) then updates the partition ID in the relevant partition ID register 100 and then returns 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, which is saved and restored as part of the processor architectural state when switching from or to that process.

[0064] However, by providing multiple partition ID registers 100 corresponding to different operating states of the system, it is not necessary to update the contents of a single partition ID register every time the operating state changes other than a context switch, such as when an operating system (OS) temporarily traps into a hypervisor to cause the hypervisor to perform some actions and then return to the same OS. Such traps into a hypervisor can be quite common in virtualized systems, for example, if the hypervisor must intervene to provide the OS with a different view of physical resources than is actually provided in the hardware. Therefore, by providing multiple partition ID registers 100, marking memory system transactions with partition IDs will automatically follow changes in exception level or secure / non-secure state, resulting in faster performance because the partition ID does not need to be updated every time a change in exception level or security state occurs.

[0065] Moreover, while most of the time control information (such as the partition ID and any associated configuration information, which is specified in the partition ID register 100 associated with a given operating state) will be set in response to instructions executed at an exception level higher than the exception level associated with the partition ID register 100, it is sometimes desirable for code executed in a given operating state to set its own partition ID in the corresponding partition ID register. A control flag may be provided 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 triggers a trap to a higher exception level, which can then determine whether to implement the write requested by the lower exception level. Therefore, attempting to set the partition ID register 100 in the same exception state when the higher exception state does not allow it may result in an exception event that triggers a switch to the higher exception state. The exception handler in the higher exception state can then decide how to set the partition ID.

[0066] Typically, when processing circuitry 6 generates a memory transaction, one of partition ID registers 100 is selected based on the current operating state as specified above. If the memory transaction is for accessing 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 miss in TLB 72 for an instruction access will use the same partition ID as the instruction access. However, other embodiments may enable instruction-side page table walk memory transactions to specify a different partition ID than the instruction access itself, as described below with respect to Figures 16 to 18As discussed. If the memory transaction is to access data, the transaction is marked with a partition ID derived from the PARTID_D field of the selected partition ID register 100 (and similarly, any page table walk access triggered by the MMU following a data access may use the same partition ID as the data access itself, or may specify a different partition ID than the data access, as further described below). Note that regardless of whether the MMU issuing the page table walk access itself supports partition ID-based resource / performance monitoring partitioning, it may still append the relevant partition identifier to the corresponding memory transaction to allow a memory system component 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 to different partition IDs.

[0067] It may be useful to allow separate partition IDs to be defined for data and instruction accesses for the same software execution environment, so that different resource control parameters can be used for corresponding instruction and data accesses. An alternative approach is to have a single partition ID associated with the software execution environment as a whole, but to append an additional bit of either 0 or 1 depending on whether the access is for instructions or data, and this would allow the memory system component to select different control parameters for instruction accesses and data accesses respectively. However, for a given number of control parameter groups selected based on the partition ID, this approach would mean that there would be a 50-50 split of the partition ID space between data and instructions. In implementation, it may be generally desirable to have more data partitions than instruction partitions, as it may be relatively common for multiple software execution environments to use the same code but execute with different data inputs, and therefore it may be particularly useful to be able to share a single instruction partition ID across multiple software execution environments, while allowing each of those environments to use different data partitions. In this case, an approach that appends a 0 or 1 bit to indicate either an instruction access or a data access would require defining multiple sets of identical configuration information at the memory system component for each separate instance of that common code. In contrast, by providing separate instruction and data partition fields in partition ID register 100, where the instruction and data partition IDs are selected from a common ID space, the same partition ID can be reused between different software execution environments, and the partition ID space can be divided between data and instructions as needed without constraining the division to a 50-50 split. Even though the two partition ID fields in each partition ID register 100 may require some additional storage capacity, this approach can save resources at the memory system component because fewer control parameter sets (and therefore less storage) are required at the memory system component by sharing one partition between instruction accesses by multiple execution environments.

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

[0069] Alternatively, another approach could 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. With 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 the other based on the PMG_I or PMG_D field, but the PMG_I or PMG_D field is treated as a characteristic of the PARTID rather than as an ID in itself. Therefore, in this case, a memory system component can perform resource partitioning based on the first partition ID derived from PARTID_I or PARTID_D, but perform performance monitoring partitioning based on the combination of the first and second partition IDs derived from PMG_I or PMG_D. With this approach, different memory resource partition IDs can no longer share the same performance monitoring ID, but the advantage is that shorter PMG fields can be used, saving hardware cost, because the instruction / data PMG field does not need to distinguish among all possible performance monitoring partitions; the instruction / data PMG field only distinguishes between partitions that share the same instruction / data resource partition ID. For example, this may allow the use of a 1-bit or 2-bit PMG field instead of a larger field, which not only saves the cost of control register 68, but also saves wires to carry memory transactions through the memory system. While the above example provides 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 attributes to be defined for data accesses and instruction accesses, respectively, another approach may be to provide a single PMG field that is shared between data accesses and instruction accesses.

[0070] In any case, the ability to define multiple performance monitoring partitions for each data / instruction partition ID can be useful.On the other hand, it should be understood that other examples can completely omit the separate performance monitoring ID field and instead use the same partition ID to control both resource management and performance monitoring.

[0071] Figure 7A is a flow chart illustrating a method of controlling the issuance of a data access memory transaction from a processing element (such as the CPU 6, GPU, or other master device acting as a memory transaction source), and in particular, controlling which partition ID is specified with the memory transaction. Figure 7A The method shown in can be used at least for data access memory transactions issued by the load / store unit 50 (for data-side page table walk memory transactions triggered by such data access memory transactions, the selection of the MPAM register at step 112 can be handled in different ways, as further discussed below).

[0072] At step 110 , the processing element issues a data access (load / store) memory access transaction, eg, in response to a load / store instruction executed at execute stage 48 .

[0073] At step 112 , the MPAM register selection logic 78 of the processing element selects one of the partition ID registers 100 based on its current operating state 64 and the MPAM control information specified in the MPAM control register 68 . Figure 8 An example is schematically shown 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 based on at least the current exception level 64 and the following control parameters specified in the hypervisor control register MPAMHCR_EL2 116:

[0074] Parameter E2H 113, which is set to 1 for a Type 2 hypervisor operating at EL2. When E2H is set to 1, instructions that access certain EL1 control registers return the corresponding EL2 version of the control register state, allowing an unmodified operating system designed for operation at EL1 to be used as a Type 2 hypervisor operating at EL2.

[0075] Parameter TGE 114, which, when TGE=1, indicates that exception types generated at EL0 that would normally be routed to EL1 (if TGE=0) should instead be routed to EL2, so that a Type 2 hypervisor operating at EL2 can manage applications at EL0 without the need for an intermediate operating system at EL1; and

[0076] Parameter GSTAPP_PLK 115 stored in MPAMHCR_EL2 116, which defines whether a process operating at EL0 should use the MPAM0_EL1 partition ID or the MPAM1_EL1 partition ID

[0077] The criteria for selecting which register 100 is the selected register are as follows:

[0078] MPAM0_EL1 is selected if any of the following is true:

[0079] οCurrent exception level 64-bit EL0, and GSTAPP_PLK=0;

[0080] or

[0081] o If the current exception level is 64-bit EL0, and E2H=1 and TGE=1.

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

[0083] Select MPAM1_EL1 if any of the following is true:

[0084] ο The current exception level 64 is EL1;

[0085] or

[0086] o The current exception level 64 is EL0, and GSTAPP_PLK=1, and at least one of E2H and TGE=0.

[0087] So if EL1&&(EL0&&GSTAPP_PLK&&!(E2H&&TGE)), then MPAM1_EL1 is selected.

[0088] If the current exception level 64 is EL2, MPAM2_EL2 is selected.

[0089] If the current exception level 64 is EL3, MPAM3_EL3 is selected.

[0090] The provision of the GSTAPP_PLK configuration parameter is optional, and on systems that do not support this feature, MPAM0_EL1 is selected instead of MPAM1_EL1 when the current exception level is EL0. Similarly, support for type 2 hypervisors may be optional, so other implementations may not have E2H / TGE control.

[0091] Furthermore, in the above embodiment with a separate security partition ID register MPAM1_EL1_S, the selection will also depend on the current security state, where register MPAM1_EL1_S is selected when processing at EL0 or EL1 in the secure domain, otherwise selected as listed above.

[0092] At step 118 , because the current transaction is a data access transaction, the PMG_D and PARTID_D fields are read from the register 100 selected at step 112 .

[0093] At 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 information specified in the hypervisor control register MPAMHCR_EL2 116, which includes virtualization enable flags EL0_VPMEN and EL1_VPMEN, respectively, specifying whether virtualization is enabled for EL0 and EL1. If virtualization is enabled for EL0 and the MPAM0_EL1 register is selected at step 112, or if virtualization is enabled for EL1 and the MPAM1_EL1 register is selected at step 112, then at step 122, at least one of the partition IDs read at steps 116 or 118 is mapped to a physical partition ID attached to the memory transaction to be issued to the memory system. Otherwise, step 122 is omitted.

[0094] Figure 9 An example of virtualized mapping of partition IDs is shown in FIG. The global partition ID space can be controlled by a hypervisor at EL2. In this example, virtualization only applies to PARTIDs (memory resource partition IDs) and not to PMGs (performance monitoring partition IDs). However, other embodiments can also provide virtualization for, for example, performance monitoring partition IDs.

[0095] The hypervisor can restrict the guest operating system executing at EL1 to use only a small range of partition IDs (e.g., starting from zero), and the mapping register 126 defines a mapping table that provides multiple mapping entries for mapping the virtual partition IDs used by the guest operating system to physical partition IDs within the global ID space. Each mapping register can 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 in the global ID space. This enables each guest operating system to set an ID for its own application without being aware of the fact that it is virtualized and is executing simultaneously with other guest operating systems that may use similar ID values. The corresponding guest operating system can map its conflicting virtual IDs to different global physical partition IDs by setting the mapping in the mapping table by the hypervisor.

[0096] Figure 9 Shown Figure 3, which is invoked when the current exception level is EL0 or EL1. The PARTID from the selected partition ID register 100 (selected by register select logic 78, as discussed above) is the virtual partition ID and is used to select the corresponding mapping entry from the mapping register 126. In this example, each mapping register 126 includes four mapping entries, so two bits of the virtual partition ID select a specific mapping entry within the mapping register 126, and the remaining bits select which mapping register 126 to select. 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 based on the virtualization enable parameter EL0_VPMEN (if the selected register 100 is MPAM0_EL1) or EL1_VPMEN (if the selected register 100 is MPAM1_EL1). When virtualization is not enabled, the original virtual partition ID is output as the physical PARTID, whereas when virtualization is enabled, the physical partition ID from the mapping register 126 is used.

[0097] Each mapping entry is associated with a corresponding valid bit in the mapping valid register MPAMVPMV_EL2 124. The valid bit for a given mapping entry specifies whether the virtual-to-physical partition ID mapping is valid. When a processing element issues a memory transaction specifying an invalid virtual partition ID, this can trigger the mapping logic to select an alternative valid partition ID. Thus, the hypervisor does not have to assign virtual-to-physical partition ID mappings for all possible virtual PARTIDs. When an invalid virtual partition ID is received, the mapping circuitry can simply use an "error occurred" value for the physical partition ID, which is passed to the memory system component along with the corresponding memory request and treated as a valid partition ID. The predetermined physical partition ID can be a "default" value for the partition ID, such as the same default partition ID used for software execution environments that do not have a custom partition ID assigned to them. For example, the predetermined physical partition ID can be zero. Alternatively, a control register (PARTID_ON_ERROR) can define a specific value for the physical partition ID that is used as the predetermined physical partition ID in the event of an error. Another approach is to trap to the hypervisor at EL2 upon receiving an invalid virtual partition ID, but this may have a greater impact on performance.

[0098] Although Figure 6An example is shown where the valid bit is stored in register 124 separate from map register 126, but in other implementations, each map entry may itself include a valid bit, such that the valid bit is stored concurrently with the corresponding physical partition ID in map register 126. In such a case, remapping valid register 124 may be omitted. Thus, in general, each map entry may be associated with a valid bit, but the location where the valid bit is stored may vary based on implementation choice.

[0099] Although Figure 7A For ease of understanding, step 122 is shown as a sequential process of a conditional step, but in the implementation process, as shown in FIG. Figure 9 As shown, a physical partition ID can be calculated for each memory transaction, and both a remapped version and a non-remapped version of the partition ID can be provided to a multiplexer 132, which selects between the two versions based on relevant enablement parameters. This can be faster than waiting until a determination has been made whether virtualization is enabled before looking up the physical partition ID.

[0100] Figure 10 is a flow chart showing step 122 in more detail. At step 140, a determination is made as to whether the remapped virtual partition ID is out of range. For example, the hypervisor control register 116 or another MPAM control register 68 (e.g., discovery register MPAMIDR_EL1 142 used to identify to software what capabilities are provided in the hardware) may specify the maximum ID value allowed to be specified by the current context. For example, the hypervisor may define a mappable range of partition IDs that may be used by an operating system executing thereunder, e.g., based on how many mapping registers 126 are provided in the hardware. If the remapped partition ID (i.e., from Figure 7A If the ID read from the register selected at step 112 is out of range, then at step 144 a valid virtual PARTID is selected to be used instead, and the method proceeds to step 149 discussed below. Which particular virtual PARTID is used may be arbitrary, such as the lowest valid PARTID.

[0101] If the virtual partition ID is within the allowed range, then at step 145, a determination is made as to whether the corresponding mapping entry is valid, for example, based on the corresponding valid bit in the 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 invalid, then at step 146, virtual PARTID 0 is selected (i.e., the virtual PARTID is equal to the value 0). At step 147, a check is made as to whether virtual PARTID 0 is valid, and if so, the method continues to step 149. If virtual PARTID 0 is invalid, then at step 148, physical PARTID 0 (a physical PARTID with all bits equal to 0) is used as the physical PARTID to be attached to the memory transaction.

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

[0103] For another example, when the received virtual PARTID is invalid, the process may proceed directly from step 145 to step 148 .

[0104] like Figure 11 As shown, although PARTID_I and PARTID_D are specified separately in the partition ID register 100, the mapping circuit 130 can use a common mapping table 126 for both types of IDs. Therefore, it is not necessary to provide separate sets of mapping registers 126, 128 for instruction access and data access.

[0105] In summary, by providing mapping hardware (mapping registers 126 and mapping circuitry 79) to map the smaller space of virtual IDs to physical IDs in the global ID space used by memory system components, this allows multiple guest operating systems to coexist when using conflicting partition IDs while improving performance because each memory transaction does not need to fall through to the hypervisor to map the partition ID.

[0106] exist Figure 7AAt step 150, a memory transaction is issued that specifies the PMG and PARTID (either in raw form as read from the selected partition ID register or after mapping at step 122), along with a security state indication indicating the security state from which the transaction was issued. The security state indication is included so that partition IDs allocated in the secure domain can use a partition ID space that is completely separate from partition IDs allocated for less secure domains (rather than allocating some partition IDs from a single ID space to secure processes, which can allow non-secure processes to infer information about the provided secure processes). By providing a clean separation between the secure world and the less secure world, security can be improved. The security indication provided with the transaction indicates from which security state the transaction was issued.

[0107] This security indication may be provided separately from any address-based security indication that indicates whether the target address of a transaction is secure or non-secure. That is, regions of the memory address space may be designated as secure or non-secure, where secure regions are only accessible from the secure domain, while non-secure regions are accessible in both the secure and non-secure domains. In the case where the memory system includes additional control structures (such as a system MMU), such address-based security indications may be included with the transaction that control access based on whether the address is in a secure or non-secure region. However, since the secure domain can access both non-secure and secure regions of the address space, such address-based security indications are not sufficient to identify whether the process issuing the transaction is secure or non-secure. Therefore, a memory transaction may separately identify the domain issuing the transaction (MPAM_NS) and the security state (NS) associated with the target address:

[0108] MPAM_NS NS meaning 0 0 Secure: Secure partition ID used to access secure locations (access from a secure state). 0 1 Crossover state: Secure partition ID used to access non-secure locations (from secure state). 1 0 Illegal because access from an unsecured state is not allowed to access a secure location. 1 1 Non-secure: Non-secure partition ID used to access non-secure locations (access from non-secure state).

[0109] Upon receiving a memory transaction, the memory system component can then use the MPAM_NS security indication to select between different parameter groups for the secure and non-secure domains, respectively, to avoid sharing control parameters across domains, which could pose a security risk if non-secure code could set performance control parameters or access performance monitoring data.

[0110] Figure 7B 1 is a flowchart illustrating a method of controlling a slave processing element (such as the CPU 6, GPU or other master device) to issue an instruction to obtain a memory transaction, and in particular, controlling which partition ID is specified by the memory transaction. Figure 7B The method shown in can be used at least for instruction fetch memory transactions issued by fetch stage 40. For instruction-side page table walk memory transactions triggered by such instruction fetch memory transactions, the selection of the MPAM register at step 112 can be handled in different ways, as discussed further below.

[0111] exist Figure 7B At step 111, the processing circuitry issues an instruction fetch memory transaction requesting the fetch of an instruction for a given address. The instruction fetch request may be made by the fetch stage 40 when an instruction is actually needed for execution, or some implementations may include pre-fetch circuitry for pre-fetching instructions into the instruction cache 10 before the instruction is actually needed for execution, and thus the pre-fetch circuitry may also generate an instruction fetch memory transaction.

[0112] Figure 7B Step 112 with Figure 7A The same as shown in for data access, i.e., when one of the MPAM partition ID registers 100 is selected based on the previous operating state (and other control parameters), as discussed above.

[0113] exist Figure 7B At step 116 , the PMG_I and PARTID_I fields of the selected partition ID register 100 are read.

[0114] Figure 7B Steps 120, 122 and 150 are the same as Figure 7A The corresponding steps are the same 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.

[0115] Return 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 given hardware implementation, so that the same code can be executed across multiple different hardware platforms. For example, discovery register 142 can specify whether certain MPAM features are provided (e.g., virtualization, or separate secure / non-secure ID spaces), or what size resources are provided (e.g., the number of bits in a partition ID, or the number of map registers 126). For example, discovery register 142 can specify:

[0116] PARTID_MAX: the maximum partition ID supported by the PE's hardware implementation;

[0117] HAS_HCR: Whether virtualization functionality is provided (and therefore whether hypervisor control registers 116, remap valid registers 124, mapping registers 126, and mapping circuitry 79 are provided)

[0118] VPMR_MAX: The maximum virtual partition ID supported by the PE's hardware implementation when virtualization is implemented.

[0119] PMG_MAX: The maximum PMG value supported by the PE's hardware implementation.

[0120] Discovery register 142 can be read from any exception state except EL0, but is limited to reading and cannot be written to because it defines parameters inherent to a particular hardware implementation. For example, discovery register 142 may be hard-wired during manufacture of the device.

[0121] When virtualization is supported, it may be desirable to prevent an operating system at EL1 from directly reading discovery registers 142, as 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. Consequently, instructions executed at EL1 that attempt to access discovery registers 142 (or at least attempt to access the PARTID_MAX field, which defines the maximum partition ID allowed for a memory transaction) may trigger an exception that traps to the hypervisor, which can then provide a different value (e.g., VPMR_MAX) in place of the maximum value to mimic the number of partition IDs visible to the operating system. The configuration parameter TRAP_MPAMIDR_EL1 controls whether such accesses to discovery registers 142 from EL1 trap 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 registers (IDRs) 142, or whether the hypervisor must intervene. Providing the flexibility to choose whether IDR accesses trap to EL2 is useful for improving performance, particularly when it is appropriate for the OS to directly access the IDR by avoiding unnecessary traps to EL2 (e.g., when virtualization is disabled).

[0122] While virtualization is discussed above in the context of virtual-to-physical ID mappings set up at EL2 for use by EL1 or EL0, generally speaking, this technique can be used with any pair of software execution environments of different privilege levels, such that an environment at a higher privilege level can control the mapping of virtual partition IDs to physical partition IDs for transactions issued by a lower privilege software execution environment. Additionally, unless otherwise noted, the techniques discussed above with respect to partition IDs may also be used with respect to performance monitoring groups in some embodiments, although this is not required. Thus, unless otherwise noted, the term "partition identifier" may be interpreted to encompass performance monitoring group identifiers.

[0123] The partition ID and performance monitoring group attached to a given memory transaction, as well as the security state indication specifying the security state from which the transaction was issued, flow with the memory transaction throughout the memory system. Thus, nodes (e.g., interconnects) of a memory system that pass memory transactions to nodes of other components of the memory system provide the same partition ID, performance monitoring group, and security state indication for the outgoing memory transaction as the corresponding request received at such nodes. For caches within the memory system, the behavior of these nodes sometimes generates a response to a request if there is a cache hit, and at other times passes the request to another part of the memory system if there is a cache miss. They may also sometimes allocate new entries based on requests. When allocating a new entry, the cache may store the partition ID, performance monitoring group, and security indication of the request that caused the allocation along with the cached data itself. When data is written back to another cache or memory, a write-back transaction is generated that specifies the partition ID, performance monitoring group, and security 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 of writebacks to be controlled / monitored according to parameters specific to the software execution environment allocating the corresponding data to the cache.

[0124] Note that not all memory system components (e.g., caches, interconnects, memory controllers, memory devices, or memory management units) can support partitioning. Components that do not support partitioning can control resource allocation or monitor performance in a common manner for all software execution environments. However, outgoing requests are still attached 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. Therefore, regardless of whether the system designer actually chooses to use the partition ID at any given memory system component, the processing element architecture and partition ID routing scheme discussed above provide the flexibility to support a range of specific implementations of partitioning at different points in the memory system. However, for those memory system components that do respond to the partition ID or performance monitoring group ID, they can control resource allocation or contention management or performance monitoring based on the partition ID.

[0125] The performance monitor works differently from the resource partitioning control. The performance monitor measures, counts or calculates performance metrics based on the filter programmed into the monitor. The filter parameters can include partition ID and performance monitoring group (or performance monitoring group, but does not include partition ID). For example, the performance monitor that is counted to the byte being transferred to the memory can filter measurement to count only the readings that have partition ID of 5 and performance monitoring group of 2. Therefore, performance measurement can be collected for different software execution environments or different software execution environment groups that share identical partition ID and performance monitoring group.

[0126] On the other hand, for a system component that supports 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 for controlling the allocation of memory system resources (such as bandwidth, cache capacity, etc.) or competition for these resources (for example, the selected memory system component parameters may define a priority set for transactions associated with the corresponding partition ID).

[0127] Figure 12 A method for controlling the operation of a memory system component based on a partition ID is shown. At step 200, the memory system component receives a memory transaction that specifies a partition ID, a performance monitoring group, and a security status indication as described above. If the memory system component supports memory system resource partitioning (step 202), then at step 204, a set of resource control parameters is selected based on the partition ID and the security status. This step does not consider the performance monitoring group. At step 206, the selected set of resource control parameters is used to control the allocation of resources or to manage contention for these resources. If memory system resource partitioning is not supported, steps 204 and 206 are omitted.

[0128] If the memory system component supports performance monitoring group allocation for performance monitoring (step 208), then at step 210, each performance monitor implemented in the component tests the request against its filter parameters (which may include tests to be applied to the PMG field and the partition ID field). Each monitor that meets its filter parameters updates its internal state based on the measurement, count, or calculation that the monitor is designed to perform. For memory system components that do not support performance monitoring partitioning, step 210 is omitted. As described above, in some embodiments, both the partition ID field and the PMG field can be included in the filter parameters (so that the PMG field further limits the partition ID field). Alternatively, the PMG can be interpreted as a separate ID from the partition ID field, in which case the filter parameters can take into account the PMG but not the partition ID.

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

[0130] Figure 13 An example of a cache 300 is shown as one 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, cluster cache 16, or system cache 20 of a given processing element 6. Cache 300 may also be a cache for address translation, such as TLB 72 or page walk cache 74 in MMU 70. Although Figure 3 An example is shown where the MMU 70 is provided within a given processor core, but a system MMU may also be provided further down in the memory system, such as within the SoC interconnect 18 .

[0131] The cache 300 has a cache storage device (cache RAM) 302 for storing information to be cached. The cache RAM 302 has a certain number of storage entries 304. Figure 13 As shown, each entry can store:

[0132] cache data 306 (which can be any cached information, covering not only data values ​​but also instruction or address translation data, depending on the type of cache),

[0133] Valid bit 308, which specifies whether the corresponding data in the entry is valid,

[0134] Tag field 310, which indicates the portion of the address associated with the cached data

[0135] Partition ID 314 of the memory transaction that allocated the data into the cache

[0136] Performance monitoring group ID 316 for allocating memory transactions

[0137] • Allocate a security state indication 318 for a memory transaction (which indicates from which security state the memory transaction was issued);

[0138] • The system design may require other information to be maintained for each cache line, such as coherency state or address space indicator (ASI).

[0139] When evicting data from the cache, the ID fields 314, 316, 318 are used to derive the partition ID, performance monitoring group ID, and security status indication for write-back transactions. Figure 13Not shown, but each cache entry may also store coherence information specifying the coherence state of the cached data (e.g., whether the data is clean or dirty, used to determine whether a write back is required) and / or victim selection data for selecting a victim cache line when eviction is required (e.g., data for tracking which entries have been least recently used).

[0140] The allocation of data to the cache can be controlled according to any known cache organization, including direct mapped, set associative, or fully associative. Figure 13 The example in FIG shows a set-associative organization scheme with four paths, but it should be understood that this is only an example. Cache lookups are performed independently of the partition ID associated with the corresponding memory transaction. Thus, when a memory transaction is received that specifies a given partition ID, the transaction can hit any data within 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 prevent different software processes from sharing access to cached data.

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

[0142] In the first cache partition control mode, allocation is controlled using a maximum capacity threshold, which is selected using a partition ID and identifies the maximum number of cache capacity entries permitted to be allocated with data associated with the corresponding partition ID. In implementations supporting a secure state and a non-secure state, the threshold may define the maximum capacity permitted to be allocated with data associated with a given combination of partition ID and non-secure ID indicators. For example, the maximum capacity threshold may be set by a higher-privilege process, i.e., the threshold for a given operating system may be set by the hypervisor, and the threshold for a given application may be set by the operating system.

[0143] For example, Figure 2An example is shown in which partition IDs 0, 1, and 2 are assigned maximum capacity thresholds of 50%, 50%, and 40%, respectively. Note that the sum of the maximum capacity thresholds defined for different software execution environments can exceed 100%, as these thresholds only place a maximum limit on the amount of data a cache can store for a given partition ID, rather than a guaranteed allocation. In this case, the corresponding software execution environments will not simultaneously use their maximum allocations.

[0144] Return to Figure 13 Cache 300 has a set of allocation counters 326 that track how many cache entries 304 have been allocated for data associated with each partition ID. If a secure state is supported, these counters can be further divided based on the security state. When a data value for a given partition ID is allocated to the cache, the corresponding allocation counter 326 increments. When data is invalidated, evicted, or replaced, the allocation count for the corresponding partition ID decrements. When a cache miss occurs in response to a given memory transaction, 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 with a maximum capacity threshold, and then controls allocation based on the result of this comparison. If the current allocation has not yet exceeded the threshold, the requested data can be allocated to the cache. However, if the allocation count equals or exceeds the threshold, cache controller 312 can either determine not to allocate any data for the new request or can evict or replace other data associated with the same partition ID from the cache before allocating new data to prevent the cache from being allocated with more entries than the threshold level associated with the partition ID. If eviction or replacement is required, the partition ID 314 stored in each entry in the cache (and, if provided, victim selection information) can be used to determine what data to evict. It should be understood that the above-described manner of counting capacity is merely an example, and other techniques may be used to track cache capacity.

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

[0146] In embodiments that support multiple security states, the security state indication is also used in conjunction with the partition ID to select the appropriate resource control parameter register 320 and allocation count 326 .

[0147] Figure 14 A method for controlling cache allocation based on a maximum capacity threshold in a first partition control mode is shown. At step 330, a cache miss is detected for a given memory transaction. At step 332, a set of resource control parameters 320 is selected based on the corresponding partition ID and security state. At step 334, an allocation count maintained by counter 326 for the corresponding security state and partition ID is compared to the maximum capacity threshold in the selected set of resource control parameters 320, and at step 336, a determination is made as to whether the allocation count is greater than the maximum capacity threshold. If not, at step 338, the requested data 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, at step 340, the data is prevented from being allocated to the cache, or alternatively, at step 342, data associated with the same partition ID as the current request may be replaced or evicted in favor of the newly allocated data, and at step 338, the data may be allocated normally (despite the limits provided by steps 340 or 342, the allocation count may occasionally exceed the threshold, for example, if the threshold has been recently updated). The method whether to proceed to step 340 or 342 is an implementation-specific choice for a given implementation of the cache.

[0148] Alternatively, if Figure 15 As shown, a second cache control mode may be used, wherein a cache capacity portion bitmap 350 selected based on a partition ID is used to control cache allocation. The bitmap 350 has a plurality of fields 352, each field specifying whether a corresponding portion of the cache storage device 302 is allowed to be allocated for storing data associated with the corresponding partition ID. For example, Figure 15 The bitmap 350 shown in the lower portion of the example has 32 fields 352, each corresponding to 1 / 32 of the cache capacity. Each field can be set to 0 to indicate that a transaction specifying the corresponding partition ID cannot allocate data to that portion of the cache, or set to 1 to indicate that the portion is allowed to be allocated with data for that partition ID.

[0149] like Figure 15 As shown in the top portion of , by setting different bitmaps 350 for different partition IDs, this allows some portions of the cache to be reserved for a given partition ID, while other portions can be shared between partition IDs or left completely unallocated. For example, for Figure 15, which is not the entire cache capacity. Portion 0 of the cache is allocated only to partition 1, portion 1 is allocated to both partition 1 and partition 2 so that they can compete for allocations to this portion of the cache, portion 2 is allocated only to partition 2, and portion 3 is not allocated to any of these partitions. Thus, when allocating data to the cache for partition 1, cache controller 312 is restricted to selecting locations within portions 0 or 1, but not portions 2 or 3. A "portion" defined by this bitmap can be any group of one or more cache entries where any given address can be allocated to at least one entry in the group, e.g., an entire way (including all sets belonging to that way) in a set-associative cache, or a more arbitrary subset of entries in a fully associative cache.

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

[0151] 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. This may be useful, for example, because if the particular cache organization being used does not support providing many parts (e.g., a set-associative cache with relatively low associativity), then overriding the maximum capacity limit provides better control than partitioning alone.

[0152] As described 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 be updated, and one or more configuration registers 366 for specifying parameters to be written to the selected set of resource control parameters.

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

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

[0155] Note that such selector registers 364 and configuration registers 366 for setting resource control parameters are only one example of how resource control parameters may be set. The advantage of this approach is that it conserves address space usage in the memory system component. However, an alternative would be to use a wider interface where a series of control settings appear as a series of N control setting registers where N is the maximum number of partition IDs supported. This is simpler because the control configuration can be updated for a partition with a single write and therefore no mutex is required to prevent one processor from accessing the selector registers 364 and configuration registers 366 while another processor is configuring the memory system component. For example, if the maximum number of partition IDs is 2 16 And since a typical memory system component has 2 to 4 controls, this approach can use 256KB of address space for this series of resource control parameters.

[0156] Access to memory-mapped configuration registers 360 can be controlled by the 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 allowed to access configuration registers 360, but access by a hypervisor at EL2 may be permitted. When partition ID virtualization is supported, the partition ID used within cache 300 is the physical partition ID, while an operating system attempting to set resource control parameters for a corresponding application's partition ID will specify the virtual partition ID. Therefore, to prevent the operating system from updating the incorrect resource control parameters, accesses to addresses mapped to configuration registers 360 can be trapped, and an exception can be triggered to switch processing to the hypervisor at EL2. The exception handler in the hypervisor can then issue a corresponding memory transaction with the correct physical partition ID to update the associated set of parameters 320 at cache 300. To achieve this, during the two-level MMU translation process, addresses associated with memory-mapped registers 360 can be placed in a level 2 address page that is distinct from the address space used by other memory system components.

[0157] In a manner similar to resource control partitioning, performance monitoring in cache 300 may be partitioned based on performance monitoring groups (and, in embodiments where PMG is a sub-attribute of the partition ID, partition ID) and security state. A plurality of performance monitors 380 may be provided, each of which may be configured to measure, count, or calculate performance metrics based on filters programmed in a set of filter parameters 382 corresponding to the performance monitor 380. The filter parameters 382 may include fields for specifying a PARTID and a PMG, and upon receiving a memory transaction, if the filter parameters 382 have set a particular value for the PARTID / PMG field, the performance monitor may determine whether to update its metrics based on the transaction based on whether the PARTID / PMG value associated with the transaction matches the value matched in the filter parameters 382. Note that in embodiments supporting the first cache allocation mode, where an allocation counter 326 is provided for tracking whether an allocation threshold is exceeded, the same allocation counter 326 may also be used for performance monitoring.

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

[0159] Although Figure 13An example of a cache 300 is shown, but 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 configuration data group for a corresponding partition ID.

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

[0161] Memory channel bandwidth division

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

[0163] The minimum bandwidth required by the partition, even in the presence of contention

[0164] The maximum bandwidth available to a partition when there is contention

[0165] Any combination of these control schemes can be used simultaneously in channels that support them. Each control scheme is described in the following sections.

[0166] Minimum bandwidth control scheme

[0167] The minimum bandwidth control scheme gives priority to requests from a partition when its current bandwidth is below the minimum, and allows its requests to compete with other normal requests when it is above its minimum bandwidth. Therefore, requests from a partition below its minimum bandwidth are most likely to be scheduled on the channel. The minimum bandwidth control scheme tracks the memory bandwidth during counting.

[0168] If the partition bandwidth usage tracked during the counting period is currently less than the minimum for that partition, its request is given priority to use the channel bandwidth.

[0169] If the partition's bandwidth usage tracked during the counting period is currently greater than the partition's minimum, then its request competes with other normal priority requests for bandwidth on the channel.

[0170] Bandwidth not used by a partition during the counting window is not accumulated. Registers within the memory system component may specify the minimum bandwidth limit for a given partition ID as scaled megabytes per second. The scaled value of megabytes per second is calculated as the required megabytes per second multiplied by a hardware-definable scaling factor.

[0171] Maximum bandwidth limit control scheme

[0172] The maximum bandwidth limit control scheme provides normal priority to partitions that have reached their maximum bandwidth limit during a count cycle. If the partition's bandwidth usage, tracked during the count cycle, is currently less than the partition's maximum, its request competes for scheduling on the memory channel with normal priority. If the partition's bandwidth usage, tracked during the count cycle, is currently greater than the partition's maximum bandwidth limit, its request competes with other less preferred requests for bandwidth on the channel.

[0173] The maximum bandwidth limit control scheme gives normal priority to requests from a partition when its bandwidth usage is below the maximum bandwidth limit, and gives non-priority to requests when bandwidth usage exceeds the maximum bandwidth limit. Therefore, a partition can use more than its maximum bandwidth in the absence of competition for channel bandwidth. Bandwidth requests when a partition's bandwidth usage is below its maximum limit are scheduled with normal priority, so not all bandwidth requested by a partition below its maximum limit may be granted by the channel scheduler based on competing requests. Bandwidth not used by a partition during a counting window is not accumulated.

[0174] Likewise, a control parameter for the maximum bandwidth limit may be specified as scaled megabytes per second. The scaled megabytes per second value is calculated as the desired megabytes per second multiplied by a hardware-definable scaling factor.

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

[0176]

[0177]

[0178] *Note that while priorities may generally be defined as "high", "medium", or "low" to increase the likelihood of servicing "high" priority requests before "medium" or "low" priority requests, a specific implementation may still deviate from the priority order when servicing requests to meet other goals of the specific implementation, such as avoiding starvation.

[0179] For all of the schemes discussed above, the control parameters for the bandwidth partitioning scheme can all be expressed in a given unit, such as megabytes per second. This value is also equal to bytes transmitted per microsecond. A specific implementation may need to multiply each bandwidth partitioning control parameter by a constant scaling factor and then program the resulting value into a bandwidth control register of the memory system component for the partition ID. Whether the specific implementation needs to scale the control parameters and the scaling factor (if scaling is required) can be specified in a discovery register within the memory system component (similar to the cache discovery register 362 described above).

[0180] For all of the above memory bandwidth partitioning schemes, memory channel bandwidth adjustments can occur within a count cycle. The count cycle can be fixed or a moving window. The width of the window can be a discoverable constant that can be read from a discovery register in the memory system component. For example, the count cycle can be at least one microsecond and can be as long as 20 microseconds or more. Longer count cycles may require more hardware, especially in a moving window implementation, while shorter count cycles may have more edge effects, especially in a fixed window implementation.

[0181] In fixed-window computation, bandwidth is allocated to requests so that each partition receives bandwidth based on the minimum and maximum values ​​for that partition. Request or local priorities can be used to resolve conflicting requests for bandwidth. When the counting window period is reached, a new window begins with no history, other than any queued requests that have not been previously serviced. For each partition, the new window begins accumulating bandwidth from zero.

[0182] With a moving window calculation, the moving window maintains a partition's bandwidth history from all commands issued within the past window width. Rather than resetting the bandwidth calculation for each partition, bandwidth is added as a command is processed and removed from the calculation as the command moves out of the window's history. This continuous calculation is relatively free of edge effects, but requires more hardware to track the command history within the window, in addition to the bandwidth counters for each partition ID required for fixed windows.

[0183] The sum of the minimum bandwidth allocations for all partitions can exceed the available bandwidth. This is not a problem when some partitions do not use their bandwidth allocations, as the unused allocations can be used by other partitions. However, when the minimum bandwidth is overallocated, the minimum bandwidth programmed for a partition cannot always be met. Software can ensure that the minimum bandwidth is not overallocated to ensure that the system can reliably deliver the programmed minimum bandwidth allocation.

[0184] Because available bandwidth can depend on one or more clock frequencies in many systems, such as the DDR clock, software may want to reallocate bandwidth when changing the clock, which affects available bandwidth. Reducing the clock rate without changing the allocation can result in overallocation of bandwidth. Note: The available bandwidth on a DRAM channel is not constant but varies with the clock rate and is a mix of read and write and bank hit rates.

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

[0186] Prioritization

[0187] Unlike the other memory system resources listed in this document, priority levels do not directly affect the allocation of memory system resources, but rather have an impact on conflicts that occur when accessing resources. A properly configured system should rarely experience noticeable performance impacts due to priority levels, but priorities do play an important role in situations of oversubscription, whether transient or sustained. Therefore, "prioritization" can be used as a tool to help isolate memory system impacts between partitions.

[0188] Priorities can be assigned to partitions at each component in the memory system that supports prioritization. This partitioning control allows different parts of the memory system to be set up to handle requests with different priorities. For example, requests from the processor to the system cache can be set up to use a higher transfer priority than requests from the system cache to main memory.

[0189] Two types of priorities can be identified for each partition ID:

[0190] Internal priorities control the priorities used in the internal operations of this memory system component. They can be used within the memory system component to prioritize internal operations. For example, the memory controller can use internal priorities to select between waiting requests when bandwidth allocation does not select a clear winner.

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

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

[0193] Controls the partition identifier used for page table walk memory transactions

[0194] The following examples describe techniques that enable a page table walk memory transaction to be assigned a partition ID that is different from the data or instruction access memory transaction that triggered the page table walk. Figure 3As shown, 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 address translation. The address translation can be a one-level address translation from a virtual address (VA) directly to a physical address (PA), or it can be a two-level address translation, in which the virtual address is translated into an intermediate physical address (IPA), which is then translated into a physical address. If the MMU 70 has cached page table information in its TLB 72, 73, 74 or page walk cache 75 that can be used to obtain the translation address (IPA or PA) from the VA, then a data or instruction access specifying the physical address and the partition ID selected as described above can be simply issued. However, if any required page table data for translating 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 the return of the page table data. In some cases, in order to traverse the hierarchical page table structure, several memory transactions may be required as part of the page table walk operation performed to locate the relevant page table data.

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

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

[0197] Therefore, the following examples provide techniques for assigning a different partition ID to a PTW memory transaction than to the corresponding D / I memory transaction. For example, this can enable a partition ID associated with an operating system to be assigned to a PTW memory transaction issued by an application running at a lower privilege level under the management of the operating system. Similarly, in the case of managing multiple operating systems using shared page table data for the operating systems, a hypervisor-associated partition ID can also be assigned to PTW memory transactions issued by the operating systems or their underlying applications, separate from the partition ID assigned to D / I accesses triggered by those operating systems or applications.

[0198] Therefore, by being able to assign different partition IDs to PTW memory transactions compared to D / I accesses, performance and fairness of resource partitioning can be improved. Figure 3 As shown, the MPAM generation logic 77 can output MPAM-related information specific to a D / I page table walk, which can be different from the MPAM-related information used for the corresponding D / I access. For PTW memory transactions issued by the page table walk unit 76, the multiplexer 390 can select between data PTW MPAM information and instruction PTW MPAM information, depending on whether the PTW memory transaction is triggered by a data access or an instruction fetch.

[0199] However, it should be recognized that not all use cases may benefit from PTW memory transactions specifying a different partition ID than the D / I accesses. There are also valid use cases where it may be desirable for PTW memory transactions to specify the same partition ID as the corresponding D / I accesses. For example, in different programming models, the operating system may assign different page table structures to the respective applications running under it. In this case, since there is no sharing of page table data between applications, it may make more sense for any memory resources consumed by PTW memory transactions from a given application to be taken from the resource allocation assigned to that particular application rather than the operating system's resource allocation.

[0200] Thus, in some embodiments, it may be useful if the processing circuitry selects whether different partition identifiers should be assigned to PTW memory transactions and corresponding D / I access memory transactions, or whether the same partition identifier should be assigned, based on programmable information that can be programmed in response to instructions from at least one of the software execution environments. The setting of this programmable information can be controlled by instructions from at least one software execution environment executing at a privilege level other than the least privileged privilege level. Various examples of programmable information are discussed below. In some cases, the programmable information may simply be a second partition ID field for PTW memory transactions, which can be set to the same partition ID as the partition ID field used for D / I accesses, or 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 partition IDs should be assigned differently to page table walks, separate from the fields that actually provide the partition IDs themselves for D / I accesses and PTWs, respectively.

[0201] Specific MPAM Information Registers for PTW

[0202] Figure 16 A first example of an architectural technique that enables different partition IDs to be specified for PTW memory transactions is shown. In this example, the number of partition ID registers 100 is expanded compared to the above examples to include several additional registers. The partition ID registers are still included in Figure 6 Four registers are shown within braces 100 of FIG. 1 and are used to provide a partition identifier for a D / I access memory transaction, wherein when a D / I access transaction is issued, the relevant registers are selected as described above.

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

[0204] like Figure 16As shown at the bottom of FIG, each PTW partition ID register 400 specifies a separate partition ID for data and instruction accesses, and a separate performance monitoring group ID for data and instruction accesses, as discussed above with respect to the partition ID registers 100. In addition, the page table walk partition ID register 400 specifies 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 the other partition ID registers 100 to be selected for data / instruction access transactions in the current execution state.

[0205] Therefore, some system registers 400 are provided to hold MPAM state for the page table walk stage. Software can choose to load each register with a different PARTID than in any MPAMn_ELx register 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}.

[0206] In one example, assuming that Figure 4 The architecture supports a hierarchical structure of software execution environments. The MMU can support the following address translation levels:

[0207] Security EL3 Level 1, which is used to translate virtual addresses (VA) of transactions issued at Security EL3 into physical addresses (PA).

[0208] Security EL1&0 Level 1, used to convert VA to PA for transactions issued at Security EL1 or Security EL0.

[0209] Non-Secure EL2 Level 1, used to convert VA to PA for transactions issued at Non-Secure EL2.

[0210] Non-secure EL2&0 Level 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.

[0211] Non-Secure EL1&0 Level 1, which is used to translate the VA of transactions issued at Non-Secure EL1 or Non-Secure EL0 into an Intermediate Physical Address (IPA).

[0212] Non-secure EL1&0 Level 2, used to convert IPA from Non-secure EL1&0 Level 1 to PA.

[0213] Merging these two secure states reduces the number from 6 to 5. Additionally, EL2 level 1 and EL2&0 level 1 can be combined, since they cannot be used simultaneously, reducing the number to 4:

[0214] EL3 Level 1

[0215] EL2 Level 1 or EL2&0 Level 1

[0216] EL1&0 Level 2

[0217] EL1&0 Level 1

[0218] Therefore, the MPAM registers may include four additional PTW partition ID registers 400 as follows:

[0219] MPAMPTWS1_EL3: for EL3 level 1

[0220] MPAMPTWS1_EL2: for EL2 level 1 and EL2&0 level 1

[0221] MPAMPTWS2_EL2: for EL1&0 level 2

[0222] MPAMPTWS1_EL1: for EL1&0 level 1

[0223] Here, the symbol MPAMPTWSa_ELb indicates that the register is used for one address translation level, and the lowest privilege state in which the contents of the register can be rewritten is ELb.

[0224] All four of these registers have Figure 16 The same fields as shown in:

[0225] EN causes the PARTID and PMG values ​​in this register to be used for those translation stages that use this register. If EN == '0', the MPAM information from the access that caused this page table walk is used. If EN == '1', the MPAM information is generated from the fields of this register.

[0226] PMG_D Performance monitoring group for page table walks initiated by data accesses.

[0227] PMG_I Performance monitoring group for page table walks initiated by instruction accesses.

[0228] PARTID_D Partition ID used for page table walks initiated by data accesses.

[0229] PARTID_I Partition ID used for page table walks initiated by instruction accesses.

[0230] In short, for Figure 16 In the method shown in , the partition identifier registers that specify corresponding partition identifiers for different operating states can be supplemented with additional page table walk partition identifier registers. When issuing a memory transaction, the processing circuit selects the partition identifier stored in the selected partition identifier register and assigns a partition identifier to the memory transaction based on the selected partition identifier. Note that virtualization of partition identifiers can still be supported, at least for accesses initiated from EL0 or EL1, so the memory transaction can be assigned a partition identifier value that may be different from the partition identifier value specified in the selected partition identifier register. The selected partition identifier may depend on the current privilege level at which the memory transaction is issued.

[0231] Therefore, at least one page table walk partition identifier register can be selected as the selected partition identifier register, which provides the selected partition identifier for the page table walk memory transaction. The processing circuit can support multiple address translation levels, wherein each address translation level is based on a corresponding page table structure, and which partition identifier register is the selected partition identifier register for the page table walk memory transaction can depend on the address translation level associated with the page table walk memory transaction. Different execution environments that manage the corresponding page table structures for different address translation levels can have different requirements for resource partitioning control, so this is why providing different partition identifiers for each address translation level can be useful. Alternatively, some address translation levels can share the same partition identifier register, and in this case, when switching between execution contexts, the register may need to be reprogrammed.

[0232] In some implementations, the enable field 402 shown 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 can increase programming burden, as if a specific use case desired to assign the same partition ID to a PTW memory transaction as used for a D / I transaction, then both registers would need to be written with the relevant partition IDs. Furthermore, for backward compatibility with code written for systems without 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 a disabled state, causing page table walk transactions to use a partition ID selected from one of the other non-PTW partition ID registers 100.

[0233] Therefore, for a given PTW memory transaction, the processing circuitry can determine whether the enable field of the corresponding PTW partition identifier register specifies an enabled state or a disabled state. Which register is the corresponding PTW partition identifier register can depend on the current operating state (security state / privilege level) and address translation level for which the PTW memory transaction is issued, as described above. When the enable field indicates the enabled state, the corresponding PTW partition identifier register itself can be used as the selected partition identifier register for the PTW memory transaction, and a partition ID can then be selected from this register. On the other hand, when the enable field of the corresponding PTW partition identifier register indicates the disabled state, the selected partition ID register can be a partition ID register other than the at least one PTW partition ID register 400. Specifically, when the enable field of the corresponding partition ID register is in the disabled state, if a data / instruction access memory transaction has already been issued from the current execution state, the selected partition ID register can be the same one of the non-PTW partition ID registers 100 that was already selected.

[0234] It may be useful for the PTW partition ID register to specify separate data and instruction partition IDs. This may allow different applications or operating systems to share the same partition ID for instruction page table walks, but use different partition IDs for, for example, 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, while 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.

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

[0236] Furthermore, as in the general embodiment discussed above, although Figure 16 A separate performance monitoring group (PMG) is shown compared to the PARTID used for resource control, but other approaches may provide the same partition ID for both resource control and performance monitoring.

[0237] Configurable sources of MPAM information

[0238] Figure 17A second example of enabling PTW memory transactions to use different partition IDs for corresponding D / I memory transactions is shown. In this example, rather than providing an additional partition ID register dedicated to PTW transactions, PTW memory transactions can share the same partition ID register used for D / I access memory transactions. However, as Figure 17 As shown, some additional control states 410 to 416 are provided in some of the partition ID registers 100 to redirect PTW transactions from a given execution environment to use a partition identifier specified in a partition ID register 100 other than the current execution environment, if desired.

[0239] This approach comes from the observation that exception levels higher than the current exception level already contain MPAM information relevant to the software environments running at those levels. This means that no additional MPAM information needs to be stored in the CPU, and this feature provides control over which exception level to select from which MPAM information to obtain during different kinds of translation table accesses, but does not include additional registers or even register bits to hold MPAM partition IDs beyond those already present in the general scheme described above.

[0240] The MPAM information to be used depends on the current exception level and the translation level in use. The two-level translation scheme uses two levels in the translation process, and the MPAM information used by each level may need to be different. In the two-level scheme, the source of the MPAM information is controlled separately for each level.

[0241] Each MPAMn_ELx register gains 1 or 2 new fields that control the source of MPAM information for the page table walk. One field (S1PTWSRCn) exists in each of the MPAM2_EL2 and MPAM1_EL1 registers. S1PTWSRCn is the source of MPAM information for a single-level page table walk or for the first level of a two-level PTW executed by executing at ELn. A second field (S2PTWSRCn) exists in each of MPAM2_EL2 and MPAM1_EL1. The second field controls the source of MPAM information for the second level PTW executed by executing at ELn. The settings in each of these fields essentially:

[0242] Backwards compatibility (i.e. PTW transactions will use the same partition information as the corresponding data / instruction accesses)

[0243] Use the MPAM information of the execution ELn for PTW transactions

[0244] Use the MPAM information of execution ELn+1 for PTW transactions.

[0245] Therefore, new control fields are added to some of the MPAM partition ID registers 100. Register fields beginning with "S1PTW" control the source of MPAM information for level 1 page table walks, while register fields beginning with "S2PTW" control the source of MPAM information for level 2 page table walks. The number at the end indicates the execution EL that uses the setting.

[0246] like Figure 17 As shown, MPAM1_EL1 adds S1PTWSRC0 and S2PTWSCR0 fields (4 bits), and MPAM2_EL2 adds S1PTWSRC1 and S2PTWSCR1 fields (4 bits).

[0247] S1PTWSRC0 (bits [51:50]): Level 1 page table walk (hypervisor) source control for EL0

[0248] 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 level 1 page table walk. If TGE == '1' (TGE is a flag in the Hypervisor Control Register (HCR) 116 that, when TGE=1, indicates that exception types generated at EL0 that would normally be routed to EL1 (if TGE=0) should be routed to EL2 instead), MPAM1_EL1.S1PTWSRC0 is not used.

[0249] S1PTWSRC0 412 can take the following values ​​(each represented as a binary 2-bit value):

[0250] 0: Backward Compatible - PTW transactions use the same partition information as would be used for corresponding data / instruction access memory transactions.

[0251] 1: In EL0 and TGE == 0, if MPAMHCR_EL2.GSTAPP_PLK == 0, use the MPAM0_EL1 PARTID and PMG fields for level 1 PTW access. If MPAMHCR_EL2.GSTAPP_PLK == 1, use the MPAM1_EL1 PARTID and PMG fields for level 1 PTW access. MPAMHCR_EL2.GSTAPP_PLK is the control flag 115 discussed above. In EL0 and TGE == 1, use the MPAM0_EL1 PARTID and PMG fields for level 1 PTW access.

[0252] 2: In EL0 and TGE == 0, use MPAM1_EL1 PARTID and PMG fields for level 1 PTW access.

[0253] In EL0 and TGE == 1, use the MPAM2_EL2 PARTID and PMG fields for level 1 PTW access.

[0254] 3: Keep.

[0255] S1PTWSRC1 (bits [51:50]): Level 1 page table walk (hypervisor) source control for EL1

[0256] In MPAM2_EL2, an additional field 416 is added.

[0257] S1PTWSRC1 controls whether the MPAM1_EL1 or MPAM2_EL1 register is used as the source of the PARTID for the level 1 page table walk caused by executing at EL1.

[0258] S1PTWSRC1 (bits [51:50])

[0259] 0: Backward compatibility.

[0260] 1: In EL1, use the MPAM1_EL1 PARTID and PMG fields for level 1 PTW access.

[0261] 2: In EL1, use the MPAM2_EL2 PARTID and PMG fields for level 1 PTW access.

[0262] 3: Keep.

[0263] S2PTWSRC0 (bits [53:52]): Level 2 page table walk (hypervisor) source control for EL0

[0264] An additional field 410 is added to MPAM1_EL1, which is defined as follows:

[0265] S2PTWSRC0 (bits [53:52]): Level 2 page table walk source control

[0266] 0: Backward compatibility.

[0267] 1: In EL0 and TGE == 0, use MPAM1_EL1.PARTID_D or PARTID_I for level 2 PTW memory accesses. PTWs caused by instruction fetch accesses use PARTID_I, and PTWs caused by load / store accesses use PARTID_D.

[0268] In EL0 and TGE == 1, use MPAM2_EL2.PARTID_D or PARTID_I for level 2 PTW memory accesses. PTWs caused by instruction fetch accesses use PARTID_I, and PTWs caused by load / store accesses use PARTID_D.

[0269] 2: In EL0, use MPAM2_EL2.PARTID_D or PARTID_I for level 2 PTW memory accesses. PTWs caused by instruction fetch accesses use PARTID_I, and PTWs caused by load / store accesses use PARTID_D.

[0270] 3: Keep.

[0271] S2PTWSRC1 (bits [53:52]): Level 2 page table walk (hypervisor) source control for EL1

[0272] An additional field 414 is added to MPAM2_EL2, which is defined as follows:

[0273] S2PTWSRC1 (bits [53:52]): Level 2 page table walk (hypervisor) source control for EL1

[0274] 0: Backward compatibility.

[0275] 1: In EL1, use MPAM1_EL1.PARTID_D or PARTID_I for level 2 PTW memory accesses. PTWs caused by instruction fetch accesses use PARTID_I, and PTWs caused by load / store accesses use PARTID_D.

[0276] 2: In EL1, use MPAM2_EL2.PARTID_D or PARTID_I for level 2 PTW memory accesses. PTWs caused by instruction fetch accesses use PARTID_I, and PTWs caused by load / store accesses use PARTID_D.

[0277] 3: Keep.

[0278] Thus, using this approach for PTW memory transactions issued from the current privilege level, the processing circuitry is able to select a partition ID register associated with a privilege level that is more privileged than the current privilege level as the selected partition ID register to be used to generate the partition identifier for the PTW memory transaction. This can reduce the hardware cost of implementing support for different partition IDs for PTW memory transactions because less register storage space is required, although slightly more complex selection logic may be required to select which partition ID to use for a given memory transaction.

[0279] The processing circuitry can select, based on programmable configuration information, 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 with higher privilege than the current privilege level. This programmable configuration information can be programmed by instructions executed at the higher privilege level. Thus, for example, an operating system can set programmable states 410, 412 to control whether an application running under it uses its own partition ID register for PTW memory transactions or refers to the register used for D / I memory transactions in the operating system. Similarly, a hypervisor can use states 414, 416 to control which partition ID register 100 is selected for use by a Level 1 or Level 2 PTW transaction issued by the operating system at EL1.

[0280] like Figure 17 As shown, in some cases, there may be multiple programmable configuration information items 410, 412, 414, and 416, each associated with a different combination of privilege level, security state, and address translation level. Therefore, for a given PTW memory transaction, one of the programmable configuration information items can be selected based on at least one of the current privilege level, current security state, and current address translation level at which the PTW memory transaction was issued. Based on the selected programmable configuration information item, the processing circuit can then 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 having a higher privilege.

[0281] Although Figure 17 A specific example of how these programmable configuration information items 410 to 416 may be stored within the MPAM control register 68 is shown, but a different layout of control states or storing the programmable configuration information 410 to 416 in registers separate from their own partition ID register 100 may also be used.

[0282] Figure 18 A flow chart is shown that illustrates a method of handling partition ID assignment for a PTW memory transaction. At step 500, a PTW memory transaction is issued by the MMU 70. At step 502, the processing circuitry checks programmable information (which, for at least some privilege levels, may be set to a privilege level that is more privileged than the current privilege level) indicating whether the PTW transaction for the current translation level and privilege level should have a different partition ID than the corresponding data / instruction access memory transaction. This programmable information may be Figure 17 , which redirects the PTW transaction to reference a different MPAN register 100 than the corresponding D / I instruction accesses, or may be, for example, Figure 16 The enable field 402 of the dedicated PTW partition ID register is shown in FIG.

[0283] If the programmable information selected for the current access is in a disabled state, which indicates that the PTW transaction should be processed in the same manner as the D / I access memory transaction, then at step 504, the same partition ID as that to be assigned to the corresponding D / I access memory transaction is assigned to the PTW memory transaction. For example, the above-described Figure 8 The method shown in , selects the partition ID register based on the current exception level and the GSTAPP_PLK field, and the relevant partition ID in the partition ID (instruction or data) can be assigned to the PTW memory transaction.

[0284] However, if it is determined at step 502 that the programmable information indicates that the option to provide separate partition IDs for PTW transactions at the current privilege level and translation level has been enabled, then at step 506, a different partition ID is assigned to the PTW memory transaction than the corresponding D / I access memory transaction. For example, if Figure 16 , you can refer to the dedicated PTW partition ID register to obtain the partition ID value to use (depending on the virtualization that maps that value), or if you use Figure 17 , then the partition ID register for a privilege level other than the current privilege level may be referenced to obtain the partition ID for deriving the partition ID value to be assigned to the memory transaction.

[0285] In this application, the phrase "configured to..." is used to mean that elements of a device have a configuration that enables them to perform a defined operation. In this context, "configuration" refers to the arrangement or manner in which hardware or software are interconnected. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device elements need to be modified in any way in order to provide the defined operation.

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

Claims

1. A device, comprising: processing circuitry for processing instructions from one of the plurality of software execution environments; and at least one memory system component for processing memory transactions issued by the processing circuitry in response to the instructions; wherein: In response to a memory transaction issued by the processing circuitry specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, the at least one memory system component is configured to: control allocation of resources for processing the memory transaction or manage contention for the resources based on a selected set of memory system component parameters, the selected set of memory system component parameters being selected based on the partition identifier specified by the memory transaction; or control whether performance monitoring data is updated in response to the memory transaction based on the partition identifier specified by the memory transaction; and When the processing circuit issues a page table walk memory transaction to request access to page table data required to obtain a translation 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 apparatus of claim 1 , wherein the processing circuit is configured to select, based on programmable information that is programmable in response to an instruction from at least one of the plurality of software execution environments, whether to: Assigning different partition identifiers to the page table walk memory transaction and the corresponding data / instruction access memory transaction, or The same partition identifier is assigned to the page table walk memory transaction and the corresponding data / instruction access memory transaction. 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. An apparatus according to any preceding claim, comprising a plurality of partition identifier registers each specifying a respective partition identifier; wherein: When issuing a memory transaction, the processing circuit is configured to select a partition identifier stored in the selected partition identifier register and assign a partition identifier to the memory transaction in accordance with the selected partition identifier stored in the selected partition identifier register.

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 from which the memory transaction was issued.

6. The apparatus of any one of claims 4 and 5, wherein the plurality of partition identifier registers comprises at least one page table walk partition identifier register, the page table walk partition identifier register being selectable as the selected partition identifier register to provide the selected partition identifier for a page table walk memory transaction.

7. The apparatus of claim 6, wherein the processing circuit is configured to support a plurality of address translation stages, each address translation stage being based on a corresponding page table structure; The plurality of partition identifier registers include a plurality of page table walk partition identifier registers each associated with at least one address translation level; and For a page table walk memory transaction, the processing circuit is configured to select which partition identifier register is the selected partition identifier register based on the address translation level associated with the page table walk memory transaction.

8. The apparatus of any one of claims 6 and 7, wherein each page table walk partition identifier register includes an enable field specifying one of an enabled state and a disabled state; For a given page table walk memory transaction, the processing circuit is configured to determine whether the enable field of the corresponding page table walk partition identifier register specifies the enabled state or the disabled state; When the enable field of the corresponding page table walk partition identifier register indicates the enable state, the selected partition identifier register is the corresponding page table walk partition identifier register; and When the enable field of the corresponding page table walk partition identifier register indicates the disabled state, the selected partition identifier register is a partition identifier register other than the at least one page table walk partition identifier register.

9. The apparatus of any one of claims 6 to 8, wherein each page table walk partition identifier register specifies a data partition identifier and an instruction partition identifier; and 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 circuit is configured to select the data partition identifier specified by the selected partition identifier register as the selected partition identifier; and For a page table walk memory transaction corresponding to an instruction access memory transaction, the processing circuit is configured to select the instruction partition identifier specified by the selected partition identifier register as the selected partition identifier.

10. The apparatus according to any one of claims 4 to 9, wherein the processing circuit is configured to execute instructions from one privilege level of a plurality of privilege levels; and For a page table walk memory transaction issued from a current privilege level, the processing circuitry can select, as the selected partition identifier register, a partition identifier register associated with a privilege level that is more privileged than the current privilege level.

11. The apparatus according to any one of claims 4 to 10, wherein the processing circuit is configured to execute instructions from one privilege level of a plurality of privilege levels; and For a page table walk memory transaction issued from a current privilege level, the processing circuitry is configured to select, based on 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 having higher privilege than the current privilege level.

12. The apparatus of claim 11, wherein the programmable configuration information is programmable by instructions executed at the more privileged permission level.

13. The apparatus according to any one of claims 11 and 12, wherein the programmable configuration information comprises a plurality of programmable configuration information items; For a page table walk memory transaction, the processing circuit is configured to select one of the programmable configuration information items according to at least one of the following: the privilege level from which the page table walk memory transaction is issued; a security state of the processing circuitry from which the page table walk memory transaction is issued; as well as which address translation level of a plurality of address translation levels is associated with the page table walk memory transaction, each address translation level being based on a corresponding page table structure; and The processing circuit is configured to control, based on the selected programmable configuration information item, 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 having a higher privilege than the current privilege level.

14. The apparatus of any preceding claim, wherein the at least one memory system component comprises at least one of: a cache configured to control allocation of data to the cache in response to the memory transaction based on the selected set of memory system component parameters; and An interconnect or memory controller configured to control bandwidth allocation or buffer occupancy for processing the memory transaction based on the selected set of memory system components.

15. A device 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 said means for processing in response to said instruction; wherein: In response to a memory transaction issued by the means for processing specifying a partition identifier selected according 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 the resources according to a selected set of memory system component parameters, the selected set of memory system component parameters being selected according to the partition identifier specified by the memory transaction; or control whether performance monitoring data is updated in response to the memory transaction according to the partition identifier specified by the memory transaction; and When the apparatus for processing issues a page table walk memory transaction to request access to page table data required to obtain a translation target address of a corresponding data / instruction access memory transaction, the apparatus 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. A method comprising: processing instructions from one of the plurality of software execution environments; as well as processing a memory transaction issued in response to the instruction; wherein: In response to a memory transaction specifying a partition identifier selected based on which software execution environment caused the memory transaction to be issued, at least one memory system component controls allocation of resources for processing the memory transaction or manages contention for the resources based on a selected set of memory system component parameters, the selected set of memory system component parameters being selected based on the partition identifier specified by the memory transaction; or controls whether performance monitoring data is updated in response to the memory transaction based on the partition identifier specified by the memory transaction; and When a page table walk memory transaction is issued to request access to page table data required to obtain a translation target address of a corresponding data / instruction access memory transaction, the partition identifier assigned to the page table walk memory transaction is allowed to be a partition identifier different from the partition identifier assigned to the corresponding data / instruction access memory transaction.

Images