Patent Description:
Caching improves computer performance by keeping recently used or often used data items, such as references to physical addresses of often used data, in caches that are faster to access compared to physical memory stores. As new information is fetched from physical memory stores or caches, caches are updated to store the newly fetched information to reflect current and/or anticipated data needs. A computer system that hosts a one or more virtual machines, may store information related to functions or applications executed at each virtual machine in different caches across the computer system. Before a virtual machine is shut down, or before an application is closed on a virtual machine, the computer system has to 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 walks and register sampling operations delay shutting down the virtual machine and closing the application on the virtual machine. As such, it would be highly desirable to provide an electronic device or electronic system that manages memory access requests and associated address translations efficiently for one or more processors executing virtual machine(s).

<CIT> discloses systems and methods for dynamic designation of instructions as sensitive. Some methods include detecting that a first instruction of a first process has been designated as a sensitive instruction; checking whether a sensitive handling enable indicator in a process state register storing a state of the first process is enabled; responsive to detection of the sensitive instruction and enablement of the sensitive handling enable indicator, invoking a constraint for execution of the first instruction; executing the first instruction subject to the constraint; and executing a second instruction of the first process without the constraint. <CIT> discloses an apparatus with a translation cache comprising a number of entries for specifying address translation data. Each entry also specifies a translation context identifier associated with the address translation data and a realm identifier identifying one of a number of realms. Each realm corresponds to at least a portion of at least one software process executed by processing circuitry In response to a memory access a lookup of the translation cache is triggered. When the lookup misses in the cache, control circuitry prevents allocation of address translation data to the cache when the current realm is excluded from accessing the target memory region by an owner realm specified for the target memory region. In the lookup, whether a given entry matches the memory access depends on both a translation context identifier comparison and a realm identifier comparison. <CIT> discloses systems that, prior to execution of the application by a speculative execution engine, locate a sequence of instructions of the application in which the speculative execution engine executes the instructions out of sequence. The sequence of instructions may be an "if-then" code block. The systems determine a disposition that forces the speculative execution engine to execute the instructions in sequence. The disposition may be adding a fence instruction to the sequence of instructions. During execution of the application code by the speculative execution engine, the systems change the sequence of instructions based on the disposition. The systems execute the changed sequence of instructions in place of the located sequence of instructions to prevent an attack on the application.

Various implementations of 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 particularly after considering the section entitled "Detailed Description" one will understand how the aspects of some implementations are used to manage memory accesses that are queued during synchronization events of a processor system executing virtual machine(s). In each synchronization event, a processor orchestrates a handshaking process to identify speculative memory access requests and purge translations associated with the speculative memory access requests without stalling the synchronization event.

Specifically, 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, a corresponding translation process is terminated prematurely without filling any translation cache structure (e.g., a table lookaside buffer (TLB), table walk caches). Data extracted from any speculative memory access request associated with the translation process cannot be applied, e.g., by an instruction fetch module, a load/store module, or a prefetch engine of the processor. The processor skips long-latency table walks of translations associated with the speculative memory access requests without compromising performance of the synchronization event. System registers do not need to be sampled and copied across translation units. By these means, an efficient memory management solution is offered to manage memory access requests and associated address translations efficiently for one or more processors executing virtual machine(s), which also expedites the synchronization events effectively.

In some implementations, a method is employed for managing memory accesses at a respective processor of one or more processors that are configured to execute one or more virtual machines. The method includes receiving a request for initiating 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, in accordance with the identifying, purging translations associated with the subset of speculative memory access requests; 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 speculative memory access requests are queued in anticipation of one or more instructions received subsequent to the request.

In some implementations, the respective 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 from or write into a respective memory unit a respective data item, aborting filling the translation cache associated with the respective processor, and withholding the respective processor from using the respective data item. Further, in some implementations, the translation cache includes a TLB and a page table cache.

In some implementations, the method further includes receiving a barrier instruction configured to force 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 for updating a system register. Alternatively, in some implementations, the method further includes receiving a barrier instruction configured to force memory access completion to initiate a data synchronization event for updating registers associated with a virtual machine implemented on the respective processor.

In another aspect, an electronic device includes one or more processors configured to execute one or more virtual machines. A respective processor is configured to implement any of the above methods.

In another aspect, a non-transitory computer readable storage medium stores one or more programs configured for execution by a respective processor of one or more processors that are configured to execute one or more virtual machines. The one or more programs include instructions that when executed by the respective processor, cause the respective processor to implement any of the above methods.

In yet another aspect, an apparatus for managing memory accesses at a respective processor of one or more processors includes means for performing any of the above methods. The one or more processors are configured to execute one or more virtual machines.

For a better understanding of the various described implementations, reference should be made to the Detailed Description below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures. Like reference numerals refer to corresponding parts throughout the drawings.

Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth in order to assist in understanding the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that various alternatives may be used without departing from the scope of claims and the subject matter may be practiced without these specific details.

<FIG> is a block diagram of an example system module <NUM> in a typical electronic device in accordance with some implementations. The system module <NUM> in this electronic device includes at least a system on a chip (SoC) <NUM>, memory modules <NUM> for storing programs, instructions and data, an input/output (I/O) controller <NUM>, one or more communication interfaces such as network interfaces <NUM>, and one or more communication buses <NUM> for interconnecting these components. In some implementations, the I/O controller <NUM> allows SoC <NUM> to communicate with an I/O device (e.g., a keyboard, a mouse or a trackpad) via a universal serial bus interface. In some implementations, the network interfaces <NUM> includes one or more interfaces for Wi-Fi, Ethernet and Bluetooth networks, each allowing the electronic device to exchange data with an external source, e.g., a server or another electronic device. In some implementations, the communication buses <NUM> include circuitry (sometimes called a chipset) that interconnects and controls communications among various system components included in the system module <NUM>.

In some implementations, the memory modules <NUM> (e.g., memory <NUM> in <FIG>) include high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices. In some implementations, memory modules <NUM> include 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 modules <NUM>, or alternatively the non-volatile memory device(s) within the memory modules <NUM>, include a non-transitory computer readable storage medium. In some implementations, memory slots are reserved on the system module <NUM> for receiving the memory modules <NUM>. Once inserted into the memory slots, memory modules <NUM> are integrated into the system module <NUM>.

In some implementations, the system module <NUM> further includes one or more components selected from:.

It is noted that the communication buses <NUM> also interconnect and control communications among various system components including components <NUM>-<NUM>.

Further, one skilled in the art knows that other non-transitory computer readable storage media can be used, as new data storage technologies are developed for storing information in the non-transitory computer readable storage media in the memory modules <NUM> and in the SSDs <NUM>. These new non-transitory computer readable storage media include, but are not limited to, those manufactured from biological materials, nanowires, carbon nanotubes and individual molecules, even though the respective data storage technologies are currently under development and yet to be commercialized.

In some implementations, the SoC <NUM> 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 <NUM> is configured to receive one or more internal supply voltages provided by the PMIC <NUM>. In some implementations, both the SoC <NUM> and the PMIC <NUM> are mounted on a main logic board, e.g., on two distinct areas of the main logic board, and electrically coupled to each other via conductive wires formed in the main logic board. As explained above, this arrangement introduces parasitic effects and electrical noise that could compromise performance of the SoC, e.g., cause a voltage drop at an internal voltage supply. Alternatively, in some implementations, the SoC <NUM> and the PMIC <NUM> are vertically arranged in an electronic device, such that they are electrically coupled to each other via electrical connections that are not formed in the main logic board. Such vertical arrangement of the SoC <NUM> and the PMIC <NUM> can reduce a length of electrical connections between the SoC <NUM> and the PMIC <NUM> and avoid performance degradation caused by the conductive wires of the main logic board. In some implementations, vertical arrangement of the SoC <NUM> and the PMIC <NUM> is facilitated in part by integration of thin film inductors in a limited space between the SoC <NUM> and the PMIC <NUM>.

<FIG> is a block diagram of an example electronic device <NUM> having one or more processing clusters <NUM> (e.g., first processing cluster <NUM>-<NUM>, Mth processing cluster <NUM>-M), in accordance with some implementations. In some implementations, the processing clusters <NUM> are implemented on one SoC <NUM>. In some implementations, the processing clusters <NUM> are distributed across multiple SoCs. Electronic device <NUM> further includes a cache <NUM> and a memory <NUM> in addition to processing clusters <NUM>. Cache <NUM> is coupled to processing clusters <NUM> on the electronic device <NUM>, which is further coupled to memory <NUM> that is external to SoC <NUM>. Each processing cluster <NUM> includes one or more processors <NUM> and a cluster cache <NUM>. The cluster cache <NUM> is coupled to one or more processors <NUM>, and optionally, maintains one or more request queues <NUM> for one or more processors <NUM>. Each cluster cache <NUM> is also associated with one or more filters <NUM> that can be used to determine whether cache entries for a specific virtual machine, a specific address space, or a specific virtual address is stored in the associated cluster cache <NUM>.

In some implementations, each processor <NUM> further includes a core cache <NUM> that is optionally split into an instruction cache and a data cache, and core cache <NUM> stores instructions and data that can be immediately executed by the respective processor <NUM>. Each core cache <NUM> is also associated with one or more core filters (not shown in <FIG>) that can be used to determine whether cache entries for a specific virtual machine, a specific address space, or a specific virtual address is stored in the associated core cache <NUM>.

In an example, the first processing cluster <NUM>-<NUM> includes first processor <NUM>-<NUM>,. , N-th processor <NUM>-N, first cluster cache <NUM>-<NUM>, where N is an integer greater than <NUM>. The first cluster cache <NUM>-<NUM> has one or more first request queues <NUM>-<NUM>, and each first request queues <NUM>-<NUM> includes a queue of demand requests and prefetch requests received from a subset of processors <NUM> of first processing cluster <NUM>-<NUM>. Additionally, as new cache entries are stored at the first cluster cache <NUM>-<NUM>, the one or more filter(s) <NUM>-<NUM> associated with the first cluster cache <NUM> are updated to store information regarding the newly added cache entries. For instance, if a new cache entry that includes a first virtual machine identifier (VMID) is stored at first cluster cache <NUM>-<NUM>, the one or more filters <NUM>-<NUM> associated with the first cluster cache <NUM>-<NUM> is updated to store information indicating that the first cluster cache <NUM>-<NUM> stores at least one cache entry with the first VMID. However, as the first cluster cache <NUM>-<NUM> is updated with new cache entries, some cache entries may be evicted from the first cluster cache <NUM>-<NUM> such that the evicted cache entries are no longer stored at the first cluster cache <NUM>-<NUM>. The one or more filters <NUM>-<NUM> associated with the first cluster cache <NUM>-<NUM> may continue to store information indicating that the first cluster cache <NUM>-<NUM> stores at least one cache entry with the first VMID even if cache entries that include the first VMID are no longer stored in the first cluster cache <NUM>-<NUM>. The one or more filters <NUM>-<NUM> associated with the first cluster cache <NUM>-<NUM> must be regenerated to accurately reflect cache entries that are currently stored in the first cluster cache <NUM>-<NUM>. For example, the one or more filters <NUM>-<NUM> associated with the first cluster cache <NUM>-<NUM> are updated in order to remove the information indicating that the first cluster cache <NUM>-<NUM> stores at least one cache entry with the first VMID.

In some implementations, the SoC <NUM> only includes a single processing cluster <NUM>-<NUM>. Alternatively, in some implementations, the SoC <NUM> includes at least an additional processing cluster <NUM>, e.g., M-th processing cluster <NUM>-M. M-th processing cluster <NUM>-M includes first processor <NUM>-<NUM>,. , N'-th processor <NUM>-N', and M-th cluster cache <NUM>-M, where N' is an integer greater than <NUM> and M-th cluster cache <NUM>-M has one or more M-th request queues <NUM>-M.

In some implementations, the one or more processing clusters <NUM> are configured to provide a central processing unit for an electronic device and are associated with a hierarchy of caches. For example, the hierarchy of caches includes three levels that are distinguished based on their distinct operational speeds and sizes. For the purposes of this application, a reference to "the speed" of a memory (including a cache memory) relates to the time required to write data to or read data from the memory (e.g., a faster memory has shorter write and/or read times than a slower memory), and a reference to "the size" of a memory relates to the storage capacity of the memory (e.g., a smaller memory provides less storage space than a larger memory). The core cache <NUM>, cluster cache <NUM>, and cache <NUM> correspond to a first level (L1) cache, a second level (L2) cache, and a third level (L3) cache, respectively. Each core cache <NUM> holds instructions and data to be executed directly by a respective processor <NUM>, and has the fastest operational speed and smallest size among the three levels of memory. For each processing cluster <NUM>, the cluster cache <NUM> is slower operationally than the core cache <NUM> and bigger in size, and holds data that is more likely to be accessed by the processors <NUM> of respective processing cluster <NUM>. The cache <NUM> is shared by the plurality of processing clusters <NUM>, and bigger in size and slower in speed than each of the core cache <NUM> and the cluster cache <NUM>. Each processing cluster <NUM> controls prefetches of instructions and data to the core caches <NUM> and/or the cluster cache <NUM>. Each individual processor <NUM> further controls prefetches of instructions and data from a respective cluster cache <NUM> into a respective individual core cache <NUM>.

In some implementations, a first cluster cache <NUM>-<NUM> of the first processing cluster <NUM>-<NUM> is coupled to a single processor <NUM>-<NUM> in the same processing cluster, and not to any other processors (e.g., <NUM>-N). In some implementations, the first cluster cache <NUM>-<NUM> of the first processing cluster <NUM>-<NUM> is coupled to multiple processors <NUM>-<NUM> and <NUM>-N in the same processing cluster. In some implementations, the first cluster cache <NUM>-<NUM> of the first processing cluster <NUM>-<NUM> is coupled to the one or more processors <NUM> in the same processing cluster <NUM>-<NUM>, and not to processors in any cluster other than the first processing cluster <NUM>-<NUM> (e.g., processors <NUM> in cluster <NUM>-M). The first cluster cache <NUM>-<NUM> of first processing cluster <NUM>-<NUM> is sometimes referred to as a second-level cache or an L2 cache.

In each processing cluster <NUM>, each request queue <NUM> optionally includes a queue of demand requests and prefetch requests received from a subset of processors <NUM> of a respective processing cluster <NUM>. Each data access request received from a respective processor <NUM> is distributed to one of the request queues <NUM> associated with the respective processing cluster <NUM>. In some implementations, a request queue <NUM> receives only requests received from a specific processor <NUM>. In some implementations, a request queue <NUM> receives requests from more than one processor <NUM> in the processing cluster <NUM>, allowing a request load to be balanced among the plurality of request queues <NUM>. Specifically, in some situations, a request queue <NUM> receives only one type of data retrieval requests (such as prefetch requests) from different processors <NUM> in the same processing cluster <NUM>.

Each request queue <NUM> includes a plurality of memory access requests to access a memory system of an SOC <NUM> including core caches <NUM>, cluster caches <NUM>, cache <NUM>, and memory <NUM>. In some implementations, based on a type of requested information, each memory access request queue <NUM> includes one of a data translation queue, an instruction translation queue, and a prefetch translation queue. The data translation queue includes a plurality of data address mapping requests for translating virtual addresses associated with data, and the data is extracted from the memory system of the SoC <NUM> using the translated virtual addresses. The instruction translation queue includes a plurality of instruction address mapping requests for translating virtual addresses associated with instructions, and the instructions are extracted from the memory system of the SoC <NUM> using the translated virtual addresses. The prefetch translation queue is applied to fetch instruction opcodes from the memory system in advance, and includes a plurality of address mapping requests for translating virtual addresses associated with instruction opcodes. The instruction opcodes are extracted from the memory system of the SoC <NUM> using the translated virtual addresses in advance and will be processed by the processor(s) <NUM> in each processing cluster <NUM>.

Each processing cluster <NUM> includes or is coupled to one or more IFUs <NUM> in the processors <NUM>. The one or more IFUs <NUM> are configured to prefetch, decode, and/or prepare upcoming instructions in parallel with execution of current instructions. In some implementations, each processor <NUM> in the processing cluster <NUM> includes or is coupled to a respective IFU <NUM> to control cache fetching (including cache prefetching) associated with the respective processor <NUM>. In some implementations, two or more of the processors <NUM> in the processing cluster <NUM> share the same IFU <NUM>. A respective IFU <NUM> may include either 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 an example, the IFU <NUM> issues a data fetch request (which is optionally a demand request or a prefetch request) associated with an instruction, and the data fetch request is received at a processor <NUM> of a processing cluster <NUM>. The data fetch request includes an address translation request that includes address information for translating a virtual address into a physical address and is applied to retrieve data from the memory <NUM>. In response to the data fetch request, the processor <NUM> implements a virtual address to physical address translation or a virtual address to physical address mapping, which may, for example, identify a page entry in a page table. The related address translation request is queued in a data translation queue among the one or more memory access request queues <NUM>.

In some implementations not shown in <FIG>, each processor <NUM> includes a prefetch engine separately from the IFU <NUM>. The prefetch engine is configured to implement prefetches in which upcoming instructions and associated data are fetched in advance while current instructions are implemented by the respective processor <NUM>.

In some implementations, each processor <NUM> includes a rename/retire/dispatch unit (REU) <NUM>, a load/store unit (LSU) <NUM>, and a memory management unit (MMU) <NUM>. Alternatively, in some implementations, two or three processors <NUM> share a REU <NUM>, a LSU <NUM>, a MMU <NUM>, or a subset thereof. The LSU <NUM> is configured to generate virtual addresses for loading and storage operations on data and instructions, load data from the memory <NUM> of the SoC <NUM>, and store data from registers <NUM> to the memory <NUM> of the SoC <NUM>. The REU <NUM> is configured for register renaming and instruction retirement and dispatching. The MMU <NUM> is configured to manage memory accesses based on the one or more memory access request queues <NUM>. In some implementations, the MMU <NUM> collaborates with the LSU <NUM> or REU <NUM> to manage speculative memory accesses during synchronization events. The virtual addresses generated by the LSU <NUM> are associated with memory access requests in the one or more memory access request queues <NUM>. In response to an initiation of a synchronization event (e.g., a context or data synchronization event), the REU <NUM> or LSU <NUM> generates a purge instruction to purge translations of speculative memory access requests in the one or more memory access request queues <NUM>. In response to the purge instruction, the MMU <NUM> identifies the speculative memory access requests in the memory access request queue(s) <NUM> and purges address translations or mappings associated with the speculative memory access requests from the queue(s) <NUM>.

<FIG> illustrates a block diagram of a hypervisor <NUM> for hosting virtual machines <NUM> on a system module <NUM>, in accordance with some implementations. The system module <NUM> includes hardware supporting the hypervisor <NUM>, such as the electronic device <NUM> and the memory <NUM>. The electronic device <NUM> includes the caches <NUM> (which include caches <NUM>, <NUM>, and <NUM>, shown in <FIG>). The hypervisor <NUM> hosts one or more virtual machines <NUM> (e.g., virtual machines <NUM>-<NUM> through <NUM>-m) and each of the virtual machines <NUM> runs a respective guest operating system (OS) <NUM> and one or more respective guest applications <NUM>. For example, as shown in <FIG>, the hypervisor <NUM> hosts m number of virtual machines <NUM>. A first virtual machine <NUM>-<NUM> runs a guest OS <NUM>-<NUM> as well as guest applications <NUM>-<NUM> through <NUM>-p, and a second virtual machine <NUM>-<NUM> runs a guest OS <NUM>-<NUM> as well as guest applications <NUM>-<NUM> through <NUM>-p'. Each of the virtual machines <NUM> operates independently from other virtual machines even though they are hosted by the same hypervisor <NUM>. For example, the first virtual machine <NUM>-<NUM> and the second virtual machine <NUM>-<NUM> may be initiated or created at different times. In another example, the first virtual machine <NUM>-<NUM> may be shut down while the second virtual machine <NUM>-<NUM> remains operational. For instance, the first virtual machine <NUM>-<NUM> may be shut down without tearing down the second virtual machine <NUM>-<NUM>. In yet another example, the first virtual machine <NUM>-<NUM> may open, run, or close any of the applications <NUM>-<NUM> through <NUM>-p independently of the second virtual machine <NUM>-<NUM> opening, running, or closing any of the applications <NUM>-<NUM> through <NUM>-p'.

Although each of the virtual machines <NUM> operate independently of one another, information required to run each of the virtual machines <NUM>, the respective guest OS <NUM>, and the respective guest applications <NUM> is stored in memory <NUM>. The virtual address to physical address translations that are used in running the virtual machines <NUM>, the guest OS <NUM>, and any guest applications <NUM> may be stored in the caches <NUM> of the system module <NUM>. Thus, when a new virtual machine <NUM> is set up, or when a new application <NUM> is opened on a virtual machine <NUM>, new address translations are stored as cache entries in the caches <NUM>. Additionally, when a virtual machine <NUM> is shut down or an application <NUM> on a virtual machine <NUM> is closed, TLB invalidation instructions are sent to the caches <NUM> to invalidate cache entries associated with the shutdown virtual machine <NUM> or to invalidate cache entries associated with the guest application that has been closed on the virtual machine <NUM>, respectively.

In a family of reduced instruction set computer (RISC) architectures for computer processors, e.g., Advanced RISC Machines (ARM), software is split into different modules, and each module has a respective level of access to the electronic device <NUM> including one or more processors <NUM>, an associated caches <NUM>, and memory <NUM>. That said, Each software module has a distinct level of privilege (also called an exception level (EL)) that can only change when a processor <NUM> takes or returns from an exception. Each exception level is numbered, and the higher levels of privilege have higher numbers. For example, EL0, EL1, EL2, and EL3 correspond to increasing privilege levels of a guess application <NUM>, guest OS <NUM>, hypervisor <NUM>, and firmware layer, respectively.

<FIG> is a flow diagram of a one-stage table walk process <NUM> for fetching data by a processing cluster <NUM> (e.g., by an IFU <NUM> of the first processing cluster <NUM>-<NUM> of <FIG>), in accordance with some implementations. For each processing cluster <NUM>, a memory access queue <NUM> includes an ordered sequence of memory access requests, and each memory access request includes an address translation request <NUM> that requests translation of a virtual address associated with a respective application <NUM> executed on a guest OS <NUM> of a virtual machine <NUM>. The virtual address is translated to the physical address <NUM> in accordance with the one-stage table walk process <NUM>. In this example, address translation information of each memory access request is stored in a multi-level hierarchy (i.e., the TLB <NUM>) that includes at least one level <NUM> table, a plurality of level <NUM> tables, a plurality of level <NUM> tables, and a plurality of level <NUM> tables. A level <NUM> table stores page entries that include table descriptors that identify a specific level <NUM> table (e.g., a specific table of the plurality of level <NUM> tables, a first table of the plurality of level <NUM> tables), a level <NUM> table stores page entries that include table descriptors that identify a specific level <NUM> table (e.g., a specific table of the plurality of level <NUM> tables, a first table of the plurality of level <NUM> tables), a level <NUM> table stores page entries that include table descriptors that identify a specific level <NUM> table (e.g., a specific table of the plurality of level <NUM> tables, a first table of the plurality of level <NUM> tables), and a level <NUM> table stores page entries that include page descriptors that identify a specific page table <NUM> in memory <NUM>. The table walk process <NUM> begins at the level <NUM> table and continues until the requested data <NUM> stored in the page entry in the memory <NUM> (e.g., the page table <NUM> in the memory <NUM>) is identified.

A data fetch process begins with a processor (e.g., the processor <NUM>-<NUM>) of a processing cluster (e.g., the processing cluster <NUM>-<NUM>) receiving an address translation request <NUM> that includes a virtual address <NUM> to be translated. The virtual address <NUM> includes a translation table base register (TTBR), which identifies the level <NUM> table at which a data fetcher of the processor (e.g., the data fetcher <NUM>-<NUM> of the processor <NUM>-<NUM>) can begin the table walk process <NUM>. The table walk process <NUM> is initiated in accordance with a determination that requested data <NUM> (e.g., data requested by the address translation request <NUM>) is not stored in the TLB <NUM> (e.g., a TLB "miss").

Specifically, the IFU <NUM> begins table walk process <NUM> by identifying a first table descriptor <NUM> that is stored in a page table entry in the level <NUM> table <NUM>. The first table descriptor <NUM> includes information that identifies a level <NUM> table <NUM> (e.g., a specific level <NUM> table) for which the IFU <NUM> can query to continue the table walk process <NUM>. In some implementations, at least a portion (e.g., a first portion <NUM>-<NUM>) of virtual address <NUM> is used to find first table descriptor <NUM> in the level <NUM> table <NUM>. For example, a first portion <NUM>-<NUM> of the virtual address <NUM> may include a reference to the page table entry in the level <NUM> table <NUM> that stores the first table descriptor <NUM>.

The IFU <NUM> identifies the level <NUM> table <NUM> based on the first table descriptor <NUM> obtained (e.g., output) from level <NUM> table <NUM>, and identifies a second table descriptor <NUM> that is stored in a page table entry in level <NUM> table <NUM>. The second table descriptor <NUM> includes information that identifies a level <NUM> table <NUM> (e.g., a specific level <NUM> table) for which the IFU <NUM> can query to continue the table walk process <NUM>. In some implementations, at least a portion (e.g., a second portion <NUM>-<NUM>) of the virtual address <NUM> is used to find the second table descriptor <NUM> in the level <NUM> table <NUM>. For example, a second portion <NUM>-<NUM> of the virtual address <NUM> may include a reference to the page table entry in level <NUM> table <NUM> that stores the second table descriptor <NUM>. In some implementations, in addition to providing a second table descriptor <NUM>, the level <NUM> table <NUM> also provides a first block descriptor <NUM> that identifies a first contiguous portion <NUM>-<NUM> within the memory <NUM>, e.g., a first contiguous portion <NUM>-<NUM> in the memory <NUM> within which the requested data <NUM> is stored.

The IFU <NUM> identifies the level <NUM> table <NUM> based on a second table descriptor <NUM> obtained from the level <NUM> table <NUM>, and identifies a third table descriptor <NUM> that is stored in a page table entry in the level <NUM> table <NUM>. The third table descriptor <NUM> includes information that identifies a level <NUM> table <NUM> (e.g., a specific level <NUM> table) for which IFU <NUM> can query to continue the table walk process <NUM>. In some implementations, at least a portion (e.g., a third portion <NUM>-<NUM>) of the virtual address <NUM> is used to find the third table descriptor <NUM> in the level <NUM> table <NUM>. For example, a third portion <NUM>-<NUM> of the virtual address <NUM> may include a reference to the page table entry in the level <NUM> table <NUM> that stores the third table descriptor <NUM>. In some implementations, in addition to providing (e.g., outputting) the third table descriptor <NUM>, the level <NUM> table <NUM> also provides a second block descriptor <NUM> that identifies a second contiguous portion <NUM>-<NUM> within the memory <NUM> (e.g., a second contiguous portion <NUM>-<NUM> in the memory <NUM> within which the requested data <NUM> (e.g., requested address translation) is stored). In some implementations, the second contiguous portion <NUM>-<NUM> in the memory <NUM> includes a smaller portion of memory <NUM> compared to the first contiguous portion <NUM>-<NUM> in the memory <NUM>, and the first contiguous portion <NUM>-<NUM> in the memory <NUM> includes the second contiguous portion <NUM>-<NUM> in the memory <NUM>. For example, the first contiguous portion <NUM>-<NUM> in the memory <NUM> includes <NUM> MB of space in the memory <NUM>, and the second contiguous portion <NUM>-<NUM> in the memory <NUM> includes <NUM> KB of space in the memory.

The IFU <NUM> identifies the level <NUM> table <NUM> based on a third table descriptor <NUM> obtained (e.g., output) from the level <NUM> table <NUM>, and identifies a page descriptor <NUM> that is stored in a page table entry in level <NUM> table <NUM>. The page descriptor <NUM> includes information that identifies a page table <NUM> in memory <NUM> for which the IFU <NUM> can query to continue table walk process <NUM>. In some implementations, at least a portion (e.g., a fourth portion <NUM>-<NUM>) of the virtual address <NUM> is used to find the page descriptor <NUM> in the memory <NUM>. For example, a fourth portion <NUM>-<NUM> of the virtual address <NUM> may include a reference to the page table entry in the level <NUM> table <NUM> that stores the page descriptor <NUM>.

The IFU <NUM> queries the page table <NUM> in the memory <NUM>, as identified by page descriptor <NUM> output from level <NUM> table <NUM>, to find a page entry <NUM> that stores the requested data <NUM> (e.g., stores the requested virtual address to physical address translation). In some implementations, at least a portion (e.g., a fifth portion <NUM>-<NUM>) of the virtual address <NUM> is used to find the page entry <NUM> in the page table <NUM>. For example, a fifth portion <NUM>-<NUM> of the virtual address <NUM> may include a reference to the byte on the page table <NUM> that stores the requested data <NUM>. Thus, using the table walk process <NUM>, The IFU <NUM> of a processor (e.g., data fetcher <NUM>-<NUM> of processor <NUM>-<NUM>) is able to obtain the requested data <NUM> (e.g., the requested address translation <NUM>, the physical address <NUM> corresponding to the request <NUM>) and pass the requested data <NUM> to the processor. However, the table walk process <NUM> introduces latency into system operations. Thus, in some embodiments, the table walk process <NUM> is skipped or bypassed for each speculative memory access request that is queued in a memory access request queue <NUM> in anticipation of one or more instructions received subsequent to a request for a synchronization event.

<FIG> is an example sequence of instructions <NUM> implemented to enable a context synchronization event, in accordance with some implementations. The context synchronization event corresponds to a termination of a first application <NUM>-<NUM> in a guest OS <NUM> to initiate a second application <NUM>-<NUM>, a termination of a first virtual machine <NUM>-<NUM> to initiate a second virtual machine <NUM>-<NUM>, or a system call for updating a system register <NUM>. In some implementations, an instruction set architecture (ISA) is part of the hypervisor <NUM> of a system module <NUM> and defines how the processors <NUM> are controlled by software. At the context synchronization event, the ISA includes the set of instructions <NUM> configured to require translations and a consistent view of translation control system registers <NUM>, e.g., for table walks of speculative memory access requests in a memory access queue <NUM>. For example, a translation of a virtual address to a physical address retains the same address space identification (ASID) during the entire lifecycle of the translation.

In some implementations, an "SVC" request <NUM> for the context synchronization event includes a supervisor call from a first exception level EL0 to a second exception level EL1, and is followed by an "ISB" barrier instruction <NUM> that is configured to force memory access completion to initiate the context synchronization event. The barrier instruction <NUM> creates an instruction synchronization barrier (ISB) that forces memory access ordering and access completion at a specific point. The barrier instruction <NUM> ensures that all instructions that come after the ISB instruction in program order are fetched from the cache or memory after the ISB instruction has completed. Using an ISB ensures that the effects of context-changing operations executed before the ISB are visible to the instructions fetched after the ISB instruction. In some implementations, context-changing operations require the insertion of an ISB instruction to ensure 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 maintenance instructions and changes to system registers. Any context-changing operations appearing in program order after the ISB instruction <NUM> only take effect after the ISB has been executed.

For example, each memory access request queue <NUM> includes an ordered-sequence of memory access requests, and includes a subset of speculative memory access requests <NUM> that are queued in anticipation of one or more instructions received subsequent to the request <NUM>. The speculative memory access requests <NUM> optionally include one or more prefetch instructions to load instructions 406A-406C or associated data to be processed subsequently to the context synchronization event. In some situations, these prefetch instructions are intended to fetch instructions and associated data for the second application <NUM> or second virtual machine <NUM> to which the context synchronization event is intended to initiate. As the caches <NUM> of the system module <NUM> have not been purged and reloaded based on the second application <NUM>-<NUM> or second virtual machine <NUM>-<NUM>, the instructions and associated data, which are fetched due to the prefetch instructions, are outdated or inconsistent, and cannot be used to implement the second application <NUM>-<NUM> or second virtual machine <NUM>-<NUM>.

Specifically, in response to the request <NUM> for the context synchronization event, the processor <NUM> identifies the subset of speculative memory access requests <NUM> and automatically purges address translations associated with the subset of speculative memory access requests <NUM>. The context synchronization event is initiated, independently of whether the subset of speculative memory access requests <NUM> are purged. That said, the context synchronization event may be initiated after, while, or before the subset of speculative memory access requests <NUM> are purged. In some situations, the prefetch instructions are intended to fetch instructions and associated data for the second application <NUM> or second virtual machine <NUM>, and speculative memory access requests <NUM> related to these prefetch instructions are purged. Given that these prefetch instructions provide the outdated instructions and data associated with the first application <NUM>-<NUM> or first virtual machine <NUM>-<NUM>, purging the speculative memory access requests <NUM> related to these prefetch instructions enhances efficiency of memory accesses and expedites the context synchronization event.

Referring to <FIG>, in an example, the request <NUM> for the context synchronization event includes a supervisor call for terminating a first application <NUM>-<NUM> and initiating a second application <NUM>-<NUM>. The supervisor call is made from a first exception level EL0 to a second exception level EL1, i.e., from the first application <NUM>-<NUM> to an operating system <NUM>. The supervisor call is followed by a regime instruction <NUM> for maintaining a translation regime and a register update instruction <NUM> for updating a translation base register <NUM> from the first application <NUM>-<NUM> (e.g., ASID=A) to the second application <NUM>-<NUM> (e.g., ASID=B). The barrier instruction <NUM> is applied to create an instruction synchronization barrier (ISA) and ensure that new instructions received after the context synchronization event are processed in the context of the second application <NUM>-<NUM>. The barrier instruction <NUM> is followed by an application load instruction 406A, an exception level instruction 406B, and a regime instruction 406C, which are associated with the second application <NUM>-<NUM>.

In some situations, a plurality of speculative memory access requests <NUM> are queued in anticipation of the instructions 406A-406C. In response to the request <NUM>, the processor <NUM> aborts implementation of address translations of the speculative memory access requests <NUM>, while completing the barrier instruction <NUM> within a first number of clock cycles. In contrast, if the address translations of the speculative memory access requests <NUM> 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. That said, purging translations associated with the subset of speculative memory access requests <NUM> expedites the context synchronization event by bypassing the speculative memory access requests <NUM> that might provide outdated or inconsistent instructions or data.

<FIG> is another example sequence of instructions <NUM> configured to enable a data synchronization event, in accordance with some implementations. A data synchronization event is implemented to permit a high exception level to be able to safely update translation control system register(s) <NUM> associated with a low exception level. For example, in the data synchronization event, a hypervisor <NUM> (EL2) updates associated translation control system registers <NUM> associated with a virtual machine <NUM>, application <NUM>. or operating system <NUM>, e.g., when a context synchronization event occurs to switch between two virtual machines <NUM>, two applications <NUM>, or two operating systems <NUM>, respectively. In some implementations, when the data synchronization event is executed from a hypervisor (EL2) or a firmware (EL3), and speculative address translations or table walks to lower exception levels (e.g., EL1 or EL0) are terminated. Address translations for one or more speculative memory accesses (i.e., speculative address translation or table walk) are purged, as the system registers <NUM> associated with translation control are updated.

In some implementations, an "HVC" request <NUM> is received via a hypervisor call to initiate the data synchronization event, and the hypervisor call is made from a guest application <NUM> or a guess operating system <NUM> to a hypervisor <NUM>. The request <NUM> is followed by a barrier instruction <NUM> configured to force memory access completion to initiate a data synchronization event. The barrier instruction <NUM> includes one or more data synchronization barriers 504A and 504B that are executed on a hypervisor layer (EL2) or a firmware layer (EL3) to force memory access completion of the speculative memory access requests to an operating system level (EL1) or an application level (EL0). In an example, each barrier instruction includes a hypervisor call from a hypervisor <NUM> or a guest operating system <NUM>. Specifically, each barrier instruction <NUM> creates a data synchronization barrier (DSB). The DSB blocks execution of any further instructions, not just loads or stores, until synchronization is complete. In some situations, the DSB also waits until all cache, TLB, and branch predictor maintenance operations that are issued by a processor <NUM> (e.g., speculative memory accesses) have completed. Conversely, in some implementations, the DSB purges any translations of any speculative memory accesses.

Each memory access request queue <NUM> includes an ordered-sequence of memory access requests, and includes a subset of speculative memory access requests <NUM> that are queued in anticipation of one or more instructions received subsequent to the request <NUM>. In response to the request <NUM> for the data synchronization event, the processor <NUM> identifies a subset of speculative memory access requests <NUM> and automatically purges address translations associated with the subset of speculative memory access requests <NUM>. The data synchronization event is initiated, before, after, or while the subset of speculative memory access requests <NUM> are purged. In some situations, prefetch instructions are issued to fetch instructions 506A-506B and associated data to be applied after the data synchronization event, and speculative memory access requests <NUM> related to these prefetch instructions are purged. These prefetch instructions provide the outdated instructions and data associated with caches, TLB, and memory that have not been updated, purging the speculative memory access requests <NUM> related to these prefetch instructions enhances efficiency of memory accesses and expedites the data synchronization event.

Referring to <FIG>, in an example, the request <NUM> for the data synchronization event includes a hypervisor call from a guest (e.g., an operating system <NUM> or application <NUM>) to a hypervisor <NUM>. The hypervisor call is followed by a regime instruction <NUM> for maintaining a translation regime and a probing instruction <NUM> for probing the translation regime by the hypervisor <NUM>. Two barrier instructions <NUM> are applied to create data barriers that ensure that address translations are completed and page table entries (PTEs) are updated and observable globally. The barrier instructions <NUM> are followed by an exception level instruction 506A and a regime instruction 506B. In some situations, a plurality of speculative memory access requests <NUM> are queued in anticipation of the instructions 506A-506B.

In some implementations, in response to the request <NUM>, the processor <NUM> aborts implementation of address translations of the speculative memory access requests <NUM>, while completing the barrier instruction <NUM> within a first number of clock cycles. In contrast, if the address translations of the speculative memory access requests <NUM> 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. That said, purging translations associated with the subset of speculative memory access requests expedites the data synchronization event by bypassing the speculative memory access requests <NUM> that might provide outdated (e.g., inconsistent) instructions or data.

<FIG> is a flow diagram of an example address translation process <NUM> implemented at a context synchronization event, in accordance with some implementations, and <FIG> is a sequence of example instructions <NUM> configured to update system registers <NUM>, in accordance with some implementations. Processors <NUM> of an SoC <NUM> orchestrate a synchronization event that purges address translations of speculative memory accesses (i.e., speculative address translations) without stalling completion of the synchronization event. Speculative memory accesses are marked, e.g., as "purged, with null-response", in a corresponding memory access queue <NUM> maintained in a cache <NUM>. The address translations associated with the speculative memory access requests are automatically purged (i.e., terminated prematurely) in accordance with a determination that each speculative memory access request is marked. The processor <NUM> does not fill any translation caching structure (e.g., TLBs <NUM>, page table <NUM>). Data, if fetched by the speculative memory access requests, cannot be consumed by the IFU <NUM>, REU <NUM>, LSU <NUM>, or MMU <NUM>.

Specifically, an REU <NUM> and an MMU <NUM> of a processor <NUM> are coordinated with each other to complete the context synchronization event in which the speculative address translations are purged. Upon receiving a request for the context synchronization event, the REU <NUM> generates a barrier instruction for creating an ISB. In response to the barrier instruction, the REU <NUM> generates a purge instruction to purge translations of the subset of speculative memory access requests. The MMU <NUM> identifies the subset of speculative memory access requests in the memory access queue(s) <NUM> and purges the translations associated with the subset of speculative memory access requests. These purged translations include data translations <NUM>, instruction translations <NUM>, prefetch translations <NUM>, or a combination thereof. Alternatively, in some implementations, the one or more memory access request queues <NUM> include a data translation queue, an instruction translation queue, and a prefetch translation queue. The MMU <NUM> identifies the subset of speculative memory access requests in each of the data translation queue, instruction translation queue, and prefetch translation queue. The speculative memory access requests include at least one memory access request in the data, instruction, and prefetch translation queues, and an associated address translation is purged.

Referring to <FIG>, in an example, a request <NUM> for the context synchronization event is received by the REU <NUM>. In response, the REU <NUM> starts a handshaking process by issuing the barrier instruction <NUM> that creates an ISB. Speculative address translation associated with a subsequent instruction <NUM> is purged to avoid a long latency table walk that might return an inconsistent or outdated instruction and associated data, which is not useable in subsequent processing.

<FIG> is a flow diagram of another example address translation process <NUM> implemented at a data synchronization event, in accordance with some implementations, and <FIG> is a sequence of example instructions <NUM> configured to update system registers <NUM> and complete table walks, in accordance with some implementations. An LSU <NUM> and an MMU <NUM> of a processor <NUM> are coordinated with each other to complete the data synchronization event in which speculative address translations are purged. Upon receiving a request for the data synchronization event, the LSU <NUM> generates a barrier instruction for creating a DSB. In response to the barrier instruction, the LSU <NUM> generates a purge instruction to purge translations of a subset of speculative memory access requests. The MMU <NUM> identifies the subset of speculative memory access requests in the memory access queue(s) <NUM> and purges the translations associated with the subset of speculative memory access requests. These purged translations include data translations <NUM>, instruction translations <NUM>, prefetch translations <NUM>, or a combination thereof. Alternatively, in some implementations, the one or more memory access request queues <NUM> include a data translation queue, an instruction translation queue, and a prefetch translation queue. The MMU <NUM> identifies the subset of speculative memory access requests in each of the data translation queue, instruction translation queue, and prefetch translation queue. The speculative memory access requests include at least one memory access request in the data, instruction, and prefetch translation queues, and an associated address translation is purged.

Referring to <FIG>, in an example, a request <NUM> for the data synchronization event is received by the LSU <NUM>. In response, the LSU <NUM> starts a handshaking process by issuing the barrier instruction <NUM> that creates the DSB. Speculative address translation associated with a subsequent instruction <NUM> is purged to avoid a long latency table walk that might return an inconsistent or outdated instruction and associated data, which is not useable in subsequent processing.

<FIG> is a flow diagram of a process <NUM> for controlling a latency in a synchronization event, in accordance with some implementations. The process <NUM> is implemented by a processor <NUM> of a system module <NUM> having one or more processors <NUM> and a memory system. The memory system of the system module <NUM> includes a core cache <NUM> of each processor <NUM>, a cluster cache <NUM> accessible to a plurality of processors <NUM> of a processing cluster <NUM>, a cache <NUM> accessible to a plurality of processing clusters <NUM>, and a memory <NUM> (e.g., a DRAM). Optionally, the cluster cache <NUM> stores one or more memory access queues <NUM> for the processors <NUM> coupled to the cluster cache <NUM>. The process <NUM> expedites a synchronization event and reduces its latency by skipping translations of speculative memory accesses in the one or more memory access queues <NUM>.

A processor <NUM> receives (<NUM>) a request <NUM> for a context synchronization event or a request <NUM> for a data synchronization event. In some implementations, the context synchronization event corresponds to an application ASID change (i.e., a termination of a first application <NUM>-<NUM> to initiate a second application <NUM>-<NUM>), a virtual machine VMID change (i.e., a termination of a first virtual machine <NUM>-<NUM> to initiate a second virtual machine <NUM>-<NUM>), or a system call for updating a system register <NUM>. This context synchronization event is optionally triggered by one or more of: page table management, system calls, and exception return. Alternatively, in some implementations, the data synchronization event updates registers <NUM> associated with a virtual machine <NUM> implemented on the processor <NUM>. In response to the request <NUM> or <NUM>, the processor <NUM> issues (<NUM>) a request (e.g., including a barrier instruction) to force memory access completion. The request is transmitted (<NUM>) to each cache <NUM>, <NUM>, or <NUM>. The processor <NUM> identifies (<NUM>) speculative memory access requests in the one or more memory access queues <NUM>, e.g., marks each speculative memory access request with a flag. An example flag is "purged, with non-response". The processor <NUM> automatically purges (<NUM>) address translations associated with the speculative memory access requests in accordance with a determination that each speculative memory access request is marked. In some implementations, these address translations are terminated prematurely (<NUM>), and the processor <NUM> does not fill (<NUM>) any translation caching structure (e.g., TLBs, table walk caches). Data, if fetched by the speculative memory access requests, cannot be applied (<NUM>) by the IFU <NUM>, REU <NUM>, LSU <NUM>, or MMU <NUM> of the same processor <NUM> or any other processor <NUM>. The synchronization event may be initiated independently of purging of the translations, e.g., prior to, subsequently to, or concurrently with purging of the translations. Stated another way, in some situations, the synchronization event is initiated without waiting for initiation or completion of the translations.

The process <NUM> terminates speculative address translations at the time of the synchronization event, thereby allowing the synchronization event to be completed without being delayed by latencies caused by the speculative address translations. In an example, a synchronization event (e.g., ISB or DSB) completes in <NUM> clock cycles, and can be extended to more than <NUM> clock cycles if long latency speculative address translations are not purged. During the course of purging the speculative address translations, system registers <NUM> do not need to be sampled and copied across translation units, and processing resources can be reserved to implement heavy operating system or hypervisor context switching, page table management, and system calls. By these means, skipping the speculative address translations enhances power consumption and performance of the SoC <NUM> at the time of the synchronization event.

It should be understood that the particular order in which the operations in <FIG> have been described are merely exemplary and are not intended to indicate that the described order is the only order in which the operations could be performed. One of ordinary skill in the art would recognize various ways to reorder the operations described herein. Additionally, it should be noted that details of other processes described herein with respect to <FIG> and <FIG> are also applicable in the process <NUM> in an exchangeable manner. For brevity, these details are not repeated here.

<FIG> is a flow diagram of a method <NUM> for managing memory access, in accordance with some implementations. Method <NUM> is implemented at a respective processor <NUM> of one or more processors <NUM> that are configured to execute one or more virtual machines <NUM>. The one or more processors <NUM> are arranged into one or more processing clusters <NUM>). The respective processor <NUM> (e.g., the first processor <NUM>-<NUM> of the first cluster <NUM>-<NUM>) receives (<NUM>) a request for initiating a synchronization event. In response to the request (<NUM>), the respective processor <NUM> identifies (<NUM>) a subset of speculative memory access requests in one or more memory access request queues <NUM>, and automatically, in accordance with the identifying, purges (<NUM>) translations associated with the subset of speculative memory access requests. The respective processor <NUM> initiates (<NUM>) the synchronization event. In some embodiments, the synchronization event is initiated (<NUM>) independently of purging of the translations (<NUM>), e.g., prior to, subsequently to, or concurrently with purging of the translations.

In some implementations, each memory access request queues <NUM> includes (<NUM>) an ordered sequence of memory access requests, and the subset of speculative memory access requests are queued in anticipation of one or more instructions received subsequent to the request. Further, in some implementations, receiving the request includes (<NUM>) receiving a barrier instruction configured to force memory access completion. In response to the request, the respective processor <NUM> aborts (<NUM>) address translations of the subset of speculative memory access requests, and completes the barrier instruction within a first number of clock cycles. The translations associated with the subset of speculative memory access requests are configured to be completed (<NUM>) within a second number of clock cycles, and the first number is less than the second number.

In some implementations, the respective processor <NUM> is associated with a translation cache and initiates the synchronization event by for each speculative memory access request, terminating a corresponding memory access request to read from or write into a respective memory unit a respective data item, aborting filling the translation cache associated with the respective processor, and withholding the respective processor from using the respective data item. Further, in some implementations, the translation cache includes a translation lookaside buffer (TLB) <NUM> and a page table cache <NUM>. Additionally, in some implementations, the respective processor includes one of more of: an instruction fetch unit (IFU) <NUM> for fetching instructions and associated data from a first memory to a second memory faster than the first memory, a load/store unit (LSU) <NUM> for executing load and store instructions and generating virtual addresses, a rename/retire/dispatch unit (REU) <NUM> for register renaming and instruction retirement and dispatching, a memory management unit (MMU) <NUM> for managing memory access to caches and memory 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, and the IFU <NUM>, LSU <NUM>, REU <NUM>, MMU <NUM>, and prefetch engine of the respective processor are withheld from using the respective data item.

In some implementations, the respective processor <NUM> includes a memory management unit (MMU) <NUM> configured to manage the one or more memory access request queues <NUM>. In response to the request, the respective processor <NUM> generates a purge instruction to purge translations of the subset of speculative memory access requests. The MMU <NUM> identifies the subset of speculative memory access requests in the one or more memory access queues and purges the translations associated with the subset of speculative memory access requests.

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"). The translations associated with the subset of speculative memory access requests are automatically purged in accordance with a determination that each speculative memory access request is associated with the flag.

In some implementations, the one or more memory access request queues <NUM> include a data translation queue, an instruction translation queue, and a prefetch translation queue, and the subset of speculative memory access requests include at least one memory access request in the data, instruction, and prefetch translation queues <NUM>.

In some implementations, the respective processor <NUM> receives (<NUM>) a barrier instruction configured to force 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 for updating a system register <NUM>.

Alternatively, in some implementations, the respective processor <NUM> receives (<NUM>) a barrier instruction configured to force memory access completion to initiate a data synchronization event for updating registers associated with a virtual machine implemented on the respective processor. The barrier instruction includes a data synchronization barrier that is executed on a hypervisor layer or a firmware layer to force memory access completion of the speculative memory access requests to an operating system level or an application level. Further, in some embodiments, the barrier instruction includes (<NUM>) a hypervisor call from a guest operating system.

It should be understood that the particular order in which the operations in <FIG> have been described are merely exemplary and are not intended to indicate that the described order is the only order in which the operations could be performed. One of ordinary skill in the art would recognize various ways to reorder the operations described herein. Additionally, it should be noted that details of other processes described herein with respect to <FIG> are also applicable in the method <NUM> in an exchangeable manner. For brevity, these details are not repeated here.

The above description has been provided with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to be limiting to the precise forms disclosed.

The terminology used in the description of the various described implementations herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used in the description of the various described implementations and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, 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," when used in this specification, 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. Additionally, it will be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the claims to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain principles of operation and practical applications, to thereby enable others skilled in the art.

Claim 1:
A method for managing memory accesses, implemented at a respective processor of one or more processors that are configured to execute one or more virtual machines, the method comprising:
receiving (<NUM>) a request for initiating a synchronization event; and
in response to the request:
identifying (<NUM>) a subset of speculative memory access requests in one or more memory access request queues;
automatically, in accordance with the identifying, purging (<NUM>) translations associated with the subset of speculative memory access requests; and
initiating (<NUM>) the synchronization event,
wherein the respective processor includes a memory management unit, MMU (<NUM>), configured to manage the one or more memory access request queues, the method further comprising:
in response to the request, generating by the respective processor a purge instruction to purge translations of the subset of speculative memory access requests, wherein the MMU (<NUM>) identifies the subset of speculative memory access requests in the one or more memory access queues and purges the translations associated with the subset of speculative memory access requests.