Patent Description:
Peripheral devices, such as hardware accelerator devices, are used conventionally to handle operations that may be offloaded by an application that is executing on a host processor-based device. When the application determines that a particular operation on a specific dataset should be offloaded to the peripheral device, the application packages all data relevant to the operation (e.g., data-buffer pointer for the dataset, the type of operation to be performed, and the like, as non-limiting examples) into a work item descriptor. The application then transmits the work item descriptor to the peripheral device using an enqueue instruction, and may continue performing other tasks while the peripheral device performs the requested operation. When the peripheral device completes the requested operation, the peripheral device transmits a completion notification back to the application to inform the application that the operation is complete, and to provide a result of the operation to the application.

As peripheral devices leverage technologies such as shared virtual memory (SVM), existing mechanisms for address translation and memory paging (e.g., using Peripheral Component Interconnect Express (PCIe) Address Translation Services (ATS), Page Request Interface (PRI), and Process Address Space Identifiers (PASIDs), as non-limiting examples) enable such peripheral devices to perform Direct Memory Access (DMA) operations to and from guest virtual addresses. However, it is possible for physical memory pages corresponding to the guest virtual addresses to be "paged out," or not resident in physical memory, at the time the DMA operations are made. This may result in address translation exceptions such as page faults being encountered by a peripheral device, causing negative impacts on latency and/or throughput for the operations that were offloaded to the peripheral device.

Some conventional approachs to minimizing page faults and associated page requests by peripheral devices involve offloading operations to a peripheral device only when a paging operation is expected to be rare, or offloading only operations that access virtual addresses which are known to have been very recently read or written (creating a high likelihood that the corresponding physical memory pages are resident in memory). These approaches, though, limit the number of scenarios in which offloading operations may be employed. Another conventional approach involves "pinning" memory pages to ensure that physical memory pages associated with the shared virtual memory addresses (along with the page tables that map such physical memory pages) are always resident. However, the pinning approach generally goes against the goals of efficiently offloading work to peripheral devices that seek to queue work directly from within user-mode applications without the need for expensive system calls or hypercalls.

Still another conventional approach involves "pre-touching" memory pages by performing otherwise unnecessary memory accesses to an address space associated with the offloaded work to ensure that the memory pages are resident before any page requests are performed by a peripheral device. While this approach may reduce the likelihood of page fault handling by the peripheral device, it is inconsistent with the programming model for offloading operations, may require more work by a processor device before or after the queuing of the offloaded operation, and may require care to avoid accidentally polluting caches. Moreover, because the pre-touching operations and the enqueue operation are not performed atomically, there may be no guarantee that a pre-touching operation will be executed temporally close to an enqueue operation.

Accordingly, a more efficient mechanism for reducing the occurrence of page faults associated with memory operations by peripheral devices is desirable. <CIT> describes hiding the page miss translation latency for program fetches. In <CIT> whenever an access is requested by CPU, an L1I cache controller does a-priori lookup of whether the virtual address plus the fetch packet count of expected program fetches crosses a page boundary. If the access crosses a page boundary, the L1I cache controller will request a second page translation along with the first page. This pipelines requests to a µTLB without waiting for the L1I cache controller to begin processing the second page requests. This becomes a deterministic prefetch of the second page translation request. The translation information for the second page is stored locally in an L1I cache controller and used when the access crosses the page boundary. <CIT> describes a virtual address translator that comprises a content addressed memory and a word addressed memory. A task name and subsegment number from a virtual address supplied by a processor are employed as a key word to search a content addressed memory and read out a subsegment descriptor if the key word is matched. The subsegment descriptor includes an absolute base address which is added to a deflection field to obtain an absolute memory address. The memory address is applied to a memory to permit transfer of a word between the processor and the memory. The processor may present any one of several task names depending upon whether the memory reference is made for an instruction or data for the processor, or for an instruction or data for an I/O connected to the processor. Bounds, residency and access privileges are checked using the subsegment descriptor. If a search of the content addressed memory reveals that the desired subsegment descriptor is not in the word addressed memory, the translator obtains the descriptor from memory and then generates the desired absolute memory address. The translator is provided with circuits generating values which indicate the efficiency of its operation. Controls are provided for selecting any one of several widths for the subsegment and deflection fields of virtual addresses received from the processor.

Exemplary embodiments disclosed herein provide speculative address translation in processor-based devices. In this regard, in one exemplary embodiment, a processor-based device provides a processing element (PE) that expands the functionality of a memory-pointer-referencing (MPR) instruction (e.g., an enqueue instruction for offloading operations to a peripheral device, as a non-limiting example) to also perform speculative address translation of a memory pointer referenced by the instruction. The PE includes an execution pipeline circuit that comprises an instruction decode stage configured to receive the MPR instruction, wherein the MPR instruction references a plurality of bytes (such as a <NUM>-byte work descriptor, as a non-limiting example) that include one or more virtual memory addresses. After receiving the MPR instruction, the PE transmits a request for address translation of the virtual memory address to a memory management unit (MMU) of the PE. The MMU then performs speculative address translation of the virtual memory address into a corresponding translated memory address, and the PE executes the MPR instruction using an execute stage of the execution pipeline circuit. In some embodiments, if the MMU detects an address translation error while performing the speculative address translation (e.g., due to a physical memory page not being resident in memory), the MMU may raise an address translation exception (e.g., a page fault, as a non-limiting example) to an appropriate exception level. For instance, the address translation exception may be raised to a guest operating system (OS) if the address translation error occurs while translating a guest virtual address to a guest physical address, or may be raised to a hypervisor if the address translation error occurs while translating a guest physical address to a system physical address.

In another exemplary embodiment, a processor-based device includes a PE that comprises an execution pipeline circuit comprising an instruction decode stage and an execute stage and an MMU. The PE is configured to receive, using the instruction decode stage, an MPR instruction that references a plurality of bytes that comprises a virtual memory address. The PE is further configured to transmit, to the MMU, a request for address translation of the virtual memory address. The PE is also configured to perform, using the MMU, speculative address translation of the virtual memory address into a corresponding translated memory address. The PE is additionally configured to execute, using the execute stage of the execution pipeline circuit, the MPR instruction.

In another exemplary embodiment, a method for performing speculative address translation in processor-based devices is provided. The method comprises receiving, using an instruction decode stage of an execution pipeline circuit of a PE of a processor-based device, an MPR instruction that references a plurality of bytes that comprises a virtual memory address. The method further comprises transmitting, to an MMU of the PE, a request for address translation of the virtual memory address. The method also comprises performing, by the MMU, speculative address translation of the virtual memory address into a corresponding translated memory address. The method additionally comprises executing, using an execute stage of the execution pipeline circuit, the MPR instruction.

In another exemplary embodiment, a non-transitory computer-readable medium is provided, the computer-readable medium having stored thereon computer-executable instructions which, when executed by a processor-based device, cause the processor-based device to receive an MPR instruction that references a plurality of bytes that comprises a virtual memory address. The computer-executable instructions further cause the processor-based device to transmit, to an MMU of the processor-based device, a request for address translation of the virtual memory address. The computer-executable instructions also cause the processor-based device to perform speculative address translation of the virtual memory address into a corresponding translated memory address. The computer-executable instructions additionally cause the processor-based device to execute the MPR instruction.

Those skilled in the art will appreciate the scope of the present disclosure and realize additional embodiments thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several embodiments of the disclosure, and together with the description serve to explain the principles of the disclosure.

In this regard, <FIG> illustrates an exemplary processor-based device <NUM> that provides a PE <NUM> for processing executable instructions. The PE <NUM> may comprise an individual processor core, including a logical execution unit and associated caches and functional units, of a central processing unit (CPU). The PE <NUM> of <FIG> includes an execution pipeline circuit <NUM> that is configured to execute an instruction stream comprising computer-executable instructions. The execution pipeline circuit <NUM> includes an instruction decode stage <NUM> for translating fetched instructions into control signals for instruction execution, and an execute stage <NUM> for actually performing instruction execution. Although not shown in <FIG>, the execution pipeline circuit <NUM> in some embodiments may include additional elements, such as a fetch stage for retrieving instructions for execution, a rename stage for allocating physical register file (PRF) registers from a PRF (not shown), a dispatch stage for issuing instructions for execution, and/or a commit stage for irrevocably updating the architectural state of the PE <NUM> based on the results of instruction execution. It is to be understood that some embodiments of the processor-based device <NUM> may comprise multiple PEs <NUM> rather than the single PE <NUM> shown in the example of <FIG>, and further that some embodiments of the PE <NUM> may include fewer or more stages within the execution pipeline circuit <NUM> than those illustrated in the example of <FIG>.

The PE <NUM> of <FIG> further comprises an MMU <NUM>, which provides virtual memory functionality by performing address translation of virtual memory addresses to physical memory addresses. Some embodiments of the MMU <NUM> include a translation lookaside buffer (TLB) <NUM>, which provides TLB entries <NUM>(<NUM>)-<NUM>(T) for caching recent translations of virtual memory addresses to physical memory addresses for subsequent reuse. The PE <NUM> in some embodiments also comprises a register <NUM>. The register <NUM> may comprise, for example, a general purpose register (GPR) or a system register (SR), as non-limiting examples, and may be one of a plurality of registers (not shown). The PE <NUM> according to some embodiments is communicatively coupled to a system memory <NUM> of the processor-based device <NUM>. The system memory <NUM> may comprise, e.g., dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), or static random access memory (SRAM), as non-limiting examples.

The processor-based device <NUM> of <FIG> and the constituent elements thereof may encompass any one of known digital logic elements, semiconductor circuits, processing cores, and/or memory structures, among other elements, or combinations thereof. Embodiments described herein are not restricted to any particular arrangement of elements, and the disclosed techniques may be easily extended to various structures and layouts on semiconductor sockets or packages. It is to be understood that some embodiments of the processor-based device <NUM> may include elements in addition to those illustrated in <FIG>. For example, the PE <NUM> may further include one or more instruction caches, unified caches, memory controllers, interconnect buses, and/or additional memory devices, caches, and/or controller circuits.

In the example of <FIG>, the PE <NUM> is executing a hypervisor <NUM> for providing virtualization functionality. Executing within the hypervisor <NUM> is a virtual machine (VM) <NUM>, within which a guest OS <NUM> is executing. The guest OS <NUM>, in turn, is executing an application <NUM> (i.e., a software application comprising computer-executable instructions that are executable by the PE <NUM>). The application <NUM> of <FIG> is communicatively coupled to a peripheral device <NUM> via an interface (not shown), such as an interface supporting the Peripheral Component Interconnect Express (PCIe) standard. The peripheral device <NUM> may comprise, e.g., a hardware accelerator device.

In the course of execution, the application <NUM> may identify a processing task or operation that may be performed more efficiently or quickly by the peripheral device <NUM>. The application <NUM> thus may elect to offload the processing task to the peripheral device <NUM> by packaging data relevant to the operation into a work item descriptor, and executing an enqueue instruction to transmit the work item descriptor to the peripheral device <NUM>. While performing the offloaded operation, the peripheral device <NUM> may perform Direct Memory Access (DMA) operations to and from guest virtual addresses allocated by the guest OS <NUM> for use by the application <NUM>. However, it is possible for physical memory pages corresponding to the guest virtual addresses to be "paged out," or not resident in the guest physical memory managed by the guest OS <NUM> or the system physical memory managed by the hypervisor <NUM>, at the time the DMA operations are performed. This may result in address translation exceptions such as page faults being encountered by the peripheral device <NUM>, causing negative impacts on latency and/or throughput of the operations offloaded to the peripheral device <NUM>.

It is to be understood that page faults encountered by the peripheral device <NUM> are inherently more expensive, in terms of latency and throughput effects, than page faults handled by the PE <NUM>. The additional latency incurred by the peripheral device <NUM> in handling a page fault is in addition to the latency associated with the peripheral device <NUM> beginning the offloaded work via an Address Translation Service (ATS) operation. If the ATS operation fails, the peripheral device <NUM> must perform, at a minimum, a Page Request Interface (PRI) operation followed by another ATS operation, and may also be required to perform context switching on the peripheral device <NUM> itself. Additionally, page requests performed by the peripheral device <NUM> must funnel through a single queue in an MMU responsible for translating memory addresses originating from the peripheral device <NUM> (e. g, an input/output memory management unit (IOMMU) or a system memory management unit (SMMU)), which may require the hypervisor <NUM> to demultiplex the page requests in per-VM queues (not shown). Each VM, such as the VM <NUM>, would then need to further dequeue and parellelize the page requests for efficient processing.

In this regard, the PE <NUM> is configured to provide speculative address translation. In an exemplary embodiment, the PE <NUM> is configured to support an MPR instruction <NUM> that may be incorporated into applications such as the application <NUM>. The MPR instruction <NUM> may be implemented within the PE <NUM> as a dedicated instruction with a unique opcode provided by an instruction set architecture (ISA) of the PE <NUM>. Alternatively or additionally, the MPR instruction <NUM> may be a conventional instruction to which additional operands and/or opcode bits are added to accomplish the functionality described herein. The MPR instruction <NUM> may comprise any instruction that references one or more memory pointers for which speculative address translation is to be performed in addition to the functionality of the MPR instruction. Thus, as a non-limiting example, the MPR instruction <NUM> in some embodiments may comprise an enqueue instruction directed to the peripheral device <NUM> to enqueue a work descriptor.

The MPR instruction <NUM> in <FIG> references a plurality of bytes <NUM> that includes a virtual memory address <NUM> (e.g., a virtual memory address to which the peripheral device <NUM> may perform a DMA operation in the future). The MPR instruction <NUM> may reference the plurality of bytes <NUM> by, for example, accessing the plurality of bytes <NUM> at a fixed location in memory, or by receiving, as a parameter, a memory address at which the plurality of bytes <NUM> may be accessed or an identifier of one or more registers that store the plurality of bytes <NUM>. The plurality of bytes <NUM> may comprise, as a non-limiting example, a <NUM>-byte work descriptor to be enqueued to the peripheral device <NUM>. It is to be understood that, while <FIG> shows only one virtual memory address <NUM>, the plurality of bytes <NUM> in some embodiments may contain multiple memory addresses.

In some embodiments, the PE <NUM> is configured to provide a mechanism associated with the MPR instruction <NUM> to indicate where among the plurality of bytes <NUM> the virtual memory address <NUM> is located. For example, some embodiments may provide that the MPR instruction <NUM> always accesses a fixed location within the plurality of bytes <NUM> to retrieve the virtual memory address <NUM>, while in some embodiments a location of the virtual memory address <NUM> within the plurality of bytes may be indicated by an address indicator (not shown) provided as part of an opcode of the MPR instruction <NUM>. According to some embodiments, the MPR instruction <NUM> may reference an address indicator (not shown) that indicates a location of the virtual memory address <NUM> within the plurality of bytes <NUM>. For instance, each bit of eight (<NUM>) bits of a byte of the plurality of bytes <NUM> of the MPR instruction <NUM> may be used as an address indicator to indicate which <NUM>-bit values stored within the plurality of bytes <NUM> correspond to virtual memory addresses. Upon execution of the MPR instruction <NUM>, the virtual memory address <NUM> is retrieved from the plurality of bytes <NUM> based on the address indicator.

Some embodiments may provide that an address indicator, such as the address indicator <NUM>, may be stored in a register such as the register <NUM>. The register <NUM> may be identified by a register identifier (not shown) provided as part of the MPR instruction <NUM> (e.g., within the plurality of bytes <NUM>, or as a parameter of the MPR instruction <NUM>, as non-limiting examples). Before executing the MPR instruction <NUM>, the PE <NUM> may be configured to store the address indicator <NUM> in the register <NUM>, and when the MPR instruction <NUM> is subsequently executed, the address indicator <NUM> may be read from the register <NUM> based on the register identifier. The virtual memory address <NUM> may then be retrieved from the plurality of bytes <NUM> based on the address indicator <NUM>.

Additionally, some embodiments may employ the register <NUM> to store additional parameter data that may be useful for speculative address translation. For instance, the PE <NUM> in some embodiments may also store in the register <NUM> a page count indicator <NUM> that indicates a count of memory pages that may require address translation for the virtual memory address <NUM>. The page count indicator <NUM> in some embodiments may be stored as part of the plurality of bytes <NUM>, or as part of the opcode of the MPR instruction <NUM>.

During execution of the application <NUM>, the instruction decode stage <NUM> of the execution pipeline circuit <NUM> of the PE <NUM> receives the MPR instruction <NUM> referencing the plurality of bytes <NUM> including the virtual memory address <NUM>. The PE <NUM> is configured to transmit a request <NUM> for address translation of the virtual memory address <NUM> to the MMU <NUM> of the PE <NUM>. The MMU <NUM> then performs speculative address translation of the virtual memory address <NUM> into a corresponding translated memory address <NUM> (e.g., a guest physical address or a system physical address, as non-limiting examples). The operations performed by the MMU <NUM> for performing the speculative address translation may correspond to conventional operations performed in the course of translating a virtual memory address into a physical memory address, such as performing page table walks, updating translation tables (not shown) to include the results of the speculative address translation, and/or caching the results of the speculative address translation in the TLB <NUM>.

In some embodiments, the MPR instruction <NUM> may reference a TLB indicator (not shown) that indicates whether a TLB entry of the plurality of TLB entries <NUM>(<NUM>)-<NUM>(T) is allocated for the speculative address translation of the virtual memory address <NUM> into the translated memory address <NUM>. If the TLB indicator is set (i.e., indicates a value of true), the TLB <NUM> is updated by the MMU <NUM> in conventional fashion as part of performing the speculative address translation. Conversely, if the TLB indicator is not set, the MMU <NUM> may not update the TLB <NUM> to avoid polluting the TLB <NUM> with the results of the speculative address translation. Some embodiments may provide that, if the TLB indicator is not set, the MMU <NUM> may update the TLB <NUM>, but may assign a weight to the allocated TLB entry of the plurality of TLB entries <NUM>(<NUM>)-<NUM>(T) to indicate that the allocated TLB entry is to be evicted before other TLB entries of the plurality of TLB entries <NUM>(<NUM>)-<NUM>(T). The MPR instruction <NUM> may reference the TLB indicator by, for example, receiving a parameter specifying a location of the TLB indicator in memory, in a register, or within the plurality of bytes <NUM>, or by accessing the TLB indicator stored at a fixed location in memory, in a register, or within the plurality of bytes <NUM>.

As noted above, the MPR instruction <NUM> according to some embodiments comprises an enqueue instruction directed to the peripheral device <NUM>. Accordingly, in such embodiments, the PE <NUM> is configured to execute the MPR instruction <NUM> using the execute stage <NUM> of the execution pipeline circuit <NUM>, which results in an enqueue command <NUM> referencing the plurality of bytes <NUM> being transmitted to the peripheral device <NUM>.

In some embodiments, the MMU <NUM> may detect an address translation error <NUM> while performing the speculative address translation of the virtual memory address <NUM>. The address translation error <NUM> may indicate, for example, that a memory page corresponding to the translated memory address <NUM> is not resident in memory. In response, the MMU <NUM> of the PE <NUM> may raise an address translation exception <NUM> (e.g., a page fault exception, as a non-limiting example).

Some embodiments may provide that the MMU <NUM> raises the address translation exception <NUM> to an appropriate exception level depending on a stage of address translation at which the address translation error <NUM> occurs. For instance, the address translation error <NUM> may occur as the MMU <NUM> performs a speculative address translation of a guest virtual address into a guest physical address of the guest OS <NUM> (i.e., a stage one (<NUM>) translation error). This may occur, for example, if the virtual memory address <NUM> is a guest virtual address of the guest OS <NUM>. Accordingly, the MMU <NUM> may raise the address translation exception <NUM> to the guest OS <NUM> for handling. In some embodiments, the address translation error <NUM> may occur as the MMU <NUM> performs the speculative address translation of a guest physical address into a system physical address of the PE <NUM> (i.e., a stage two (<NUM>) translation error). For instance, the virtual memory address <NUM> may comprise a guest physical address of the guest OS <NUM>, or may comprise a guest virtual address of the guest OS <NUM> that requires two stages of translation. In response to a stage two (<NUM>) translation error, the MMU <NUM> may raise the address translation exception <NUM> to the hypervisor <NUM> for handling. Some embodiments may provide that the MMU <NUM> raises the address translation exception <NUM> to the hypervisor <NUM> for handling regardless of whether the address translation exception <NUM> occurs as a result of a stage one (<NUM>) translation error or a stage two (<NUM>) translation error.

In embodiments in which the MPR instruction <NUM> is used to carry out an operation such as enqueuing the plurality of bytes <NUM> to the peripheral device <NUM>, the MPR instruction <NUM> may reference a synchronicity indicator (not shown) to indicate whether any address translation errors, such as the address translation error <NUM>, are reported synchronously or asynchronously with respect to the operation. The MPR instruction <NUM> may reference the synchronicity indicator by, for example, receiving a parameter specifying a location of the synchronicity indicator in memory, in a register, or within the plurality of bytes <NUM>, or by accessing the synchronicity indicator stored at a fixed location in memory, in a register, or within the plurality of bytes <NUM>.

Thus, in the example where the MPR instruction <NUM> is an enqueue instruction directed to the peripheral device <NUM>, the address translation error <NUM> may be reported synchronously prior to transmitting the enqueue command <NUM> to the peripheral device <NUM> if the synchronicity indicator is set (e.g., has a value of true). The address translation error <NUM> may be reported using conventional architectural mechanisms for reporting synchronous translation errors, and may be reported one address translation error at a time or all at once. Conversely, the reporting of the address translation error <NUM> may be performed asynchronously in parallel with transmitting the enqueue command <NUM> to the peripheral device <NUM> if the synchronicity indicator is not set. The address translation error <NUM> may be recorded, e.g., in a syndrome register (not shown) for servicing by software. Note that, if asynchronous reporting is performed, a race condition may result between the reporting and subsequent handling of the address translation error <NUM> and the enqueue command <NUM> reaching the peripheral device <NUM>. This may result in the address translation error <NUM> not being serviced by the time the peripheral device <NUM> attempts to access a memory page corresponding to the virtual memory address <NUM>. In this case, the peripheral device <NUM> may need to perform a PRI operation in conventional fashion.

To provide a more detailed description of exemplary contents of a MPR instruction such as the MPR instruction <NUM> of <FIG>, <FIG> is provided. In <FIG>, an MPR instruction <NUM>, corresponding in functionality to the MPR instruction <NUM> of <FIG>, is shown. The MPR instruction <NUM> comprises an opcode <NUM> that indicates an operation to be performed by the PE <NUM> of <FIG> when the MPR instruction <NUM> is executed. The MPR instruction <NUM> references a <NUM>-byte work descriptor <NUM>, which in the example of <FIG> comprises a plurality of bytes <NUM>(<NUM>)-<NUM>(<NUM>) corresponding to the plurality of bytes <NUM> of <FIG>. The work descriptor <NUM> stores data relevant to an operation to be offloaded to a peripheral device such as the peripheral device <NUM> of <FIG>. The MPR instruction <NUM> may reference the work descriptor <NUM> by, for example, taking as a parameter a memory address at which the work descriptor <NUM> may be accessed, or an identifier of one or more registers that store the work descriptor <NUM>.

In the example of <FIG>, the first byte <NUM>(<NUM>) of the plurality of bytes <NUM>(<NUM>)-<NUM>(<NUM>) comprises a plurality of address indicators <NUM>(<NUM>)-<NUM>(<NUM>) that may be used to indicate which of the plurality of bytes <NUM>(<NUM>)-<NUM>(<NUM>) correspond to virtual memory addresses for which speculative address translation is to be performed. Each of the address indicators <NUM>(<NUM>)-<NUM>(<NUM>) comprises a bit of the byte <NUM>(<NUM>), and corresponds to a group of eight (<NUM>) bytes within the bytes <NUM>(<NUM>)-<NUM>(<NUM>) that may store a <NUM>-bit virtual address. In <FIG>, the bytes <NUM>(<NUM>)-<NUM>(<NUM>) are used to store a virtual memory address <NUM>(<NUM>), while the bytes <NUM>(<NUM>)-<NUM>(<NUM>) are used to store a virtual memory address <NUM>(<NUM>). Accordingly, the address indicators <NUM>(<NUM>) and <NUM>(<NUM>) may be set to indicate the locations of the virtual memory addresses <NUM>(<NUM>) and <NUM>(<NUM>) within the plurality of bytes <NUM>(<NUM>)-<NUM>(<NUM>).

The MPR instruction <NUM> of <FIG> further references additional indicators, including a register indicator <NUM>, a TLB indicator <NUM>, and a synchronicity indicator <NUM>, the functionality of each of which is discussed in greater detail above with respect to <FIG>. In some embodiments, the register indicator <NUM>, the TLB indicator <NUM>, and/or the synchronicity indicator <NUM> may comprise parameters that are specified as part of the MPR instruction <NUM>. Some embodiments may provide that the register indicator <NUM>, the TLB indicator <NUM>, and/or the synchronicity indicator <NUM> may be provided as part of a byte of the plurality of bytes <NUM>(<NUM>)-<NUM>(<NUM>), while in some embodiments the TLB indicator <NUM> and/or the synchronicity indicator <NUM> may be stored at a specified memory location or in a register indicated by the register indicator <NUM>.

<FIG> provide a flowchart <NUM> illustrating exemplary operations for performing speculative address translation by the PE <NUM> of <FIG>. For the sake of clarity, elements of <FIG> and <FIG> are referenced in describing <FIG>. It is to be understood that some operations illustrated in <FIG> may occur in an order other than that illustrated in <FIG> in some embodiments, and/or may be omitted in some embodiments. In <FIG>, operations according to some embodiments begin with the PE <NUM> storing, in the register <NUM>, the address indicator <NUM> that indicates a location of the virtual memory address <NUM> within the plurality of bytes <NUM> of the MPR instruction <NUM> (block <NUM>). In some embodiments, the PE <NUM> may also store, in the register <NUM>, the page count indicator <NUM> that indicates a count of memory pages requiring address translation for the virtual memory address <NUM> (block <NUM>).

The PE <NUM> receives, using the instruction decode stage <NUM> of the execution pipeline circuit <NUM> of the PE <NUM> of the processor-based device <NUM>, the MPR instruction <NUM> that references the plurality of bytes <NUM> that comprises the virtual memory address <NUM> (block <NUM>). In embodiments in which the plurality of bytes <NUM> provide an address indicator (such as the address indicators <NUM>(<NUM>) and <NUM>(<NUM>) of <FIG>), the PE <NUM> may retrieve the virtual memory address <NUM> from the plurality of bytes <NUM> based on the address indicator of the MPR instruction <NUM> (block <NUM>). In embodiments in which the address indicator <NUM> is stored in the register <NUM>, the PE <NUM> may read the address indicator <NUM> from the register <NUM> based on the register indicator <NUM> of the MPR instruction <NUM> (block <NUM>). The PE <NUM> may then retrieve the virtual memory address <NUM> from the plurality of bytes <NUM> based on the address indicator <NUM> (block <NUM>). The PE <NUM> then transmits, to the MMU <NUM> of the PE <NUM>, the request <NUM> for address translation of the virtual memory address <NUM> (block <NUM>). Operations then continue at block <NUM> of <FIG>.

Referring now to <FIG>, the PE <NUM> (i.e., using the MMU <NUM>) performs speculative address translation of the virtual memory address <NUM> into the corresponding translated memory address <NUM> (block <NUM>). In some embodiments, the operations of block <NUM> for performing the speculative address translation may be based on the page count indicator <NUM> (e.g., by performing address translation for the indicated number of memory pages) (block <NUM>). Some embodiments may provide that the operations of block <NUM> for performing the speculative address translation may be based on the TLB indicator <NUM> of the MPR instruction <NUM> (block <NUM>). Thus, for instance, the MMU <NUM> may allocate a TLB entry of the plurality of TLB entries <NUM>(<NUM>)-<NUM>(T) of the TLB <NUM> if the TLB indicator <NUM> is set, and may not allocate a TLB entry (or may allocate a TLB entry and assign a lower weight) if the TLB indicator <NUM> is not set.

The PE <NUM> then executes the MPR instruction <NUM> using the execute stage <NUM> of the execution pipeline circuit <NUM> (block <NUM>). In embodiments in which the MPR instruction <NUM> comprises an enqueue instruction, the operations of block <NUM> for executing the MPR instruction <NUM> comprises, responsive to executing the MPR instruction <NUM>, transmitting the enqueue command <NUM> that references the plurality of bytes <NUM> to the peripheral device <NUM> (block <NUM>). Operations then continue at block <NUM> of <FIG>.

Turning now to <FIG>, some embodiments may provide that the PE <NUM> detects, using the MMU <NUM>, the address translation error <NUM> while performing the speculative address translation (block <NUM>). The PE <NUM> thus raises the address translation exception <NUM> (block <NUM>). In some embodiments, the operations of block <NUM> for raising the address translation exception <NUM> are based on the synchronicity indicator <NUM> (block <NUM>). Thus, for instance, if the MPR instruction <NUM> comprises an enqueue instruction and the synchronicity indicator <NUM> indicates that the address translation exception <NUM> is to be raised synchronously, the PE <NUM> may stall the enqueue instruction until the address translation exception <NUM> is reported using existing architectural mechanisms for reporting synchronous translation errors (e.g., mechanisms used for a load instruction). Conversely, if the synchronicity indicator <NUM> indicates that the address translation exception <NUM> is to be raised asynchronously, the PE <NUM> may complete execution of the enqueue instruction in parallel with raising the address translation exception <NUM>.

Some embodiments may provide that the operations of block <NUM> for raising the address translation exception <NUM> may include raising the address translation exception <NUM> to the hypervisor <NUM> executing on the processor-based device <NUM> (i.e., regardless of whether the address translation exception <NUM> is raised in the course of translating a guest virtual address to a guest physical address, or translating a guest physical address to a system physical address) (block <NUM>). In embodiments in which the address translation error <NUM> comprises a stage one (<NUM>) translation error that occurs during translation of a guest virtual address to a guest physical address, the operations of block <NUM> for raising the address translation exception <NUM> may comprise the PE <NUM> raising the address translation exception <NUM> to the guest OS <NUM> executing within the VM <NUM> on the processor-based device <NUM> (block <NUM>). According to embodiments in which the address translation error <NUM> comprises a stage two (<NUM>) translation error that occurs during translation of a guest physical address to a system physical address, the operations of block <NUM> for raising the address translation exception <NUM> may comprise the PE <NUM> raising the address translation exception <NUM> to the hypervisor <NUM> on the processor-based device <NUM> (block <NUM>).

<FIG> is a block diagram of an exemplary processor-based device <NUM>, such as the processor-based device <NUM> of <FIG>, that provides speculative address translation. The processor-based device <NUM> may be a circuit or circuits included in an electronic board card, such as a printed circuit board (PCB), a server, a personal computer, a desktop computer, a laptop computer, a personal digital assistant (PDA), a computing pad, a mobile device, or any other device, and may represent, for example, a server or a user's computer. In this example, the processor-based device <NUM> includes a processor <NUM>. The processor <NUM> represents one or more general-purpose processing circuits, such as a microprocessor, central processing unit, or the like, and may correspond to the PE <NUM> of <FIG>. The processor <NUM> is configured to execute processing logic in instructions for performing the operations and steps discussed herein. In this example, the processor <NUM> includes an instruction cache <NUM> for temporary, fast access memory storage of instructions and an instruction processing circuit <NUM>. Fetched or prefetched instructions from a memory, such as from a system memory <NUM> over a system bus <NUM>, are stored in the instruction cache <NUM>. The instruction processing circuit <NUM> is configured to process instructions fetched into the instruction cache <NUM> and process the instructions for execution.

The processor <NUM> and the system memory <NUM> are coupled to the system bus <NUM> and can intercouple peripheral devices included in the processor-based device <NUM>. As is well known, the processor <NUM> communicates with these other devices by exchanging address, control, and data information over the system bus <NUM>. For example, the processor <NUM> can communicate bus transaction requests to a memory controller <NUM> in the system memory <NUM> as an example of a peripheral device. Although not illustrated in <FIG>, multiple system buses <NUM> could be provided, wherein each system bus constitutes a different fabric. In this example, the memory controller <NUM> is configured to provide memory access requests to a memory array <NUM> in the system memory <NUM>. The memory array <NUM> is comprised of an array of storage bit cells for storing data. The system memory <NUM> may be a read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), etc., and a static memory (e.g., flash memory, static random access memory (SRAM), etc.), as non-limiting examples.

Other devices can be connected to the system bus <NUM>. As illustrated in <FIG>, these devices can include the system memory <NUM>, one or more input devices <NUM>, one or more output devices <NUM>, a modem <NUM>, and one or more display controllers <NUM>, as examples. The input device(s) <NUM> can include any type of input device, including, but not limited to, input keys, switches, voice processors, etc. The output device(s) <NUM> can include any type of output device, including, but not limited to, audio, video, other visual indicators, etc. The modem <NUM> can be any device configured to allow exchange of data to and from a network <NUM>. The network <NUM> can be any type of network, including, but not limited to, a wired or wireless network, a private or public network, a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), a BLUETOOTH™ network, and the Internet. The modem <NUM> can be configured to support any type of communications protocol desired. The processor <NUM> may also be configured to access the display controller(s) <NUM> over the system bus <NUM> to control information sent to one or more displays <NUM>. The display(s) <NUM> can include any type of display, including, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, etc..

The processor-based device <NUM> in <FIG> may include a set of instructions <NUM> to be executed by the processor <NUM> for any application desired according to the instructions. The instructions <NUM> may be stored in the system memory <NUM>, processor <NUM>, and/or instruction cache <NUM> as examples of non-transitory computer-readable medium <NUM>. The instructions <NUM> may also reside, completely or at least partially, within the system memory <NUM> and/or within the processor <NUM> during their execution. The instructions <NUM> may further be transmitted or received over the network <NUM> via the modem <NUM>, such that the network <NUM> includes the computer-readable medium <NUM>.

While the computer-readable medium <NUM> is shown in an exemplary embodiment to be a single medium, the term "computer-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions <NUM>. The term "computer-readable medium" shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by a processing device and that cause the processing device to perform any one or more of the methodologies of the embodiments disclosed herein. The term "computer-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical medium, and magnetic medium.

The embodiments disclosed herein include various steps. The steps of the embodiments disclosed herein may be formed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware and software process.

The embodiments disclosed herein may be provided as a computer program product, or software process, that may include a machine-readable medium (or computer-readable medium) having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the embodiments disclosed herein. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes: a machine-readable storage medium (e.g., ROM, random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, flash memory devices, etc.), and the like.

Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the embodiments disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer-readable medium and executed by a processor or other processing device, or combinations of both. The components of the processor-based devices described herein may be employed in any circuit, hardware component, integrated circuit (IC), or IC chip, as examples. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends on the particular application, design choices, and/or design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.

Claim 1:
A processor-based device (<NUM>), comprising:
a processing element, PE, (<NUM>) comprising:
an execution pipeline circuit (<NUM>) comprising an instruction decode stage (<NUM>) and an execute stage (<NUM>); and
a memory management unit, MMU (<NUM>);
the PE configured to:
receive (<NUM>), using the instruction decode stage, a memory-pointer-referencing, MPR, instruction (<NUM>) that references a plurality of bytes (<NUM>) that comprises a virtual memory address (<NUM>), wherein the MPR instruction comprises an enqueue instruction directed to a peripheral device;
transmit (<NUM>), to the MMU, a request (<NUM>) for address translation of the virtual memory address;
perform (<NUM>), using the MMU, speculative address translation of the virtual memory address into a corresponding translated memory address (<NUM>);
execute (<NUM>), using the execute stage of the execution pipeline circuit, the MPR instruction; and
responsive to executing the MPR instruction, transmit an enqueue command referencing the plurality of bytes to the peripheral device.