Managing latency in synchronous events

Abstract

The electronic device includes one or more processors for executing one or more virtual machines. In response to a request to initiate a synchronization event, the processor identifies a subset of speculative memory access requests in one or more memory access request queues. Automatically and in accordance with the identification, the processor purges translations associated with the subset of speculative memory access requests. Following the purging, the processor initiates the synchronization event. In some implementations, the memory access completion is forced in response to a context synchronization event corresponding to a first application termination, a first virtual machine termination, or a system call to update a system register. Alternatively, in some implementations, the memory access completion is forced at an operating system level or an application level in response to a data synchronization event initiated on a hypervisor layer or a firmware layer.

Description

[Technical field]

[0001] Priority Application This application claims priority to U.S. patent application Ser. No. 17 / 684,231, entitled "LATENCY MANAGEMENT IN SYNCHRONIZATION EVENTS," filed Mar. 1, 2022, which is incorporated by reference in its entirety.

[0002] This application relates generally to microprocessor technology, including, but not limited to, methods, systems, and devices for managing memory access requests associated with one or more processors executing virtual machines. [Background technology]

[0003] Caching improves computer performance by keeping recently or frequently used data items in a cache where access is faster, such as references to the physical addresses of frequently used data, compared to a physical memory store. When new information is fetched from a physical memory store or cache, the cache is updated to store the newly fetched information to reflect current and / or anticipated data needs. A computer system that hosts one or more virtual machines may store information related to functions or applications executed in each virtual machine in different caches across the computer system. Before a virtual machine is stopped or an application is closed on a virtual machine, the computer system must complete all table walks of memory access queues and / or sample all system registers to collect application identifiers and virtual machine identifiers during address translation. Such long latency table walk and register sampling operations delay the stopping of the virtual machine and the termination of applications on the virtual machine. It would therefore be highly desirable to provide an electronic device or system that efficiently manages memory access requests and associated address translations for one or more processors running virtual machines. Summary of the Invention [Means for solving the problem]

[0004] Various implementations of the systems, methods, and devices within the scope of the appended claims each have several aspects, no single one of which is solely responsible for the attributes described herein. Without limiting the scope of the appended claims, after considering this disclosure, and in particular the section entitled "Description of the Preferred Embodiments," one will understand how aspects of some implementations are used to manage memory accesses queued during synchronization events in a processor system running a virtual machine. At each synchronization event, the processors organize a handshaking process to identify speculative memory access requests and purge translations associated with the speculative memory access requests without stalling the synchronization event.

[0005] In particular, in some implementations, outstanding translation requests associated with speculative memory access requests are marked with a flag (e.g., "purged with null response"). In response to each marked translation request, the corresponding translation process is terminated early without filling any translation cache structures (e.g., translation lookaside buffer (TLB), table walk cache). Data extracted from any speculative memory access request associated with the translation process cannot be applied, for example, by an instruction fetch module, a load / store module, or a prefetch engine of the processor. The processor skips the long latency table walk of the translation associated with the speculative memory access request without compromising the execution of a synchronization event. There is no need for system registers to be sampled and copied across translation units. By these means, an efficient memory management solution is provided for efficiently managing memory access requests and associated address translations for one or more processors running virtual machines, thereby also effectively facilitating synchronization events.

[0006] In some implementations, a method for managing memory accesses is employed in each of one or more processors configured to execute one or more virtual machines. The method includes receiving a request to initiate a synchronization event. The method further includes, in response to the request, identifying a subset of speculative memory access requests in one or more memory access request queues, automatically purging translations associated with the subset of the speculative memory access requests according to the identification, and initiating the synchronization event. In some implementations, each memory access request queue includes an ordered sequence of memory access requests, and the subset of the speculative memory access requests are queued in anticipation of one or more instructions being received following the request.

[0007] In some implementations, each processor is associated with a translation cache, and initiating the synchronization event further includes, for each speculative memory access request, terminating a corresponding memory access request to read or write the respective data item from or to the respective memory unit, ceasing to fill a translation cache associated with the respective processor, and suspending use of the respective data item by the respective processor. Further, in some implementations, the translation cache includes a TLB and a page table cache.

[0008] In some implementations, the method further includes receiving a barrier instruction configured to force a memory access completion to initiate a context synchronization event. The context synchronization event corresponds to a termination of a first application to initiate a second application, a termination of a first virtual machine to initiate a second virtual machine, or a system call to update a system register. Alternatively, in some implementations, the method further includes receiving a barrier instruction configured to force a memory access completion to initiate a data synchronization event to update a register associated with a virtual machine implemented on the respective processor.

[0009] In another aspect, an electronic device includes one or more processors configured to execute one or more virtual machines, each processor configured to perform any of the methods described above.

[0010] In another aspect, a non-transitory computer-readable storage medium stores one or more programs configured for execution by each of one or more processors configured to execute one or more virtual machines, the one or more programs including instructions that, when executed by the respective processor, cause the respective processor to perform any of the methods described above.

[0011] In yet another aspect, an apparatus for managing memory access in each processor of one or more processors includes means for performing any of the methods set forth above, wherein the one or more processors are configured to execute one or more virtual machines. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram of illustrative system modules in a typical electronic device, in accordance with some implementations. [Diagram 2]1 is a block diagram of an example electronic device having one or more processing clusters, according to some implementations. [Figure 3A] FIG. 2 is a block diagram of a hypervisor for hosting virtual machines on a system module according to some implementations. [Figure 3B] A flow diagram of a one-stage table walk process for fetching data by a processing cluster, according to some implementations. [Figure 4] 4 is a diagram of an example sequence of instructions implemented to enable a context synchronization event, according to some implementations. [Diagram 5] 5 is a diagram of another example sequence of instructions 500 configured to enable a data synchronization event, according to some implementations. [Figure 6A] FIG. 1 is a flow diagram of an example address translation process implemented at a context synchronization event, according to some implementations. [Figure 6B] 1 is a diagram of an example sequence of instructions configured to update a system register, according to some implementations. [Figure 6C] FIG. 13 is a flow diagram of another example address translation process implemented during a data synchronization event, according to some implementations. [Figure 6D] A diagram of an example sequence of instructions configured to update system registers and complete a table walk, according to some implementations. [Figure 7] FIG. 1 is a flow diagram of a process for controlling latency in synchronous events, according to some implementations. [Figure 8] 1 is a flow diagram of a method for managing memory access according to some implementations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] For an improved understanding of the various described implementations, reference should be made to the following detailed description in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout and in which:

[0014] Reference will now be made in detail to certain embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth to aid in understanding the subject matter presented herein. However, it will be apparent to those skilled in the art that various alternatives may be used without departing from the scope of the claims, and that the subject matter may be practiced without these specific details.

[0015] FIG. 1 is a block diagram of an exemplary system module 100 in a typical electronic device, according to some implementations. The system module 100 in this electronic device includes at least a system on chip (SoC) 102, a memory module 104 for storing programs, instructions, and data, an input / output (I / O) controller 106, one or more communication interfaces, such as a network interface 108, and one or more communication buses 150 for interconnecting these components. In some implementations, the I / O controller 106 enables the SoC 102 to communicate with I / O devices (e.g., a keyboard, a mouse, or a trackpad) via a universal serial bus interface. In some implementations, the network interface 108 includes one or more interfaces for Wi-Fi, Ethernet, and Bluetooth networks, each of which allows the electronic device to exchange data with an external source, e.g., a server or another electronic device. In some implementations, the communication bus 150 includes circuitry (sometimes referred to as a chipset) that interconnects and controls communication between various system components included in the system module 100.

[0016] In some implementations, the memory module 104 (e.g., memory 104 in FIG. 2) includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices. In some implementations, the memory module 104 includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. In some implementations, the memory module 104, or alternatively, the non-volatile memory devices within the memory module 104, include a non-transitory computer-readable storage medium. In some implementations, a memory slot is reserved on the system module 100 to receive the memory module 104. When inserted into the memory slot, the memory module 104 is incorporated into the system module 100.

[0017] In some implementations, the system module 100 further includes one or more components selected from the following: A memory controller 110 that controls communications between the SoC 102 and memory components, including the memory module 104, in the electronic device, including controlling memory management unit (MMU) line replacements (e.g., cache entry replacement, cache line replacement) in the cache in accordance with a cache replacement policy. · A solid-state drive (SSD) 112 that applies integrated circuit assemblies to store data within an electronic device, and in many implementations is based on NAND or NOR memory configurations. · A hard drive 114, a conventional data storage device based on electromechanical magnetic disks and used to store and retrieve digital information. A power connector 116 electrically coupled to receive an external power source. · A power management integrated circuit (PMIC) 118 that modulates the received external power supply to other desired DC voltage levels, e.g., 5V, 3.3V, or 1.8V, as required by various components or circuits within the electronic device (e.g., SoC 102). · A graphics module 120 that generates output image feeds to one or more display devices according to their desired image / video formats. · A sound module 122, which facilitates the input and output of audio signals to and from electronic devices under the control of a computer program.

[0018] It should be noted that communication bus 150 also interconnects and controls communications between various system components, including components 110-122.

[0019] Additionally, one skilled in the art will appreciate that other non-transitory computer readable storage media may be used as new data storage technologies are developed for storing information on those non-transitory computer readable storage media within memory module 104 and SSD 112. Although each data storage technology is currently under development and has not yet been commercialized, these new non-transitory computer readable storage media include, but are not limited to, those made from biological materials, nanowires, carbon nanotubes, and individual molecules.

[0020] In some implementations, the SoC 102 is implemented on an integrated circuit that integrates one or more microprocessors or central processing units, memory, input / output ports, and secondary storage on a single substrate. The SoC 102 is configured to receive one or more internal supply voltages provided by the PMIC 118. In some implementations, both the SoC 102 and the PMIC 118 are mounted on a main logic board, e.g., on two separate areas of the main logic board, and are electrically coupled to each other via conductors formed in the main logic board. As explained above, this arrangement results in parasitic effects and electrical noise that can impair the performance of the SoC, e.g., cause voltage drops in the internal voltage supplies. Alternatively, in some implementations, the SoC 102 and the PMIC 118 are vertically arranged in the electronic device, such that they are electrically coupled to each other via electrical connections that are not formed in the main logic board. Such a vertical arrangement of the SoC 102 and the PMIC 118 can reduce the length of electrical connections between the SoC 102 and the PMIC 118 and avoid performance degradation caused by conductors on the main logic board. In some implementations, the vertical arrangement of the SoC 102 and the PMIC 118 is facilitated in part by the integration of thin-film inductors in the limited space between the SoC 102 and the PMIC 118.

[0021] 2 is a block diagram of an example electronic device 200 having one or more processing clusters 202 (e.g., a first processing cluster 202-1, an Mth processing cluster 202-M) according to some implementations. In some implementations, the processing clusters 202 are implemented on one SoC 102. In some implementations, the processing clusters 202 are distributed across multiple SoCs. In addition to the processing clusters 202, the electronic device 200 further includes a cache 220 and a memory 104. The cache 220 is coupled to the processing clusters 202 on the electronic device 200, and the electronic device 200 is further coupled to the memory 104 that is external to the SoC 102. Each processing cluster 202 includes one or more processors 204 and a cluster cache 210. The cluster cache 210 is coupled to the one or more processors 204 and, in some cases, maintains one or more request queues 240 for the one or more processors 204. Each cluster cache 210 is also associated with one or more filters 232 that may be used to determine whether a cache entry for a particular virtual machine, a cache entry for a particular address space, or a cache entry for a particular virtual address is stored in the associated cluster cache 210.

[0022] In some implementations, each processor 204 further includes a core cache 208, possibly divided into an instruction cache and a data cache, which stores instructions and data that may be immediately executed by the respective processor 204. Each core cache 208 is also associated with one or more core filters (not shown in FIG. 2 ) that may be used to determine whether a cache entry for a particular virtual machine, address space, or virtual address is stored in the associated core cache 208.

[0023] In one example, the first processing cluster 202-1 includes a first processor 204-1, ...., an Nth processor 204-N, and a first cluster cache 210-1, where N is an integer greater than 1. The first cluster cache 210-1 has one or more first request queues 240-1, each of which includes a queue of demand requests and prefetch requests received from a subset of the processors 204 of the first processing cluster 202-1. Additionally, when a new cache entry is stored in the first cluster cache 210-1, one or more filters 232-1 associated with the first cluster cache 210-1 are updated to store information about the newly added cache entry. For example, when a new cache entry including a first virtual machine identifier (VMID) is stored in the first cluster cache 210-1, the one or more filters 232-1 associated with the first cluster cache 210-1 are updated to store information indicating that the first cluster cache 210-1 stores at least one cache entry with the first VMID. However, when the first cluster cache 210-1 is updated with the new cache entry, some cache entries may be evicted from the first cluster cache 210-1, such that the evicted cache entries are no longer stored in the first cluster cache 210-1. The one or more filters 232-1 associated with the first cluster cache 210-1 may continue to store information indicating that the first cluster cache 210-1 stores at least one cache entry with the first VMID, even if a cache entry including the first VMID is no longer stored in the first cluster cache 210-1. The filter or filters 232-1 associated with the first cluster cache 210-1 must be regenerated to accurately reflect the cache entries currently stored in the first cluster cache 210-1.For example, one or more filters 232-1 associated with the first cluster cache 210-1 are updated to remove information indicating that the first cluster cache 210-1 stores at least one cache entry with the first VMID.

[0024] In some implementations, the SoC 102 includes only a single processing cluster 202-1. Alternatively, in some implementations, the SoC 102 includes at least an additional processing cluster 202, e.g., an Mth processing cluster 202-M. The Mth processing cluster 202-M includes a first processor 206-1, ...., an N'th processor 206-N', and an Mth cluster cache 210-M, where N' is an integer greater than 1, and the Mth cluster cache 210-M has one or more Mth request queues 240-M.

[0025] In some implementations, the one or more processing clusters 202 are configured to provide a central processing unit for the electronic device and are associated with a hierarchy of caches. For example, the hierarchy of caches includes three levels, differentiated based on their distinct operating speeds and sizes. In this application, references to the "speed" of a memory (including cache memory) relate to the time required to write data to or read data from the memory (e.g., faster memories have shorter write and / or read times than slower memories), and references to the "size" of a memory relate to the storage capacity of the memory (e.g., smaller memories provide less storage space than larger memories). The core cache 208, the cluster cache 210, and the cache 220 correspond to a first level (L1), second level (L2), and third level (L3) cache, respectively. Each core cache 208 holds instructions and data to be directly executed by the respective processor 204, and has the fastest operating speed and smallest size of the three levels of memory. For each processing cluster 202, cluster cache 210 is operationally slower than core cache 208, is larger in size, and holds data that is more likely to be accessed by processors 204 of the respective processing cluster 202. Cache 220 is shared by multiple processing clusters 202 and is larger in size and slower than each of core cache 208 and cluster cache 210. Each processing cluster 202 controls the prefetching of instructions and data into core cache 208 and / or cluster cache 210. Each individual processor 204 further controls the prefetching of instructions and data from its respective cluster cache 210 to its respective individual core cache 208.

[0026] In some implementations, the first cluster cache 210-1 of the first processing cluster 202-1 is coupled to a single processor 204-1 in the same processing cluster and is not coupled to any other processor (e.g., 204-N). In some implementations, the first cluster cache 210-1 of the first processing cluster 202-1 is coupled to multiple processors 204-1 and 204-N in the same processing cluster. In some implementations, the first cluster cache 210-1 of the first processing cluster 202-1 is coupled to one or more processors 204 in the same processing cluster 202-1 and is not coupled to processors in any cluster other than the first processing cluster 202-1 (e.g., processor 206 in cluster 202-M). The first cluster cache 210-1 of the first processing cluster 202-1 may be referred to as a second level cache or L2 cache.

[0027] In each processing cluster 202, each request queue 240 possibly includes a queue of demand requests and prefetch requests received from a subset of the processors 204 of the respective processing cluster 202. Each data access request received from each processor 204 is dispatched to one of the request queues 240 associated with the respective processing cluster 202. In some implementations, a request queue 240 receives requests only received from a particular processor 204. In some implementations, a request queue 240 receives requests from more than one processor 204 in a processing cluster 202, allowing the request load to be distributed among the multiple request queues 240. In particular, in some situations, a request queue 240 receives only one type of data retrieval request (e.g., a prefetch request) from different processors 204 in the same processing cluster 202.

[0028] Each request queue 240 includes a number of memory access requests for accessing a memory system of the SOC 102, including the core cache 208, the cluster cache 210, the cache 220, and the memory 104. In some implementations, based on the type of information requested, each memory access request queue 240 includes one of a data translation queue, an instruction translation queue, and a prefetch translation queue. The data translation queue includes a number of data address mapping requests for translating a virtual address associated with data, the data being retrieved from the memory system of the SoC 102 using the translated virtual address. The instruction translation queue includes a number of instruction address mapping requests for translating a virtual address associated with an instruction, the instructions being retrieved from the memory system of the SoC 102 using the translated virtual address. The prefetch translation queue includes a number of address mapping requests for translating a virtual address associated with an instruction, the instructions being retrieved from the memory system of the SoC 102 using the translated virtual address. The prefetch translation queue includes a number of address mapping requests for translating a virtual address associated with an instruction opcode, which is applied to fetch an instruction opcode from the memory system in advance, the prefetch translation queue. The instruction opcodes are retrieved from the memory system of the SoC 102 using the pre-translated virtual addresses to be processed by the processors 204 in each processing cluster 202 .

[0029] Each processing cluster 202 includes or is coupled to one or more IFUs 212 within the processor 204. The one or more IFUs 212 are configured to prefetch, decode, and / or prepare upcoming instructions in parallel with the execution of current instructions. In some implementations, each processor 204 in a processing cluster 202 includes or is coupled to a respective IFU 212 to control cache fetching (including cache prefetching) associated with the respective processor 204. In some implementations, two or more of the processors 204 in a processing cluster 202 share the same IFU 212. Each IFU 212 may include any of a demand fetcher for fetching instructions and associated data for demand requests and a prefetcher for fetching instructions and associated data for prefetch requests. In one example, IFU 212 issues a data fetch request (possibly a demand request or a prefetch request) associated with an instruction, which is received at processor 204 of processing cluster 202. The data fetch request includes an address translation request, which includes address information for translating a virtual address to a physical address, and is applied to retrieve data from memory 104. In response to the data fetch request, processor 204 may implement a virtual-to-physical address translation or mapping, thereby identifying, for example, a page entry in a page table. The associated address translation request is queued in a data translation queue in one or more memory access request queues 240.

[0030] 2, each processor 204 includes a prefetch engine separate from the IFU 212. The prefetch engine is configured to perform prefetching, in which upcoming instructions and associated data are fetched in advance while a current instruction is being executed by the respective processor 204.

[0031] In some implementations, each processor 204 includes a rename / retire / dispatch unit (REU) 214, a load / store unit (LSU) 216, and a memory management unit (MMU) 218. Alternatively, in some implementations, two or three processors 204 share the REU 214, the LSU 216, the MMU 218, or a subset thereof. The LSU 216 is configured to generate virtual addresses for loading and storing operations on data and instructions, load data from the memory 104 of the SoC 102, and store data from registers 222 to the memory 104 of the SoC 102. The REU 214 is configured for register renaming, and instruction retirement and dispatching. The MMU 218 is configured to manage memory accesses based on one or more memory access request queues 240. In some implementations, the MMU 218 cooperates with the LSU 216 or the REU 214 to manage speculative memory accesses during a synchronization event. The virtual addresses generated by the LSU 216 are associated with memory access requests in one or more memory access request queues 240. In response to the onset of a synchronization event (e.g., a context or data synchronization event), the REU 214 or the LSU 216 generates a purge instruction to purge translations of the speculative memory access requests in the one or more memory access request queues 240. In response to the purge instruction, the MMU 218 identifies the speculative memory access requests in the memory access request queues 240 and purges the address translations or mappings associated with the speculative memory access requests from the queues 240.

[0032] FIG. 3A illustrates a block diagram of a hypervisor 310 for hosting virtual machines 320 on a system module 100 according to some implementations. The system module 100 includes hardware supporting the hypervisor 310, such as the electronic device 200 and memory 104. The electronic device 200 includes a cache 330 (including caches 208, 210, and 220 shown in FIG. 2). The hypervisor 310 hosts one or more virtual machines 320 (e.g., virtual machines 320-1 through 320-m), each of which executes a respective guest operating system (OS) 324 and one or more respective guest applications 322. For example, as illustrated in FIG. 3A, the hypervisor 310 hosts m virtual machines 320. The first virtual machine 320-1 executes the guest OS 324-1 and guest applications 322-1-322-p, and the second virtual machine 320-2 executes the guest OS 324-2 and guest applications 326-1-326-p'. Each of the virtual machines 320 operates independently of the other virtual machines, despite being hosted by the same hypervisor 310. For example, the first virtual machine 320-1 and the second virtual machine 320-2 may be started or created at different times. In another example, the first virtual machine 320-1 may be stopped while the second virtual machine 320-2 remains operational. For example, the first virtual machine 320-1 may be stopped without tearing down the second virtual machine 320-2. In yet another example, the first virtual machine 320-1 may open, execute, or close any of the applications 322-1 to 322-p regardless of the second virtual machine 320-2 opening, executing, or closing any of the applications 326-1 to 326-p'.

[0033] Although each of the virtual machines 320 operates independently of the other, information required to execute each of the virtual machines 320, the respective guest OS 324, and the respective guest application 322 is stored in the memory 104. The virtual to physical address translations used in the execution of the virtual machines 320, the guest OS 324, and any guest applications 322 may be stored in the cache 330 of the system module 100. Thus, when a new virtual machine 320 is set up or a new application 322 is opened on the virtual machine 320, the new address translations are stored as cache entries in the cache 330. Additionally, when the virtual machine 320 is stopped or an application 322 on the virtual machine 320 is closed, a TLB invalidation instruction is sent to the cache 330 to invalidate cache entries associated with the stopped virtual machine 320 or the guest application closed on the virtual machine 320, respectively.

[0034] In the family of Reduced Instruction Set Computer (RISC) architectures for computer processors, e.g., Advanced RISC Machines (ARM), software is divided into different modules, each having a respective level of access to the electronic device 200, which includes one or more processors 204, associated caches 330, and memory 104. However, each software module has a distinct level of privilege (also called an exception level (EL)) that can only change when the processor 204 takes or returns from an exception. Each exception level is numbered, with higher levels of privilege having higher numbers. For example, EL0, EL1, EL2, and EL3 correspond to increasing privilege levels for the guest application 322, guest OS 324, hypervisor 310, and firmware layer, respectively.

[0035] 3B is a flow diagram of a one-stage table walk process 380 for fetching data by a processing cluster 202 (e.g., by an IFU 212 of a first processing cluster 202-1 of FIG. 2) according to some implementations. For each processing cluster 202, the memory access queue 240 includes an ordered sequence of memory access requests, each memory access request including an address translation request 308 requesting translation of a virtual address associated with a respective application 322 executed on a guest OS 324 of a virtual machine 320. The virtual address is translated to a physical address 390 according to the one-stage table walk process 380. In this example, the address translation information for each memory access request is stored in a multi-level hierarchy (i.e., TLB 370) including at least one level 0 table, multiple level 1 tables, multiple level 2 tables, and multiple level 3 tables. The level 0 table stores page entries including a table descriptor that identifies a particular level 1 table (e.g., a particular table of a plurality of level 1 tables, a first table of a plurality of level 1 tables), the level 1 table stores page entries including a table descriptor that identifies a particular level 2 table (e.g., a particular table of a plurality of level 2 tables, a first table of a plurality of level 2 tables), the level 2 table stores page entries including a table descriptor that identifies a particular level 3 table (e.g., a particular table of a plurality of level 3 tables, a first table of a plurality of level 3 tables), and the level 3 table stores page entries including a table descriptor that identifies a particular page table 360 ​​in memory 104. The table walk process 380 starts in the level 0 table and continues until the requested data 390 stored in a page entry in memory 104 (e.g., a page table 360 ​​in memory 104) is identified.

[0036] The data fetch process begins with a processor (e.g., processor 204-1) of a processing cluster (e.g., processing cluster 202-1) receiving an address translation request 308 that includes a virtual address 312 to be translated. The virtual address 312 includes a translation table base register (TTBR) that identifies a level 0 table at which the processor's data fetcher (e.g., IFU 212-1 of processor 204-1) can begin a table walk process 380. The table walk process 380 is initiated following a determination that requested data 390 (e.g., data requested by address translation request 308) is not stored in TLB 370 (e.g., a TLB "miss").

[0037] In particular, the IFU 212 begins the table walk process 380 by identifying a first table descriptor 314 stored in a page table entry in the level 0 table 316. The first table descriptor 314 includes information identifying a level 1 table 318 (e.g., a particular level 1 table) for which the IFU 212 can query to continue the table walk process 380. In some implementations, at least a portion of the virtual address 312 (e.g., first portion 312-1) is used to discover the first table descriptor 314 in the level 0 table 316. For example, the first portion 312-1 of the virtual address 312 may include a reference to a page table entry in the level 0 table 316 that stores the first table descriptor 314.

[0038] The IFU 212 identifies a level 1 table 318 based on the first table descriptor 314 obtained (e.g., output) from the level 0 table 316 and identifies a second table descriptor 332 stored in a page table entry in the level 1 table 318. The second table descriptor 332 includes information identifying a level 2 table 340 (e.g., a particular level 2 table) for which the IFU 212 can query to continue the table walk process 380. In some implementations, at least a portion of the virtual address 312 (e.g., the second portion 312-2) is used to discover the second table descriptor 332 in the level 1 table 318. For example, the second portion 312-2 of the virtual address 312 may include a reference to a page table entry in the level 1 table 318 that stores the second table descriptor 332. In some implementations, in addition to providing the second table descriptor 332, the level 1 table 318 also provides a first block descriptor 334 that identifies a first contiguous portion 390-1 within the memory 104, e.g., the first contiguous portion 390-1 within the memory 104 in which the requested data 390 is stored.

[0039] The IFU 212 identifies a level 2 table 340 based on the second table descriptor 332 obtained from the level 1 table 318, and identifies a third table descriptor 342 stored in a page table entry in the level 2 table 340. The third table descriptor 342 includes information identifying a level 3 table 350 (e.g., a particular level 3 table) for which the IFU 212 can query to continue the table walk process 380. In some implementations, at least a portion of the virtual address 312 (e.g., the third portion 312-3) is used to discover the third table descriptor 342 in the level 2 table 340. For example, the third portion 312-3 of the virtual address 312 may include a reference to a page table entry in the level 2 table 340 that stores the third table descriptor 342. In some implementations, in addition to providing (e.g., outputting) the third table descriptor 342, the level 2 table 340 also provides a second block descriptor 344 that identifies a second contiguous portion 390-2 in the memory 104 (e.g., the second contiguous portion 390-2 in the memory 104 in which the requested data 390 (e.g., the requested address translation) is stored). In some implementations, the second contiguous portion 390-2 in the memory 104 includes a smaller portion of the memory 104 compared to the first contiguous portion 390-1 in the memory 104, which includes the second contiguous portion 390-2 in the memory 104. For example, the first contiguous portion 390-1 in the memory 104 includes 16 MB of space in the memory 104, and the second contiguous portion 390-2 in the memory 104 includes 32 KB of space in the memory.

[0040] The IFU 212 identifies a level 3 table 350 based on the third table descriptor 342 obtained (e.g., output) from the level 2 table 340 and identifies a page descriptor 352 stored in a page table entry in the level 3 table 350. The page descriptor 352 includes information identifying a page table 360 ​​in memory 104 for which the IFU 212 can query to continue the table walk process 380. In some implementations, at least a portion of the virtual address 312 (e.g., the fourth portion 312-4) is used to find the page descriptor 352 in memory 104. For example, the fourth portion 312-4 of the virtual address 312 may include a reference to a page table entry in the level 3 table 350 that stores the page descriptor 352.

[0041] The IFU 212 queries a page table 360 ​​in memory 104, as identified by a page descriptor 352 output from the level 3 table 350, to find a page entry 362 that stores the requested data 390 (e.g., stores a requested virtual to physical address translation). In some implementations, at least a portion of the virtual address 312 (e.g., the fifth portion 312-5) is used to find the page entry 362 in the page table 360. For example, the fifth portion 312-5 of the virtual address 312 may include a reference to a byte on the page table 360 ​​that stores the requested data 390. Thus, using a table walk process 380, the IFU 212 of a processor (e.g., the IFU 212-1 of the processor 204-1) can obtain the requested data 390 (e.g., the requested address translation 380, the physical address 390 corresponding to the request 308) and pass the requested data 390 to the processor. However, the table walk process 380 introduces latency into system operation. Thus, in some embodiments, the table walk process 380 is skipped or bypassed for each speculative memory access request queued in the memory access request queue 240 in anticipation of one or more instructions being received following a request for a synchronization event.

[0042] 4 is an exemplary sequence of instructions 400 implemented to enable a context synchronization event according to some implementations. A context synchronization event corresponds to the termination of a first application 322-1 in a guest OS 324 to start a second application 322-2, the termination of a first virtual machine 320-1 to start a second virtual machine 320-2, or a system call to update a system register 222. In some implementations, an instruction set architecture (ISA) is part of the hypervisor 310 of the system module 100 and defines how the processor 204 is controlled by software. In a context synchronization event, the ISA includes a set of instructions 400 configured to require translation, for example, for a table walk of speculative memory access requests in the memory access queue 240, and a consistent view of the translation control system register 222. For example, a virtual to physical address translation retains the same address space identification (ASID) during the entire life cycle of the translation.

[0043] In some implementations, the "SVC" request 402 for a context synchronization event includes a supervisor call from a first exception level EL0 to a second exception level EL1, followed by an "ISB" barrier instruction 404 configured to force memory access completion to initiate the context synchronization event. The barrier instruction 404 creates an instruction synchronization barrier (ISB) that forces memory access ordering and access completion at a particular point in time. The barrier instruction 404 ensures that all instructions that come after the ISB instruction in program order are fetched from the cache or memory after the ISB instruction completes. The use of the ISB ensures that the effects of context changing operations performed before the ISB are visible to instructions fetched after the ISB instruction. In some implementations, a context changing operation requires the insertion of an ISB instruction to ensure that the effects of the operation are visible to instructions fetched after the ISB instruction. Examples of such context changing operations include, but are not limited to, completed cache and TLB maintaining instructions, and changes to system registers. Any context changing operations that occur in program order after the ISB instruction 404 take effect only after the ISB is executed.

[0044] For example, each memory access request queue 240 includes an ordered sequence of memory access requests, including a subset of speculative memory access requests 406 that are queued in anticipation of one or more instructions received following request 402. The speculative memory access requests 406 possibly include one or more prefetch instructions for loading instructions 406A-406C or associated data to be processed following a context synchronization event. In some circumstances, these prefetch instructions are intended to fetch instructions and associated data for a second application 322-2 or a second virtual machine 320-2 for which a context synchronization event is intended to commence. Because the cache 330 of the system module 100 has not been purged and reloaded based on the second application 322-2 or the second virtual machine 320-2, the instructions and associated data fetched for the prefetch instructions are stale or inconsistent and cannot be used to implement the second application 322-2 or the second virtual machine 320-2.

[0045] In particular, in response to the request 402 for a context synchronization event, the processor 204 identifies a subset of the speculative memory access requests 406 and automatically purges the address translations associated with the subset of the speculative memory access requests 406. The context synchronization event is initiated regardless of whether the subset of the speculative memory access requests 406 is purged. Although, the context synchronization event may be initiated after, during, or before the subset of the speculative memory access requests 406 is purged. In some circumstances, the prefetch instructions are intended to fetch instructions and associated data for the second application 322-2 or the second virtual machine 320-2, and the speculative memory access requests 406 related to these prefetch instructions are purged. Given that these prefetch instructions provide stale instructions and data associated with the first application 322-1 or the first virtual machine 320-1, purging the speculative memory access requests 406 related to these prefetch instructions improves memory access efficiency and facilitates context synchronization events.

[0046] 4, in one example, a request 402 for a context synchronization event includes a supervisor call to terminate the first application 322-1 and start the second application 322-2. The supervisor call is made from the first exception level EL0 to the second exception level EL1, i.e., from the first application 322-1 to the operating system 324. The supervisor call is followed by a regime instruction 408 to maintain the translation regime and a register update instruction 410 to update the translation base register 222 from the first application 322-1 (e.g., ASID=A) to the second application 322-2 (e.g., ASID=B). A barrier instruction 404 is applied to create an instruction synchronization barrier (ISA) and to ensure that new instructions received after the context synchronization event are processed in the context of the second application 322-2. The barrier instruction 404 is followed by an application load instruction 406A, an exception level instruction 406B, and a regime instruction 406C, which are associated with a second application 322-2.

[0047] In some circumstances, multiple speculative memory access requests 406 are queued in anticipation of instructions 406A-406C. In response to the request 402, the processor 204 aborts performing address translations of the speculative memory access requests 406 while completing the barrier instruction 404 within a first number of clock cycles. In contrast, if the address translations of the speculative memory access requests 406 are not aborted, the address translations are configured to be completed within a second number of clock cycles. The first number is less than the second number. Nevertheless, by purging translations associated with a subset of the speculative memory access requests 406, a context synchronization event is facilitated by bypassing the speculative memory access requests 406 that may provide stale or inconsistent instructions or data.

[0048] 5 is another exemplary sequence of instructions 500 configured to enable a data synchronization event according to some implementations. The data synchronization event is implemented to enable a higher exception level to be able to safely update a translation control system register 222 associated with a lower exception level. For example, in a data synchronization event, the hypervisor 310 (EL2) updates the associated translation control system register 222 associated with a virtual machine 320, an application 322, or an operating system 324 when a context synchronization event occurs, for example, to switch between two virtual machines 320, two applications 322, or two operating systems 324, respectively. In some implementations, when a data synchronization event is executed from the hypervisor (EL2) or firmware (EL3), a speculative address translation or table walk to a lower exception level (e.g., EL1 or EL0) is terminated. When the system register 222 associated with the translation control is updated, the address translation (i.e., the speculative address translation or table walk) for one or more speculative memory accesses is purged.

[0049] In some implementations, an "HVC" request 502 is received via a hypervisor call, which is made from a guest application 322 or guest operating system 324 to the hypervisor 310 to initiate a data synchronization event. The request 502 is followed by a barrier instruction 504 configured to force memory access completion to initiate a data synchronization event. The barrier instruction 504 includes one or more data synchronization barriers 504A and 504B that execute on the hypervisor layer (EL2) or firmware layer (EL3) to force memory access completion of a speculative memory access request to the operating system level (EL1) or application level (EL0). In one example, each barrier instruction includes a hypervisor call from the hypervisor 310 or guest operating system 324. In particular, each barrier instruction 504 creates a data synchronization barrier (DSB). The DSB blocks execution of further instructions, rather than just loading or storing, until synchronization is completed. In some circumstances, the DSB also waits until all cache, TLB, and branch predictor maintenance operations (e.g., speculative memory accesses) issued by the processor 204 have completed. Conversely, in some implementations, the DSB purges any translations of any speculative memory accesses.

[0050] Each memory access request queue 240 includes an ordered sequence of memory access requests, including a subset of speculative memory access requests 506 that are queued in anticipation of one or more instructions being received following a request 502. In response to a request 502 for a data synchronization event, the processor 204 identifies the subset of speculative memory access requests 506 and automatically purges address translations associated with the subset of speculative memory access requests 506. The data synchronization event is initiated before, after, or during the subset of speculative memory access requests 506 is purged. In some circumstances, prefetch instructions are issued to fetch instructions 506A-506B and associated data that will be applied after the data synchronization event, and the speculative memory access requests 506 related to these prefetch instructions are purged. These prefetch instructions provide stale instructions and data associated with caches, TLBs, and memories that have not been updated, and by purging speculative memory access requests 506 related to these prefetch instructions, memory access efficiency is improved and data synchronization events are facilitated.

[0051] 5, in one example, a request 502 for a data synchronization event includes a hypervisor call from a guest (e.g., operating system 324 or application 326) to hypervisor 310. The hypervisor call is followed by a regime instruction 508 to maintain the translation regime and a probing instruction 510 to probe the translation regime by hypervisor 310. Two barrier instructions 504 are applied to create a data barrier that ensures that address translation is completed and that page table entries (PTEs) are updated and globally observable. The barrier instructions 504 are followed by an exception level instruction 506A and a regime instruction 506B. In some circumstances, multiple speculative memory access requests 506 are queued in anticipation of instructions 506A-506B.

[0052] In some implementations, in response to the request 502, the processor 204 aborts performing address translations of the speculative memory access requests 506 while completing the barrier instruction 504 within a first number of clock cycles. In contrast, if the address translations of the speculative memory access requests 506 are not aborted, the address translations are configured to be completed within a second number of clock cycles. The first number is less than the second number. Nonetheless, by purging translations associated with a subset of the speculative memory access requests, a data synchronization event is facilitated by bypassing the speculative memory access requests 506 that may provide stale (e.g., inconsistent) instructions or data.

[0053] FIG. 6A is a flow diagram of an exemplary address translation process 600 implemented in a context synchronization event according to some implementations, and FIG. 6B is a sequence of exemplary instructions 620 configured to update a system register 222 according to some implementations. The processor 204 of the SoC 102 orchestrates a synchronization event that purges address translations of speculative memory accesses (i.e., speculative address translations) without stalling the completion of the synchronization event. The speculative memory accesses are marked, for example, as “purged with null response” in the corresponding memory access queue 240 maintained in the cache 210. The address translations associated with the speculative memory access requests are automatically purged (i.e., terminated early) according to the determination that each speculative memory access request is marked. The processor 204 does not fill any translation caching structures (e.g., TLB 370, page table 360). When data is fetched by a speculative memory access request, it cannot be consumed by the IFU 212, the REU 214, the LSU 216, or the MMU 218.

[0054] In particular, the REU 214 and MMU 218 of the processor 204 are coordinated with each other to complete a context synchronization event in which speculative address translations are purged. Upon receiving a request for a context synchronization event, the REU 214 generates a barrier instruction to create an ISB. In response to the barrier instruction, the REU 214 generates a purge instruction to purge translations of a subset of the speculative memory access requests. The MMU 218 identifies a subset of the speculative memory access requests in the memory access queue 240 and purges translations associated with the subset of the speculative memory access requests. These purged translations include data translations 602, instruction translations 604, prefetch translations 606, or combinations thereof. Alternatively, in some implementations, the one or more memory access request queues 240 include a data translation queue, an instruction translation queue, and a prefetch translation queue. The MMU 218 identifies a subset of the speculative memory access requests in each of the data translation queue, the instruction translation queue, and the prefetch translation queue. The speculative memory access request includes at least one memory access request in the data, instruction, and prefetch translation queues, and an associated address translation is purged.

[0055] 6B, in one example, a request 608 for a context synchronization event is received by the REU 214. In response, the REU 214 begins a handshaking process by issuing a barrier instruction 610 that creates an ISB. Speculative address translations associated with subsequent instructions 612 are purged to avoid long latency table walks that may return inconsistent or stale instructions and associated data that are not usable in subsequent processing.

[0056] FIG. 6C is a flow diagram of another exemplary address translation process 640 implemented in a data synchronization event according to some implementations, and FIG. 6D is a sequence of exemplary instructions 660 configured to update system registers 222 and complete a table walk according to some implementations. The LSU 216 and MMU 218 of the processor 204 are coordinated with each other to complete a data synchronization event in which speculative address translations are purged. Upon receiving a request for a data synchronization event, the LSU 216 generates a barrier instruction to create a DSB. In response to the barrier instruction, the LSU 216 generates a purge instruction to purge translations of a subset of the speculative memory access requests. The MMU 218 identifies a subset of the speculative memory access requests in the memory access queue 240 and purges the translations associated with the subset of the speculative memory access requests. These purged translations include data translations 642, instruction translations 644, prefetch translations 646, or a combination thereof. Alternatively, in some implementations, the one or more memory access request queues 240 include a data translation queue, an instruction translation queue, and a prefetch translation queue. The MMU 218 identifies a subset of the speculative memory access requests in each of the data translation queue, the instruction translation queue, and the prefetch translation queue. The speculative memory access requests include at least one memory access request in the data, instruction, and prefetch translation queues, and associated address translations are purged.

[0057] 6D , in one example, a request 648 for a data synchronization event is received by LSU 216. In response, LSU 216 begins a handshaking process by issuing a barrier instruction 650 that creates a DSB. Speculative address translations associated with subsequent instructions 652 are purged to avoid long latency table walks that may return inconsistent or stale instructions and associated data that are not usable in subsequent processing.

[0058] 7 is a flow diagram of a process 700 for controlling latency in synchronization events according to some implementations. The process 700 is performed by a processor 204 of a system module 100 having one or more processors 204 and a memory system. The memory system of the system module 100 includes a core cache 208 of each processor 204, a cluster cache 210 accessible to the multiple processors 204 of the processing cluster 202, a cache 220 accessible to the multiple processing clusters 202, and a memory 104 (e.g., DRAM). In some cases, the cluster cache 210 stores one or more memory access queues 240 for the processors 204 coupled to the cluster cache 210. The process 700 expedites and reduces the latency of synchronization events by skipping conversion of speculative memory accesses in the one or more memory access queues 240.

[0059] The processor 204 receives a request 402 for a context synchronization event or a request 502 for a data synchronization event (702). In some implementations, the context synchronization event corresponds to an application ASID change (i.e., the termination of a first application 322-1 to start a second application 322-2), a virtual machine VMID change (i.e., the termination of a first virtual machine 320-1 to start a second virtual machine 320-2), or a system call to update a system register 222. This context synchronization event is possibly triggered by one or more of page table management, a system call, and an exception return. Alternatively, in some implementations, the data synchronization event updates a register 222 associated with a virtual machine 320 implemented on the processor 204. In response to the request 402 or 502, the processor 204 issues a request (e.g., including a barrier instruction) to force a memory access completion (704). The request is sent to each cache 208, 210, or 220 (706). The processor 204 identifies the speculative memory access requests in one or more memory access queues 240 and marks each speculative memory access request, for example, with a flag (708). An exemplary flag is "purged without response." The processor 204 automatically purges the address translations associated with the speculative memory access requests according to the determination that each speculative memory access request has been marked (710). In some implementations, these address translations are terminated early (712) and the processor 204 does not fill any translation caching structures (e.g., TLB, table walk cache) (714). When data is fetched by a speculative memory access request, it cannot be applied by the IFU 212, REU 214, LSU 216, or MMU 218 of the same processor 204 or any other processor 204 (716). The synchronization event may be initiated independently of the purge of the transform, for example, before, after, or simultaneously with the purge of the transform (718).In other words, in some situations, a synchronization event is initiated without waiting for a transformation to start or complete.

[0060] The process 700 terminates the speculative address translation at the time of the synchronization event, thereby allowing the synchronization event to be completed without being delayed by the latency caused by the speculative address translation. In one example, the synchronization event (e.g., ISB or DSB) completes in 10 clock cycles and may extend beyond 1000 clock cycles if the long latency speculative address translations are not purged. During the process of purging the speculative address translations, the system registers 222 do not need to be sampled and copied across the translation units, and processing resources may be reserved to perform heavy operating system or hypervisor context switching, page table management, and system calls. By these means, the power consumption and performance of the SoC 102 at the time of the synchronization event is improved by skipping the speculative address translation.

[0061] It should be understood that the particular order in which the operations in FIG. 7 are described is merely an example and is not intended to indicate that the described order is the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. Additionally, it should be noted that other process details described herein with respect to FIGS. 1-6D and 8 may also be applied in an interchangeable manner to process 700. For the sake of brevity, these details will not be repeated here.

[0062] 8 is a flow diagram of a method 800 for managing memory accesses according to some implementations. The method 800 is implemented in a respective processor 204 of one or more processors 204 configured to execute one or more virtual machines 320. The one or more processors 204 are disposed in one or more processing clusters 202. The respective processor 204 (e.g., a first processor 204-1 of a first cluster 202-1) receives a request to initiate a synchronization event (802). In response to the request (804), the respective processor 204 identifies (806) a subset of speculative memory access requests in one or more memory access request queues 240 and automatically purges (808) translations associated with the subset of speculative memory access requests in accordance with the identification. The respective processor 204 initiates (810) a synchronization event. In some embodiments, the synchronization event is initiated 810 independently of the purge of transforms (808), for example, before, after, or simultaneously with the purge of transforms.

[0063] In some implementations, each memory access request queue 240 includes an ordered sequence of memory access requests, and a subset of the speculative memory access requests are queued in anticipation of one or more instructions being received following the request (812). Further, in some implementations, receiving the request includes receiving a barrier instruction configured to force memory access completion (814). In response to the request, each processor 204 aborts address translation of the subset of the speculative memory access requests and completes the barrier instruction within a first number of clock cycles (816). The translation associated with the subset of the speculative memory access requests is configured to be completed within a second number of clock cycles, the first number being less than the second number (818).

[0064] In some implementations, each processor 204 is associated with a translation cache and, for each speculative memory access request, initiates a synchronization event by terminating the corresponding memory access request to read or write the respective data item from or to the respective memory unit, ceasing to fill the translation cache associated with the respective processor, and suspending the respective processor's use of the respective data item. Further, in some implementations, the translation cache includes a translation lookaside buffer (TLB) 370 and a page table cache 360. Further, in some implementations, each processor includes one or more of an instruction fetch unit (IFU) 212 for fetching instructions and associated data from a first memory to a second memory that is faster than the first memory; a load / store unit (LSU) 216 for executing load and store instructions and generating virtual addresses; a rename / retire / dispatch unit (REU) 214 for register renaming and instruction retirement and dispatching; a memory management unit (MMU) 218 ​​for managing memory accesses to the caches and memories of the one or more processors; and a prefetch engine for fetching instructions or data from the first memory to the second memory in advance of the use of the respective data items by the IFU 212, LSU 216, REU 214, MMU 218, and prefetch engine of each processor.

[0065] In some implementations, each processor 204 includes a memory management unit (MMU) 218 ​​configured to manage one or more memory access request queues 240. In response to the request, each processor 204 generates a purge instruction to purge translations of a subset of the speculative memory access requests. The MMU 218 identifies a subset of the speculative memory access requests in the one or more memory access queues and purges translations associated with the subset of the speculative memory access requests.

[0066] In some implementations, the subset of speculative memory access requests is identified by marking each of the subset of speculative memory access requests with a flag (e.g., "purged with null response.") Translations associated with the subset of speculative memory access requests are automatically purged in accordance with the determination that each speculative memory access request is associated with a flag.

[0067] In some implementations, the one or more memory access request queues 240 include a data conversion queue, an instruction conversion queue, and a prefetch conversion queue, and the subset of speculative memory access requests includes at least one memory access request in the data, instruction, and prefetch conversion queues 240.

[0068] In some implementations, each processor 204 receives (820) a barrier instruction configured to force a memory access completion to initiate a context synchronization event, the context synchronization event corresponding to a termination of a first application to start a second application, a termination of a first virtual machine to start a second virtual machine, or a system call to update a system register 222.

[0069] Alternatively, in some implementations, each processor 204 receives a barrier instruction configured to force memory access completion to initiate a data synchronization event to update registers associated with a virtual machine implemented on the respective processor (822). The barrier instruction includes a data synchronization barrier executed at the hypervisor or firmware layer to force memory access completion of a speculative memory access request to the operating system or application level. Additionally, in some embodiments, the barrier instruction includes a hypervisor call from a guest operating system (824).

[0070] It should be understood that the particular order in which the operations in FIG. 8 have been described is merely an example, and is not intended to indicate that the described order is the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. Additionally, it should be noted that other process details described herein with respect to FIGS. 1-7 may also be applied in an interchangeable manner to method 800. For the sake of brevity, these details will not be repeated here.

[0071] Example implementations are described in at least the following numbered clauses:

[0072] Clause 1. A method for managing memory access, implemented in each of one or more processors configured to execute one or more virtual machines, comprising: receiving a request to initiate a synchronization event; identifying, in response to the request, a subset of speculative memory access requests in one or more memory access request queues; automatically purging translations associated with the subset of the speculative memory access requests in accordance with the identification; and initiating the synchronization event.

[0073] Clause 2. The method of clause 1, wherein each memory access request queue includes an ordered sequence of memory access requests, and a subset of speculative memory access requests are queued in anticipation of one or more instructions being received following the request.

[0074] Clause 3. The method of any of the preceding clauses, wherein receiving a request includes receiving a barrier instruction configured to force memory access completion, and the method further includes, in response to the request, aborting address translation for a subset of the speculative memory access requests and completing the barrier instruction within a first number of clock cycles, wherein translation associated with the subset of the speculative memory access requests is configured to be completed within a second number of clock cycles, the first number being less than the second number.

[0075] Clause 4. The method of any of clauses 1-3, wherein each processor is associated with a translation cache, and the step of initiating a synchronization event further comprises, for each speculative memory access request, terminating a corresponding memory access request to read the respective data item from or write the respective data item to the respective memory unit, ceasing to fill the translation cache associated with the respective processor, and suspending use of the respective data item by the respective processor.

[0076] Clause 5. The method of clause 4, wherein the translation cache includes a translation lookaside buffer (TLB) and a page table cache.

[0077] Clause 6. The method of clause 4 or 5, wherein each processor includes one or more of an instruction fetch unit (IFU) for fetching instructions and associated data from a first memory to a second memory that is faster than the first memory, a load / store unit (LSU) for executing load and store instructions and generating virtual addresses, a rename / retire / dispatch unit (REU) for register renaming and instruction retirement and dispatching, a memory management unit (MMU) for managing memory accesses to the caches and memories of the one or more processors, and a prefetch engine for fetching instructions or data from the first memory to the second memory in advance of the use of the respective data items by the IFU, LSU, REU, MMU, and prefetch engine of each processor.

[0078] Clause 7. The method of any of the preceding clauses, wherein each processor includes a memory management unit (MMU) configured to manage one or more memory access request queues, and the method further includes the step of generating, in response to a request, by each processor, a purge instruction for purging translations of a subset of the speculative memory access requests, wherein the MMU identifies a subset of the speculative memory access requests in the one or more memory access request queues and purges translations associated with the subset of the speculative memory access requests.

[0079] Clause 8. The method of any preceding clause, wherein identifying a subset of the speculative memory access requests includes marking each of the subset of the speculative memory access requests with a flag, and wherein translations associated with the subset of the speculative memory access requests are automatically purged pursuant to a determination that each speculative memory access request is associated with a flag.

[0080] Clause 9. The method of any of the preceding clauses, wherein the one or more memory access request queues include a data conversion queue, an instruction conversion queue, and a prefetch conversion queue, and the subset of speculative memory access requests includes at least one memory access request in the data, instruction, and prefetch conversion queues.

[0081] Clause 10. The method of any of clauses 1-9, wherein the method further includes receiving a barrier instruction configured to force a memory access completion to initiate a context synchronization event, the context synchronization event corresponding to a termination of a first application to initiate a second application, a termination of a first virtual machine to initiate a second virtual machine, or a system call to update a system register.

[0082] Clause 11. The method of any of clauses 1-9, wherein the method further comprises receiving a barrier instruction configured to force memory access completion to initiate a data synchronization event to update registers associated with a virtual machine implemented on a respective processor, the barrier instruction comprising a data synchronization barrier executed on a hypervisor layer or a firmware layer to force memory access completion of a speculative memory access request to an operating system level or an application level.

[0083] Clause 12. The method of clause 11, wherein the barrier instruction includes a hypervisor call from the guest operating system.

[0084] Clause 13. An electronic device comprising one or more processors configured to run one or more virtual machines, each processor configured to perform the method of any of clauses 1 to 12.

[0085] Clause 14. A non-transitory computer-readable storage medium storing one or more programs configured for execution by respective ones of one or more processors configured to execute one or more virtual machines, the one or more programs including instructions that, when executed by the respective processors, cause the respective processors to perform the method of any of clauses 1 to 12.

[0086] Clause 15. An apparatus for managing memory access in each of one or more processors configured to execute one or more virtual machines, the apparatus comprising means for performing the method in any of clauses 1 to 12.

[0087] The above description has been provided with reference to specific implementations. However, the above illustrative description is not intended to be exhaustive or to be limited to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The implementations have been chosen and described to best explain the disclosed principles and their practical applications, and thereby enable others to best utilize the present disclosure and various implementations with various modifications as suited to the particular use contemplated.

[0088] The terms used in the description of the various described implementations herein are merely for the purpose of describing the particular implementations and are not intended to be limiting. The singular forms "a", "an" and "the" used in the description of the various described implementations and the appended claims are intended to include the plural unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes", "including", "comprises" and / or "comprising" as used herein specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, it will be understood that terms such as "first", "second" and the like may be used herein to describe various elements, but these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

[0089] The term "if" as used herein is to be interpreted to mean "when" or "upon" or "in response to determining" or "in response to detecting" or "in accordance with a determination that," as the case may be, depending on the context. Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" is to be interpreted to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]" or "in accordance with a determination that [a stated condition or event] is detected," as the case may be, depending on the context.

[0090] The above description has been described with reference to specific embodiments for purposes of explanation. However, the above illustrative description is not intended to be exhaustive or to limit the scope of the claims to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments were chosen and described in order to best explain the principles of operation and practical application, thereby enabling others skilled in the art.

[0091] Although various figures show some logical steps in a particular order, steps that are not order dependent may be reordered and other steps may be combined or separated. While some reordering or other groupings are described in detail, others will become apparent to those of ordinary skill in the art, and the reordering and groupings presented herein are not an exhaustive list of alternatives. Moreover, it should be recognized that the steps may be implemented in hardware, firmware, software, or any combination thereof. [Explanation of symbols]

[0092] 100 System Module 102 System on Chip (SoC), SoC, SOC 104 Memory module, memory 106 Input / Output (I / O) Controller, I / O Controller 108 Network Interface 110 Memory controller, component 112 Solid State Drive (SSD), Components, SSD 114 Hard Drive, Components 116 Power connector, components 118 Power Management Integrated Circuits (PMIC), Components, PMIC 120 Graphics module, components 122 Sound module, components 150 Communication Bus 200 Electronic Devices 202 Processing Cluster 202-1 first processing cluster, single processing cluster, processing cluster, first cluster 202-MM processing cluster, cluster 204, 206 processors 204-1 first processor, single processor, processor 204-NNth processor, processor 206-1 First Processor 206-N' N'th processor 208 Core Cache, Cache 210 Cluster Cache, Cache 210-1 First cluster cache 210-MM cluster cache 212 IFU, Instruction Fetch Unit (IFU) 212-1 IFU 214 Rename / Retire / Dispatch Unit (REU), REU 216 Load / Store Unit (LSU), LSU 218 Memory Management Unit (MMU), MMU 220, 330 Cash 222 Registers, System Registers, Conversion Control System Registers, Conversion Base Registers 232, 232-1 Filter 240 Request queue, memory access request queue, queue, memory access queue, data, instruction, and prefetch conversion queue 240-1 First request queue 240-MM Request Queue 308 Address translation request, request 310 Hypervisor 312 Virtual Address 312-1 First Part 312-2 Second part 312-3 Third Part 312-4 Fourth Part 312-5 Fifth Part 314 First Table Descriptor 316 Level 0 Table 318 Level 1 Table 320, 320-1 to 320-m Virtual Machines 320-1 First Virtual Machine 320-2 Second Virtual Machine 322, 322-1 to 322-p, 326-1 to 326-p' Guest applications, applications 322-1 First Application 322-2 Second Application 324 guest operating system (OS), guest OS, operating system, guest operating system 324-1, 324-2 Guest OS 326 Applications 332 Second Table Descriptor 334 First Block Descriptor 340 Level 2 Table 342 Third Table Descriptor 344 Second Block Descriptor 350 Level 3 Table 352 Page Descriptors 360 page tables, page table cache 362 page entries 370 TLB, Translation Lookaside Buffer (TLB) 380 One-step table walk process, table walk process, requested address translation 390 Physical address, requested data 390-1 First continuous part 390-2 Second continuous part 400, 500, 620, 660 instructions 402 "SVC" request, request 404 "ISB" Barrier command, Barrier command, ISB command 406, 506 Speculative memory access requests 406A instruction, application load instruction 406B, 506A instructions, exception level instructions 406C, 506B Orders, Regime Orders 408, 508 Regime Orders 410 Register Update Instructions 502 "HVC" request, request 504, 610, 650 Barrier Orders 504A, 504B Data Synchronization Barrier 510 Probing Command 600 Exemplary Address Translation Process 602, 642 Data conversion 604, 644 Instruction Conversion 606, 646 Prefetch Conversion 608, 648 request 612, 652 Subsequent orders 640 Another Exemplary Address Translation Process 700 processes

Claims

1. 1. A method for managing memory accesses, implemented in each of one or more processors configured to execute one or more virtual machines, comprising: receiving a request to initiate a synchronous event; In response to said request, identifying a subset of speculative memory access requests in one or more memory access request queues; automatically purging translations associated with a subset of the speculative memory access requests in accordance with the identification; initiating the synchronization event; Including, each of the processors includes a memory management unit (MMU) configured to manage the one or more memory access request queues, the method comprising: generating, in response to the request, by the respective processors, a purge instruction for purging translations of a subset of the speculative memory access requests, the MMU identifying the subset of the speculative memory access requests in the one or more memory access request queues and purging the translations associated with the subset of the speculative memory access requests. Further comprising: method.

2. 2. The method of claim 1, wherein each memory access request queue includes an ordered sequence of memory access requests, and a subset of the speculative memory access requests are queued in anticipation of one or more instructions being received following the request.

3. and wherein receiving the request includes receiving a barrier instruction configured to force a memory access completion, the method comprising: in response to the request, aborting address translation for a subset of the speculative memory access requests and completing the barrier instruction within a first number of clock cycles, wherein the translation associated with the subset of the speculative memory access requests is configured to be completed within a second number of clock cycles, the first number being less than the second number; The method of claim 2, further comprising:

4. Each processor is associated with a translation cache, and the step of initiating the synchronization event includes, for each speculative memory access request: completing a corresponding memory access request to read or write each data item from or to each memory unit; ceasing to fill the translation cache associated with the respective processor; reserving use of said respective data items by said respective processors; The method of claim 1, further comprising:

5. The method of claim 4 , wherein the translation cache includes a translation lookaside buffer (TLB) and a page table cache.

6. each of the processors includes one or more of an instruction fetch unit (IFU) for fetching instructions and associated data from a first memory to a second memory that is faster than the first memory; a load / store unit (LSU) for executing load and store instructions and generating virtual addresses; a rename / retire / dispatch unit (REU) for register renaming and instruction retirement and dispatching; a memory management unit (MMU) for managing memory accesses to caches and memories of the one or more processors; and a prefetch engine for fetching instructions or data from the first memory to the second memory in advance; The method of claim 4 , wherein the IFU, LSU, REU, MMU, and prefetch engine of the respective processor are reserved for use of the respective data item.

7. The method of claim 1, wherein the step of identifying a subset of the speculative memory access requests includes a step of marking each of the subset of the speculative memory access requests with a flag, and the translations associated with the subset of the speculative memory access requests are automatically purged purging a determination that each speculative memory access request is associated with the flag.

8. 2. The method of claim 1, wherein the one or more memory access request queues include a data conversion queue, an instruction conversion queue, and a prefetch conversion queue, and the subset of speculative memory access requests includes at least one memory access request in the data, instruction, and prefetch conversion queues.

9. The method further comprising: receiving a barrier instruction configured to force a memory access completion to initiate a context synchronization event; Further comprising:

2. The method of claim 1, wherein the context synchronization event corresponds to a termination of a first application to start a second application, a termination of a first virtual machine to start a second virtual machine, or a system call to update a system register.

10. The method further comprising: receiving a barrier instruction configured to force a memory access completion to initiate a data synchronization event for updating a register associated with a virtual machine implemented on the respective processor; Further comprising:

2. The method of claim 1, wherein the barrier instruction comprises a data synchronization barrier executed at a hypervisor layer or a firmware layer to force memory access completion of the speculative memory access request to an operating system level or an application level.

11. The method of claim 10 , wherein the barrier instruction comprises a hypervisor call from a guest operating system.

12. 1. An electronic device comprising one or more processors configured to execute one or more virtual machines, each processor comprising: Receiving a request to initiate a synchronization event; In response to said request, identifying a subset of speculative memory access requests in one or more memory access request queues; automatically purging translations associated with a subset of the speculative memory access requests in accordance with the identification; Initiating the synchronization event; configured to run each of the processors includes a memory management unit (MMU) configured to manage the one or more memory access request queues; generating, by the respective processor, in response to the request, a purge instruction for purging translations of a subset of the speculative memory access requests, wherein the MMU is configured to identify a subset of the speculative memory access requests in the one or more memory access request queues and to purge the translations associated with the subset of the speculative memory access requests. Electronic devices.

13. 13. The electronic device of claim 12, wherein each memory access request queue includes an ordered sequence of memory access requests, a subset of the speculative memory access requests being queued in anticipation of one or more instructions being received following the request.

14. and receiving the request includes receiving a barrier instruction configured to force a memory access completion, the respective processor: in response to the request, aborting address translation for a subset of the speculative memory access requests and completing the barrier instruction within a first number of clock cycles, wherein the translation associated with the subset of the speculative memory access requests is configured to be completed within a second number of clock cycles, the first number being less than the second number; The electronic device of claim 13 , further configured to execute:

15. The respective processor is associated with a translation cache, and the initiation of the synchronization event includes, for each speculative memory access request: completing a corresponding memory access request to read or write each data item from or to each memory unit; ceasing to fill the translation cache associated with the respective processor; and withholding use of said respective data items from said respective processors; The electronic device of claim 12 further comprising:

16. 16. The electronic device of claim 15, wherein the translation cache includes a translation lookaside buffer (TLB) and a page table cache.

17. 17. The electronic device of claim 16, wherein each of the processors includes one or more of an instruction fetch unit (IFU) for fetching instructions and associated data from a first memory to a second memory that is faster than the first memory, a load / store unit (LSU) for executing load and store instructions and generating virtual addresses, a rename / retire / dispatch unit (REU) for register renaming and instruction retirement and dispatching, and a prefetch engine for fetching instructions or data from the first memory to the second memory in advance, wherein the IFU, LSU, REU, MMU, and prefetch engine of each of the processors are reserved for use by the respective data items.

18. 1. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a respective one or more processors configured to execute one or more virtual machines, the one or more programs including instructions that, when executed by the respective processor, cause the respective processor to: Receiving a request to initiate a synchronization event; In response to said request, identifying a subset of speculative memory access requests in one or more memory access request queues; automatically purging translations associated with a subset of the speculative memory access requests in accordance with the identification; initiating the synchronization event; receiving a barrier instruction configured to force a memory access completion to initiate a data synchronization event to update a register associated with a virtual machine implemented on the respective processor; Run the command, The barrier instruction includes a data synchronization barrier executed at a hypervisor layer or a firmware layer to force memory access completion of the speculative memory access request to an operating system level or an application level. A non-transitory computer-readable storage medium.

19. 1. An apparatus for managing memory access in each processor of one or more processors configured to execute one or more virtual machines, comprising: means for receiving a request to initiate a synchronous event; In response to said request, identifying a subset of speculative memory access requests in one or more memory access request queues; automatically purging translations associated with a subset of the speculative memory access requests in accordance with the identification; initiating said synchronization event following said purging; and a means for performing said means for receiving a barrier instruction configured to force a memory access completion to initiate a data synchronization event for updating a register associated with a virtual machine implemented on the respective processor; Equipped with The barrier instruction includes a data synchronization barrier executed at a hypervisor layer or a firmware layer to force memory access completion of the speculative memory access request to an operating system level or an application level. Device.

Images