Method and apparatus for high-performance page-fault handling for multi-tenant scalable accelerators and machine-readable medium

Abstract

Apparatus and methods for efficient page retrieval error handling. For example, one embodiment of the apparatus includes: one or more accelerator engines for processing work descriptors submitted by a client to a plurality of job columns; and error handling hardware logic associated with the one or more accelerator engines, the error handling hardware logic being configured to implement a specified page retrieval error handling mode for each job column of the plurality of job columns, the page retrieval error handling mode including a first page retrieval error handling mode and a second page retrieval error handling mode.

Description

[Technical Field]

[0001] This invention generally relates to the field of computer processors. More specifically, this invention relates to a method and apparatus for efficient page fault handling in multi-tenant scalable accelerators. [Previous Technology]

[0002] An instruction set or instruction set architecture (ISA) is part of a programmed computer architecture, comprising native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I / O). It should be noted that the term "instruction" here usually refers to macro instructions—instructions to be provided to the processor for execution, as opposed to microinstructions or microoperations—that is, the result of the processor decoder decoding the macro instructions. Microinstructions or microoperations can be configured to instruct execution units on the processor to perform operations to implement the logic associated with the macro instructions.

[0003] An ISA differs from a microarchitecture, which is a set of processor design techniques used to implement an instruction set. Processors with different microarchitectures can share a common instruction set. For example, the Intel® Pentium 4 processor, the Intel® Core™ processor, and processors from Advanced Micro Devices (AMD) in Sunnyvale, California, implement nearly the same version of the x86 instruction set (with some extensions added to newer versions), but have different internal designs. For example, the same register architecture of an ISA can be implemented differently in different microarchitectures using known techniques, including dedicated physical registers, one or more dynamically configured physical registers using register renaming mechanisms (e.g., using Register Alias ​​Tables (RATs), Reorder Buffers (ROBs), and retired register files). Unless otherwise specified, the terms register architecture, register file, and register are used herein to indicate their visibility to the software / programmer and the way registers are specified. When differentiation is needed, the adjectives “logic,” “architecture,” or “software visible” will be used to indicate a register / file in a register architecture, while different adjectives will be used to specify a register in a given microarchitecture (e.g., entity register, reorder buffer, retired register, register pool). [Summary of the Invention]

[0004] and

Implementation Method

[0035] In the following description, various specific details are described for illustrative purposes to provide a full understanding of the embodiments of the invention described below. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, known structures and apparatuses are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention. Demonstration Computer Architecture

[0036] The following details describe an exemplary computer architecture. In this art, other known system designs and configurations for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally, a wide variety of systems or electronic devices incorporating the processors and / or other execution logic disclosed herein are also generally suitable.

[0037] Figure 1 illustrates an embodiment of an exemplary system. The multiprocessor system 100 is a point-to-point interconnect system and includes a plurality of processors, including a first processor 170 and a second processor 180, coupled via a point-to-point interconnect 150. In some embodiments, the first processor 170 and the second processor 180 are homogeneous. In some embodiments, the first processor 170 and the second processor 180 are heterogeneous.

[0038] Processors 170 and 180 are shown to include integrated memory controller (IMC) unit circuitry 172 and 182, respectively. Processor 170 also includes point-to-point (PP) interfaces 176 and 178 as part of its interconnect controller unit; similarly, the second processor 180 also includes point-to-point (PP) interfaces 186 and 188. Processors 170 and 180 can exchange information via point-to-point (PP) interconnect 150 using PP interface circuitry 178 and 188. IMCs 172 and 182 couple processors 170 and 180 to individual memories, namely memories 132 and 134, which may be portions of the main memory locally attached to the individual processors.

[0039] Processors 170 and 180 may each use point-to-point interface circuits 176, 194, 186, and 198 to exchange information with chipset 190 via individual PP interconnects 152 and 154. Chipset 190 may selectively exchange information with coprocessor 138 via high-efficiency interface 192. In some embodiments, coprocessor 138 is a special-purpose processor, such as a high-volume MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.

[0040] A shared cache (not shown) may be contained in or outside of processors 170 and 180, but still connected to the processors via PP interconnect, so that local cache information of any one or both processors can be stored in the shared cache if one processor is placed in a low-power mode.

[0041] Chipset 190 may be coupled to a first interconnect 116 via interface 196. In some embodiments, the first interconnect 116 may be a peripheral component interconnect (PCI) interconnect, or an interconnect such as a fast PCI interconnect or another I / O interconnect. In some embodiments, one of the interconnects is coupled to a power control unit (PCU) 117, which may include circuitry, software, and / or firmware to perform power management operations relating to processors 170, 180, and / or coprocessor 138. PCU 117 provides control information to a voltage regulator to cause the voltage regulator to generate an appropriate regulated voltage. PCU 117 also provides control information to control the generated operating voltage. In various embodiments, PCU 117 may include various power management logic units (circuitry) for performing hardware-based power management. This power management may be processor-wide controlled (e.g., for various processor hardware and may be triggered by workload and / or power, thermal, or other processor limitations) and / or power management may be performed in response to external sources (e.g., platform or power management sources or system software).

[0042] The PCU 117 is illustrated as logic separate from processor 170 and / or processor 180. In other cases, the PCU 117 may execute on one or more cores (not shown) of processor 170 or 180. In some cases, the PCU 117 may be implemented as a microcontroller (dedicated or general purpose) or configured to execute its own dedicated power management code, sometimes referred to as P-code or other control logic. In other embodiments, the power management operations performed by the PCU 117 may be implemented outside the processor, for example, by a separate power management integrated circuit (PMIC) or another component outside the processor. In other examples, the power management operations performed by the PCU 117 may be implemented in the BIOS or other system software.

[0043] Various I / O devices 114 may be coupled to the first interconnect 116 together with an interconnect (bus) bridge 118 that couples the first interconnect 116 to the second interconnect 120. In some embodiments, one or more additional processors 115, such as coprocessors, high-efficiency MIC processors, GPGPUs, accelerators (e.g., graphics accelerators or digital signal processor (DSP) units), field programmable gate arrays (FPGAs), or any other processor systems, are coupled to the first interconnect 116. In some embodiments, the second interconnect 120 may be a low pin count (LPC) interconnect. Various devices may be coupled to the second interconnect 120, including, for example, a keyboard and / or mouse 122, a communication device 127, and storage unit circuitry 128. Storage unit circuitry 128 may be a disk drive or other mass storage device, which in some embodiments may contain instructions / code and data 130. Furthermore, audio I / O 124 may be coupled to the second interconnect 120. Note that other architectures besides the point-to-point architecture described above are also possible. For example, in addition to point-to-point architectures, systems such as multiprocessor system 100 can also implement multi-interconnect or other similar architectures. Demonstration of core architecture, processor, and computer architecture.

[0044] For different purposes, processor cores can be implemented in different processors in different ways. For example, such core implementations may include: 1) general-purpose sequential cores intended for general-purpose computing; 2) high-efficiency general-purpose out-of-order cores intended for general-purpose computing; and 3) special-purpose cores primarily used for graphics and / or scientific (throughput) computing. Different processor implementations may include a CPU intended for general-purpose computing with one or more general-purpose sequential cores and / or one or more general-purpose out-of-order cores; and 2) a coprocessor containing one or more special-purpose cores primarily used for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate die separate from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (wherein this coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and / or scientific (throughput) logic, or a special purpose core); and 4) a system-on-a-chip (SoC) which may contain the above coprocessors, and additional functionality, on the same die as the CPU (sometimes referred to as an application core or application processor). An exemplary core architecture is described below, following the description of the exemplary processors and computer architectures.

[0045] FIG2 is a block diagram illustrating an embodiment of processor 200, which may include more than one core, may have an integrated memory controller, and may have integrated graphics. Solid blocks illustrate processor 200 having a single core 202A, a system agent 210, and a set of one or more interconnect controller unit circuits 216, while dashed blocks, in selected portions, illustrate alternative processors 200 having multiple cores 202(A)-(N), a set of one or more integrated memory controller unit circuits 214 within the system agent unit circuit 210, special purpose logic 208, and a set of one or more interconnect controller unit circuits 216. Note that processor 200 may be one of processors 170 or 180 of FIG1, or coprocessors 138 or 115.

[0046] Therefore, different embodiments of processor 200 may include: 1) a CPU having special purpose logic 208 that is integrated graphics and / or scientific (throughput) logic (which may include one or more cores (not shown)) and cores 202(A)-(N) that are one or more general purpose cores (e.g., general purpose sequential cores, general purpose out-of-order cores, or a combination of both); 2) a coprocessor having a large number of special purpose cores 202(A)-(N) primarily for graphics and / or scientific (throughput); and 3) a coprocessor having a large number of general purpose sequential cores 202(A)-(N). Therefore, processor 200 can be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (General Purpose Graphics Processing Unit Circuit), a high-throughput multi-integrated core (MIC) coprocessor (containing 30 or more cores), an embedded processor, or the like. The processor may be implemented on one or more chips. The processor 200 may be part of one or more substrates and / or may be implemented on one or more substrates using any of several process technologies, such as BiCMOS, CMOS, or NMOS.

[0047] The memory hierarchy includes one or more layers of cache unit circuits 204(A)-(N) within cores 202(A)-(N), a group of one or more shared cache unit circuits 206, and external memory (not shown), coupled to the group of integrated memory controller unit circuits 214. The group of one or more shared cache unit circuits 206 may include one or more intermediate caches, such as a second layer (L2), a third layer (L3), a fourth layer (L4), or other layer caches, such as the last layer cache (LLC), and / or combinations thereof. Although in some embodiments, the ring-based interconnect circuit 212 interconnects the special purpose logic 208 (e.g., integrated graphics logic), the group of shared cache unit circuits 206, and the system proxy unit circuit 210, other embodiments use any number of known techniques to interconnect these units. In some embodiments, consistency is maintained between the shared cache unit circuits 206 and one or more of the cores 202(A)-(N).

[0048] In some embodiments, one or more cores 202(A)-(N) are multithreaded. System proxy unit circuitry 210 includes these components to coordinate and operate cores 202(A)-(N). System proxy unit circuitry 210 may, for example, include power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may or may include logic and components required to adjust the power states of cores 202(A)-(N) and / or special purpose logic 208 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0049] Cores 202(A)-(N) can appear homogeneous or heterogeneous in terms of their architectural instruction sets; that is, two or more cores 202(A)-(N) can execute the same instruction set, while other cores can execute only a subset of that instruction set or a different instruction set. Demonstration core architecture block diagrams for sequential and out-of-order cores.

[0050] Figure 3(A) is a block diagram illustrating both a model sequential pipeline and a model register renaming out-of-order dispatch / execution pipeline according to an embodiment of the present invention. Figure 3(B) is a block diagram illustrating an exemplary embodiment of both a sequential architecture core and a model register renaming out-of-order dispatch / execution architecture core to be included in a processor according to an embodiment of the present invention. Solid blocks in Figures 3(A)-(B) illustrate the sequential pipeline and sequential core, while additional dashed blocks illustrate the register renaming out-of-order dispatch / execution pipeline and core. Assuming the sequential pattern is a subset of the out-of-order pattern, the out-of-order pattern will be described.

[0051] In Figure 3(A), the processor pipeline 300 includes a fetch stage 302, a select-length decode stage 304, a decode stage 306, a select-configure stage 308, a select-rename stage 310, a scheduling (also known as dispatch or dispatch) stage 312, a select register read / memory read stage 314, an execution stage 316, a write-back / memory write stage 318, a select exception handler 322, and a select-determine stage 324. One or more operations can be performed in each of these processor pipeline stages. For example, during the fetch stage 302, one or more instructions are fetched from the instruction memory, and during the decode stage 306, the one or more fetched instructions can be decoded, resulting in an address using a forward register port (e.g., a load store unit (LSU) address), and a branch transfer (i.e., an immediate shift or linked register (LR)) can be performed. In one embodiment, the decoding stage 306 and the register read / memory read stage 314 can be combined into a single pipeline stage. In one embodiment, during the execution stage 316, decoding instructions can be executed, LSU address / data pipelines can be executed to the Advanced Microcontroller Bus (AHB) interface, multiplication and addition operations can be performed, arithmetic operations with branching results can be performed, and so on.

[0052] For example, the exemplary register renaming out-of-order dispatch / execution core architecture can implement pipeline 300 as follows: 1) Instruction fetch 338 executes fetch and length decoding stages 302 and 304; 2) Decoding unit circuit 340 executes decoding stage 306; 3) Rename / configurator unit circuit 352 executes configuration stage 308 and rename stage 310; 4) Scheduler unit circuit 356 executes scheduling stage 312; 5) Physical register file unit circuit 358 and memory unit circuit 370 execute register read / memory read stage 314; execution cluster 360 executes execution stage 316; 6) Memory unit circuit 370 and physical register file unit circuit 358 execute write-back / memory write stage 318; 7) Various units (unit circuits) can be involved in exception handling stage 322; and 8) Retirement unit circuit 354 and physical register file unit circuit 358 execute determination stage 324.

[0053] Figure 3B shows that processor core 390 includes front-end unit circuitry 330 coupled to execution engine unit circuitry 350, and both are coupled to memory unit circuitry 370. Core 390 can be a Reduced Instruction Set Computing (RISC) core, Complex Instruction Set Computing (CISC) core, Very Long Instruction Word (VLIW) core, or a hybrid or alternative core type. In another option, core 390 can be a special purpose core, such as a networking or communication core, compression engine, coprocessor core, general-purpose computing graphics processing unit (GPGPU) core, graphics core, or the like.

[0054] The front-end unit circuit 330 may include a branch prediction unit circuit 332 coupled to an instruction cache unit circuit 334, which is coupled to an instruction translation lookahead buffer (TLB) 336, which is coupled to an instruction fetch unit circuit 338 coupled to a decoding unit circuit 340. In one embodiment, the instruction cache unit circuit 334 is included in a memory unit circuit 370 instead of the front-end unit circuit 330. The decoding unit circuit 340 (or decoder) may decode instructions and generate one or more microoperations, microcode entry points, microinstructions, other instructions, or other control signals decoded from or reflected or derived from the original instruction as output. The decoding unit circuit 340 may further include an address generation unit circuit (AGU, not shown). In one embodiment, the AGU uses a transfer register port to generate an LSU address and may further perform branch transfers (e.g., immediate offset branch transfer, LR register branch transfer, etc.). The decoding unit circuit 340 can be implemented using various mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), and so on. In one embodiment, core 390 includes microcode ROM (not shown) or other media storing microcode for use with certain macro instructions (e.g., in the decoding unit circuit 340 or in the front-end unit circuit 330). In one embodiment, the decoding unit circuit 340 includes micro-operations (micro-ops) or operation caches (not shown) to hold / cache decoding operations, microtags, or micro-operations generated during decoding or other stages of the processor pipeline 300. The decoding unit circuit 340 may be coupled to rename / configurator unit circuit 352 in the execution engine unit circuit 350.

[0055] The execution engine circuit 350 includes a renaming / configurer unit circuit 352 coupled to a retirement unit circuit 354 and a group of one or more scheduler circuits 356. The scheduler circuits 356 represent any number of different schedulers, including reserved stations, central command windows, etc. In some embodiments, the scheduler circuit 356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an arithmetic generation unit (AGU) scheduler / scheduling circuit, an AGU queue, etc. The scheduler circuit 356 is coupled to physical register file circuits 358. Each physical register file circuit 358 represents one or more physical register files, each storing one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction index for the address of the next instruction to be executed), etc. In one embodiment, physical register file unit circuitry 358 includes vector register unit circuitry, write mask register unit circuitry, and scalar register unit circuitry. These register units can provide architecture vector registers, vector mask registers, general-purpose registers, etc. Physical register file unit circuitry 358 is superimposed on retirement unit circuitry 354 (also referred to as a retirement queue or retirement array) to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer (ROB) and retired register files; using future files, history buffers, and retired register files; using a register graph and a pool of registers, etc.). Retirement unit circuitry 354 and physical register file circuitry 358 are coupled to execution cluster 360. Execution cluster 360 includes one or more sets of execution unit circuitry 362 and one or more sets of memory access circuitry 364. The execution unit circuit 362 can perform various arithmetic, logical, floating-point, or other types of operations (e.g., shift, addition, subtraction, multiplication) and is applicable to various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include several execution units or execution unit circuits dedicated to a particular function or group of functions, other embodiments may include only a single execution unit circuit or multiple execution unit / execution unit circuits that execute all functions. Scheduler circuit 356, physical register file unit circuit 358, and execution cluster 360 are shown as possibly multiple because some embodiments establish separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each having its own scheduler circuit, physical register file unit circuit, and / or execution cluster—and in separate memory access pipelines, some embodiments are implemented in which only the execution cluster of this pipeline has memory access unit circuit 364).It should also be understood that when separate pipelines are used, one or more of these pipelines may be dispatched / executed out of order, while others may be sequential.

[0056] In some embodiments, the execution engine unit circuit 350 can execute the load storage unit (LSU) address / data pipeline to the advanced microcontroller bus (AHB) interface (not shown), and address phase and write-back, data phase load, store, and branch.

[0057] The memory access circuitry 364 is coupled to the memory cell circuitry 370, which includes a data TLB cell circuitry 372 coupled to the data cache circuitry 374, which is coupled to the second-level (L2) cache circuitry 376. In an exemplary embodiment, the memory access cell circuitry 364 may include a load cell circuitry, a storage address cell circuitry, and a storage data cell circuitry, each coupled to the data TLB circuitry 372 in the memory cell circuitry 370. The instruction cache circuitry 334 is further coupled to the second-level (L2) cache cell circuitry 376 in the memory cell circuitry 370. In one embodiment, the instruction cache 334 and the data cache 374 are combined into a single instruction and data cache (not shown) in the L2 cache cell circuitry 376, the third-level (L3) cache cell circuitry (not shown), and / or the main memory. The L2 cache unit circuit 376 is coupled to caches of one or more other layers and ultimately to main memory.

[0058] Core 390 may support one or more instruction sets (e.g., x86 instruction set (with some extensions that have been added to newer versions); MIPS instruction set; ARM instruction set (with optional additional extensions, such as NEON)); and instructions included herein. In one embodiment, core 390 includes logic to support compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using compressed data. Example execution unit circuitry.

[0059] Figure 4 illustrates an embodiment of the execution unit circuit, as shown in the execution unit circuit 362 of Figure 3(B). As shown, the execution unit circuit 362 may include one or more ALU circuits 401, vector / SIMD unit circuits 403, load / store unit circuits 405, and / or branch / jump unit circuits 407. The ALU circuit 401 performs integer arithmetic and / or Boolean operations. The vector / SIMD unit circuit 403 performs vector / SIMD operations (e.g., SIMD / vector registers) on compressed data. The load / store unit circuit 405 executes load and store instructions to load data from memory into a register or store data from a register into memory. The load / store unit circuit 405 may also generate addresses. The branch / jump unit circuit 407, depending on the instruction, causes a branch or jump to a memory location. The floating-point unit (FPU) circuit 409 performs floating-point arithmetic. The width of the execution unit circuit 362 varies depending on the embodiment and can range from 16 bits to 1024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit). Example register architecture.

[0060] Figure 5 is a block diagram of a register architecture 500 according to some embodiments. As shown, there is a vector / SIMD register 510, which varies in width from 128 bits to 1024 bits. In some embodiments, the vector / SIMD register 510 is a solid 512-bit register, and depending on the mapping, only some lower bits are used. For example, in some embodiments, the vector / SIMD register 510 is a ZMM register, which is 512 bits; the lower 256 bits are used for the YMM register and the lower 128 bits are used for the XMM register. Thus, there are overlapping registers. In some embodiments, the vector length field is selected between a maximum length and one or more other shorter lengths, wherein each of these shorter lengths is half the length of the former. Scalar operations are performed on the lowest-order data element location in the ZMM / YMM / XMM register; higher-order data element locations are either left as they were before the instruction was executed or are zeroed out, depending on the embodiment.

[0061] In some embodiments, the register architecture 500 includes a write mask / predicate register 515. For example, in some embodiments, there are eight write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16-bit, 32-bit, 64-bit, or 128-bit in size. The write mask / predicate register 515 may allow merging (e.g., allowing any set of elements at the destination to be protected from being updated during any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements at the destination to be zeroed during any operation). In some embodiments, the location of each data element in a given write mask / predicate register 515 corresponds to the location of a data element at the destination. In other embodiments, the write mask / predicate register 515 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0062] The register architecture 500 includes a plurality of general-purpose registers 525. These registers can be 16-bit, 32-bit, 64-bit, etc., and can be used for scalar operations. In some embodiments, these registers can be represented by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0063] In some embodiments, the register architecture 500 includes a scalar floating-point register 545, which is used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using the x87 instruction set extension or as an MMX register to perform operations on 64-bit compressed integer data, and holds operands for some operations performed between the MMX and XMM registers.

[0064] One or more flag registers 540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operation. For example, one or more flag registers 540 may store status code information, such as carry, same, auxiliary carry, zero, sign, and overflow. In some embodiments, one or more flag registers 540 are also referred to as program status and control registers.

[0065] Segment registers 520 include segment points for accessing memory. In some embodiments, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0066] The Specific Machine Register (MSR) 535 controls and reports processor performance. Most MSRs 535 handle system-related functions and are not accessible to applications. The Machine Check Register 560 consists of control, status, and error reporting MSRs, which are used to detect and report errors in the hardware.

[0067] One or more instruction index registers 530 store an instruction index value. Control registers 555 (e.g., CR0-CR4) determine the operating mode and characteristics of the currently performing task of the processor (e.g., processors 170, 180, 138, 115, and / or 200). Debugging registers 550 control and allow monitoring of debugging operations of the processor or core.

[0068] Memory management registers 565 specify the location of data structures used in protected mode memory management. These registers may include GDTR, IDRT, working registers, and LDTR registers.

[0069] Alternative embodiments of the present invention may use wider or narrower registers. Furthermore, alternative embodiments of the present invention may use more, fewer, or different register files and registers. Instruction set

[0070] An instruction set architecture (ISA) may contain one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) to indicate the operation to be performed (e.g., operand code) and the operands and / or other data fields (e.g., masking), etc. Some instruction formats are further subdivided (or subformatted) through the definition of instruction templates. For example, an instruction template for a given instruction format may be defined with instruction format fields that have different subsets (these fields are typically in the same order, but at least some have different bit positions because they contain fewer fields) and / or be defined with given fields that are interpreted differently. Therefore, each instruction in an ISA is represented using a given instruction format (and, if defined, a given instruction template of that instruction format) and includes fields to indicate the operation and operands. For example, the sample ADD instruction has a specific operand and an instruction format that includes an operand field to specify the operand, and an operand field to select operands (source 1 / destination and source 2); and the occurrence of this ADD instruction in the instruction stream will have specific content in the operand field that selects the specific operand. Sample instruction format

[0071] Embodiments of the instructions described herein may be implemented in different formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instructions may be executed in such systems, architectures, and pipelines, but are not limited thereto.

[0072] Figure 6 illustrates an embodiment of the instruction format. As shown, an instruction may contain multiple components, including, but not limited to, one or more fields for: one or more preambles 601, operands 603, addressing information 605 (e.g., register identifier, memory addressing information, etc.), shift values ​​607, and / or immediate values ​​609. Note that some instructions utilize some or all of the fields of this format, while others use only the fields used for operands 603. In some embodiments, the order shown is merely the order in which these fields will be encoded; however, it should be understood that in other embodiments, these fields may be encoded, combined, etc., in different orders.

[0073] Prefix field 601 modifies an instruction when used. In some embodiments, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.) to provide segment substitution (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.) to perform bus locking operations and / or change operands (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Parts of these prefixes can be considered "legacy" prefixes. One or more other examples of prefixes detailed herein indicate and / or provide further capabilities, such as specifying a particular register, etc. Other prefixes typically follow "legacy" prefixes.

[0074] The operand field 603 is used to at least partially define the operation performed to decode the instruction. In some embodiments, the main operand encoded in the operand field 603 is 1, 2, or 3 bits long. In other embodiments, the main operand can be of different lengths. Sometimes, an additional 3-bit operand field is encoded in another field.

[0075] Address field 605 is used to address one or more operands of the instruction, for example, at a location in memory or one or more temporary registers. Figure 7 illustrates an embodiment of address field 605. In this illustration, the selected ModR / M byte 702 and the selected Scale, Index, Base (SIB) byte 704 are shown. The ModR / M byte 702 and the SIB byte 704 are used to encode two operands of up to one instruction, each operand being a direct register or valid memory address. Note that each of these fields is optional, and not all instructions include one or more of these fields. The MOD R / M byte 702 includes a MOD field 742, a temporary register field 744, and an R / M field 746.

[0076] The content of MOD field 742 distinguishes between memory access and non-memory access modes. In some embodiments, when MOD field 742 has a value of b11, direct register addressing mode is used; otherwise, indirect register addressing mode is used.

[0077] The register field 744 may encode destination register operands or source register operands, or it may encode operand code extensions that are not used to encode any instruction operands. The contents of the register index field 744 are generated directly or through addresses to indicate the location of the source or destination operands (in the register or in memory). In some embodiments, the register field 744 is supplemented with extra bits from the preamble (e.g., preamble 601) to allow for larger addressing.

[0078] The R / M field 746 can be used to encode instruction operands, their reference memory addresses, or it can be used to encode destination register operands or source register operands. Note that the R / M field 746 can be combined with the MOD field 742 to specify an addressing mode in some embodiments.

[0079] SIB byte 704 includes a scale field 752, an index field 754, and a base field 756 used to generate addresses. The scale field 752 represents the scaling factor. The index field 754 indicates the index register to be used. In some embodiments, the index field 754 is supplemented with extra bits from the prefix (e.g., prefix 601) to allow for larger addresses. The base field 756 indicates the base register to be used. In some embodiments, the base field 756 is supplemented with extra bits from the prefix (e.g., prefix 601) to allow for larger addresses. In practice, the content of the scale field 752 allows for scaling of the content of the index field 754 for memory address generation (e.g., for address generation using 2 scale * index + base).

[0080] Some addressing schemes utilize displacement values ​​to generate memory addresses. For example, memory addresses can be generated based on 2 scale * index + base + displacement, index * scale + displacement, r / m + displacement, instruction index (RIP / EIP) + displacement, register + displacement, etc. The displacement can be a 1-byte, 2-byte, 4-byte, etc. value. In some embodiments, displacement field 607 provides this value. Additionally, in some embodiments, the displacement factor is used in the MOD field encoded in address field 605, which indicates a compressed displacement scheme, wherein the displacement value is calculated by multiplying disp8 by a scaling factor N determined based on the vector length, the value of the ab bits, and the instruction input unit size. The displacement value is stored in displacement field 607.

[0081] In some embodiments, the immediate value field 609 indicates the immediate value used for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0082] Figure 8 illustrates an embodiment of the first preamp 601(A). In some embodiments, the first preamp 601(A) is an embodiment of the REX preamp. Instructions for this preamp can specify general-purpose registers, 64-bit compressed data registers (e.g., single instruction, multiple data (SIMD) registers, or vector registers), and / or control registers and debugging registers (e.g., CR8-CR15 or DR8-DR15).

[0083] The instruction using the first preamplifier 601(A) can specify up to three registers using 3-bit fields, depending on the format: 1) using the reg field 744 and the R / M field 746 of the Mod R / M byte 702; 2) using the Mod R / M byte 702 and the SIB byte 704, including the use of the reg field 744, the base field 756, and the index field 754; or 3) using the register field of the operand.

[0084] In the first preamplifier 601(A), bit positions 7:4 are set to 0100. Bit position 3(W) can be used to determine the operand size, but may not be able to determine the operand width independently. Therefore, when W=0, the operand size is determined by the code segment specifier (CS.D), and when W=1, the operand size is 64 bits.

[0085] Note that the addition of another element allows 16 (24) registers to be addressed, while each MOD R / M reg field 744 and MOD R / MR / M field 746 can only address 8 registers individually.

[0086] In the first preamplifier 601(A), bit position 2(R) can be an extension of the MOD R / M reg field 744 and can be used to modify the ModR / M reg field 744 when the field encodes a general-purpose register, a 64-bit compressed data register (e.g., an SSE register), or a control or debugging register. When the Mod R / M byte 702 specifies other registers or defines extended operands, R is ignored.

[0087] Bit position 1(X)X bits can modify SIB byte index field 754.

[0088] Bit position B(B)B can be modified in Mod R / MR / M field 746 or SIB byte base field 756; or it can be modified in the operand register field used to access general registers (e.g., general register 525).

[0089] Figures 9(A)-9(D) illustrate embodiments of how the R, X, and B fields of the first preamplifier 601(A) are used. Figure 9(A) illustrates that R and B from the first preamplifier 601(A) are used to extend the reg field 744 and R / M field 746 of the MOD R / M byte 702 when the SIB byte 704 is not used for memory addressing. Figure 9(B) illustrates that R and B from the first preamplifier 601(A) are used to extend the reg field 744 and R / M field 746 of the MOD R / M byte 702 when the SIB byte 704 is not used (scratch register - scratch register addressing). Figure 9(C) illustrates how R, X, and B from the first preamplifier 601(A) are used to extend the reg field 744 of the MOD R / M byte 702, and the index field 754 and base field 756 when the SIB byte 704 is used for memory addressing. Figure 9(D) illustrates how B from the first preamplifier 601(A) is used to extend the reg field 744 of the MOD R / M byte 702 when the register is encoded in the operand code 603.

[0090] Figures 10(A)-10(B) illustrate embodiments of the second preamplifier 601(B). In some embodiments, the second preamplifier 601(B) is an embodiment of the VEX preamplifier. The second preamplifier 601(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD register 510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second preamplifier 601(B) provides a three-operand (or more) syntax. For example, the preceding two-operand instructions perform an operation such as A = A + B, which overwrites the source operand. The use of the second preamplifier 601(B) causes operands to perform non-destructive operations, such as A = B + C.

[0091] In some embodiments, the second preamplifier 601(B) enters two forms – a two-tuple form and a three-tuple form. The two-tuple second preamplifier 601(B) is mainly used for 128-bit scalars and some 256-bit instructions; while the three-tuple second preamplifier 601(B) provides a close replacement for the first preamplifier 601(A) and the three-tuple arithmetic code instructions.

[0092] Figure 10(A) illustrates an embodiment of the second preamble 601(B) in tuple form. In one example, format field 1001 (byte 0 1003) contains the value C5H. In another example, byte 1 1005 contains the “R” value in bit [7]. This value is the complement of the same value of the first preamble 601(A). Bit [2] is used to specify the length (L) of the vector (where 0 is a scalar or 128-bit vector and 1 is a 256-bit vector). Bits [1:0] provide operand extensions that are equal to some old preambles (e.g., 00 = no preamble, 01 = 66H, 10 = F3H, and 11 = F2H). The bits [6:3] displayed as vvvv can be used to: 1) encode the first source register operand specified in inverted (one's complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand specified in one's complement form for some vector shift; or 3) not encode any operand, the field is reserved and should contain a value such as 1111b.

[0093] The instruction above can be used with Mod R / MR / M field 746 to encode the instruction operand of the reference memory address or to encode the destination register operand or the source register operand.

[0094] Using the previously placed instruction, the Mod R / M reg field 744 can be used to encode destination register operands or source register operands, which are considered as operand code extensions and are not used to encode any instruction operands.

[0095] For instruction syntax that supports four operands, vvvv, Mod R / MR / M field 746, and Mod R / M reg field 744 encode three of the four operands. The bits [7:4] of the immediate value 609 are then used to encode the third source register operand.

[0096] Figure 10(B) illustrates an embodiment of the second preamble 601(B) in tuple form. In one example, format field 1011 (byte 0 1013) contains the value C4H. Byte 1 1015 contains “R”, “X”, and “B” in bits [7:5], which are complements of the same value of the first preamble 601(A). The bits [4:0] (displayed as mmmmm) of byte 1 1015 contain content to encode one or more implicit preamble operand byte groups as needed. For example, 00001 implies 0FH preamble operand, 00010 implies 0F38H preamble operand, 00011 implies 0F3AH preamble operand, and so on.

[0097] Bits [7] of byte 2 1017 are used similarly to W of the first preamp 601(A), which contains elements that help determine operand size. Bit [2] is used to specify the length (L) of the vector (where 0 is a scalar or 128-bit vector and 1 is a 256-bit vector). Bits [1:0] provide operand extensions equal to some legacy preamps (e.g., 00 = no preamp, 01 = 66H, 10 = F3H, and 11 = F2H). Bits [6:3], which are displayed as vvvv, can be used to: 1) encode a first source register operand specified in inverted (one's complement) form and valid for instructions with 2 or more source operands; 2) encode a destination register operand specified in one's complement form for some vector shift; or 3) not encode any operand, in which case the field is reserved and should contain a value, such as 1111b.

[0098] The instruction set above can be used to encode the instruction operand of the reference memory address, or to encode the destination register operand or the source register operand using Mod R / MR / M field 746.

[0099] The instruction above can use Mod R / M reg field 744 to encode destination register operands or source register operands, which are considered as operand code extensions and are not used to encode any instruction operands.

[0100] For instruction syntax vvvv that supports four operands, Mod R / MR / M field 746 and Mod R / M reg field 744 encode three of the four operands. The bits [7:4] of the immediate value 609 are then used to encode the third source register operand.

[0101] Figure 11 illustrates an embodiment of the third preamplifier 601(C). In some embodiments, the first preamplifier 601(A) is an embodiment of the EVEX preamplifier. The third preamplifier 601(C) is a quaternion preamplifier.

[0102] The third preamplifier 601(C) can encode a 32-vector register (e.g., a 128-bit, 256-bit, and 512-bit register) in 64-bit mode. In some embodiments, the preamplifier is utilized by writing a mask / operation mask instruction (see the discussion of registers in the previous diagram of FIG5) or prediction. The operation mask register allows conditional processing or selection control. The operation mask instruction is encoded using the second preamplifier 601(B), the source / destination operand of which is the operation mask register and the contents of the operation mask register are treated as a single value.

[0103] The third preamplifier 601(C) can encode instruction class-specific functionality (e.g., compact instructions with "load + operation" semantics can support embedded broadcast functionality, floating-point instructions with rounding semantics can support static rounding functionality, floating-point instructions with non-rounding operation semantics can support "suppress all exceptions" functionality, etc.).

[0104] The first tuple of the third preposition 601(C) is format field 1111, which in one example has a value of 62H. The subsequent tuples are referred to as payload tuples 1115-1119, and together they form the 24-bit value of P[23:0], providing a specific capability to be represented in one or more fields (detailed herein).

[0105] In some embodiments, P[1:0] of payload byte 1119 is the same as the next two mmmmmm bits. In some embodiments, P[3:2] is reserved. When P[7] is combined with Mod R / M reg field 744, bit P[4](R') allows access to the upper 16 vector register group. P[6] can also provide access to the upper 16 vector registers when SIB-type addressing is not required. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when Mod R / M register field 744 is combined with Mod R / MR / M field 746, access to the next group of 8 registers beyond the next 8 registers is allowed. P[9:8] provides operand extensions equal to some legacy prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H). In some embodiments, P

[10] is a fixed value of 1. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand specified in inverted (one's complement) form and valid for instructions with 2 or more source operands; 2) encode a destination register operand specified in one's complement form for some vector shift; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0106] P

[15] is similar to the first preamplifier 601(A) and the second preamplifier 601(B) and can be used as an operation code extension bit or operation element size promotion.

[0107] P[18:16] indicates the index of the register in the operation mask (write mask) register (e.g., write mask / predicate register 515). In one embodiment of the invention, the specific value aaa=000 has a special behavior indicating that no operation mask is used for that specific instruction (this can be implemented in various ways, including using operation mask hardwired to all hardware as all 1 or using hardware that bypasses the mask hardware). When merged, the vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (as specified by the base operation and the extended operation); in other embodiments, the old values ​​of the individual elements of the destination are preserved, where the corresponding mask bit has 0. Conversely, when the zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (as specified by the base operation and the extended operation); in one embodiment, when the corresponding mask bit has a value of 0, the elements of the destination are set to 0. This functional subgroup provides the ability to control the vector length of the operations performed (i.e., the span of elements from the first to the last element is modified); however, these elements do not necessarily need to be modified to be continuous. Therefore, the operation mask field allows for partial vector operations, including loading, storing, arithmetic, logic, etc. While embodiments of the invention are described where the content of the operation mask field selects one operation mask register among several operation mask registers for the operation mask to be used (and thus the content of the operation mask field indirectly indicates the mask to be performed), alternative or additional embodiments allow the content of the mask written into the field to directly indicate the mask to be performed.

[0108] P

[19] can be combined with P[14:11] to encode a second source vector register in non-destructive source syntax, which can access the 16 vector registers using P

[19] . P

[20] encodes multi-functionality, which varies across different instruction categories and can affect the meaning of the vector length / rounding control specifier fields (P[22:21]). P

[23] indicates support for merge-write mask (e.g., when set to 0) or support for zero-and-merge mask (e.g., when set to 1).

[0109] An exemplary embodiment of encoding a register in an instruction using a third preamplifier 601(C) is described in detail in the following table. 4 3 [2:0] temporary register type Common usage REG R' R ModR / M reg General, Vector Purpose or source vvvv V' vvvv General, Vector Second source or destination RM X B ModR / MR / M General, Vector Source or destination Base 0 B ModR / MR / M General Memory addressing index 0 X SIB. Index General Memory addressing VIDX V' X SIB. Index vector VSIB memory addressing Table 1: 32-bit registers supported in 64-bit mode [2:0] temporary register type Common usage REG ModR / M reg General, Vector Purpose or source vvvv vvvv General, Vector Second source or destination RM ModR / MR / M General, Vector Source or destination Base ModR / MR / M General Memory addressing index SIB. Index General Memory addressing VIDX SIB. Index vector VSIB memory addressing Table 2: Register specifiers encoded in 32-bit mode [2:0] temporary register type Common usage REG ModR / M Reg k0-k7 source vvvv vvvv k0-k7 Second Source RM ModR / MR / M k0-7 Source 1 {k1} aaa k0 1 -k7 Operational masking Table 3: Encoding of Operation Mask Register Specifiers

[0110] The code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0111] The code can be implemented in a high-level program or object-oriented programming language to communicate with the processing system. If desired, the code can also be implemented in assembly or machine language. In fact, the mechanisms described herein do not limit the scope to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0112] Embodiments of the mechanism described herein may be implemented as hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as a computer program or program code executable on a programmable system, the system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0113] One or more of the embodiments may be executable by representative instructions stored on a machine-readable medium, which presents various logics within the processor, causing the machine to manufacture the logic to perform the techniques described herein when read by a machine. This representation, referred to as an "IP core," may be stored on a tangible machine-readable medium and supplied to various clients or manufacturing facilities for loading into the manufacturing machine that actually performs the logic or processor.

[0114] This machine-readable storage medium may include, but is not limited to, a non-transitory tangible configuration of articles made or formed by a machine or apparatus, including storage media such as hard disks, any other type of disk, including floppy disks, optical disks, CD-ROMs, rewritable CD-RWs, and magneto-optical disks, semiconductor devices such as read-only memory (ROM), random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0115] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or design data, such as a hardware description language (HDL), defining the architecture, circuitry, device, processor, and / or system characteristics described herein. These embodiments may also be referred to as program products. Emulation (including binary translation, code transformation, etc.)

[0116] In some cases, an instruction translator can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can translate (e.g., using binary translation, dynamic binary translation including dynamic compilation), transform, emulate, or translate an instruction into one or more other instructions to be processed by the core. An instruction translator can be implemented as software, hardware, firmware, or a combination thereof. An instruction translator can be on the processor, off the processor, or partially on the processor and partially off the processor.

[0117] Figure 12 illustrates a block diagram for the use of a software instruction converter according to certain embodiments to convert binary instructions in a source instruction set into binary instructions in a target instruction set. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter may also be implemented as software, firmware, hardware, or various combinations thereof. Figure 12 shows a program in a high-level language 1202, which can be compiled using a first ISA compiler 1204 to produce first ISA binary code 1206, which can be natively executed by a processor 1216 having at least one first instruction set core. The processor 1216 having at least one first ISA instruction set core represents any processor that can perform substantially the same functions as an Intel® processor having at least one first ISA instruction set core by compatiblely executing or processing (1) a large portion of the instruction set of the first ISA instruction set core or (2) an object code version of the application or other software target to run on an Intel processor having at least one ISA instruction set core to achieve substantially the same results as a processor having at least one ISA instruction set core. The first ISA compiler 1204 represents a compiler operable to produce first ISA binary code 1206 (e.g., object code), which can be executed on a processor 1216 having a first ISA instruction set core, with or without additional linking processing.

[0118] Similarly, Figure 12 shows a program represented in a high-level language 1202, which can be compiled using an alternative instruction set compiler 1208 to produce alternative instruction set binary code 1210, which can be natively executed by a processor 1214 that does not have a first ISA instruction set core. An instruction converter 1212 is used to convert the first ISA binary code 1206 into code that can be natively executed by a processor 1214 that does not have a first ISA instruction set core. This converted code will not appear to be the same as the alternative instruction set binary code 1210, as it would be difficult to make such an instruction converter; however, the converted code will perform general operations and will be instructed by the alternative instruction set. Therefore, the instruction converter 1212 represents software, firmware, hardware, or a combination thereof, through emulation, simulation, or any other processing, allowing a processor or other electronic device that does not have a first ISA instruction set processor or core to execute the first ISA binary code 1206.

[0119] In various embodiments, the device may serve or support multiple clients. However, the scalability of the device may be limited by its ability to maintain information about the various different clients it is serving, which may subsequently be limited by silicon die area or other space available to store this information. For example, a single-root input / output virtualization (SR-IOV) device as defined by the Fast Peripheral Component Interconnect (PCIe) specification may be implemented to support a larger number of virtual functions (VFs) for a larger number of clients. A device may also implement a larger number of queues and associated client-specific states to support a large number of clients.

[0120] FIG13 illustrates one embodiment of the scalable device 100, which can be implemented as a logic gate, storage element, and / or any other type of circuit, all or part of which can be included in discrete components and / or integrated into circuitry of a processing device or any other device in a computer or other information processing system. For example, the device 1300 of FIG13 may correspond to the coprocessor 138 of FIG1 or the special purpose logic 208 of FIG2.

[0121] According to one embodiment, the scalable device can use any number of work queues 1350, wherein a work queue is a data structure that will be used to accept work from a client. A work queue can be a dedicated work queue (DWQ) that can accept work from a single client, or it can be a shared work queue (SWQ) that can accept work from multiple clients. For example, device 1300 is shown to include DWQs 1310 and 1314 and SWQ 1312, which can accept work from clients 1320, 1322, 1324, 1326, and 1328.

[0122] The job queue can be implemented using memory within the device (e.g., device 1300) and / or memory not within the device (e.g., host memory, system memory, temporary registers, or other storage locations not within the device). Using host memory, for example, job queue 1350 can be implemented as a software-writable base register, header register, or tail register to notify the device of job submission. Using device memory, for example, job queue 1350 can be implemented as a software-writable address to submit a job.

[0123] Job column 1350 can be used to store job descriptors, which contain client identifiers (IDs) and permissions. The client ID is used to identify the client (e.g., by a Program Address Space Identifier (PASID)) and the permissions represent the permissions that the device can use to identify the client's address domains and permissions. The job descriptors can be populated with trusted hardware (e.g., a CPU in a secure environment) and / or trusted software (e.g., an operating system (OS) running on a CPU in a secure environment) to ensure that they are not spoofed by unauthorized clients.

[0124] In various embodiments, the job descriptor is fully self-describing, so that the device does not need to retain any client-specific state, and therefore does not require additional memory to support additional clients. The fully self-describing job descriptor contains all the information required to perform the requested job.

[0125] For example, in one embodiment, a work descriptor may include an index indicating a completion record that will be written to host memory for a completion status (including any error status). The completion record may also include any partial results that subsequent work descriptors may use, allowing data to be carried forward through operations (e.g., cyclic redundancy check calculations may use results from each step as input to the next step). The completion record may also include flag bits and / or any other information that may be used in the execution of operations. Therefore, no memory will be used in the device to store per-client states regarding completion status, partial results, flag bits, etc.

[0126] In various embodiments, working descriptors can also be used to avoid other limitations on the scalability of the device. For example, the limitation of one client per message transmission interruption in the device's PCI MSI-X table can be avoided by any of the following methods. By any of these methods, any client can establish multiple interrupts, allowing the client to choose to specify different interrupts for different descriptors, thus allowing the client to perform interrupt rebalancing without involving the OS or other system software.

[0127] In one embodiment, the working descriptor may be designed to contain interrupt information (e.g., MSI address and data) provided by the client. Because the interrupt information is provided by the client and is not trusted, interrupt remapping hardware (e.g., I / O memory management unit) can be responsible for ensuring that the client cannot request an interrupt that has not yet been assigned to it. For example, PASID and remapping interrupt information can be used to locate interrupt remapping table entries for interrupt information (PASID granular interrupt remapping). PASID granular interrupt remapping allows the same information to have different meanings when used with different PASIDs, and also allows system software to control which interrupt information (e.g., indicated by the client's PASID) each client can use. The device can then use the interrupt information from the working descriptor to generate an interrupt when the operation is completed, while avoiding storing the interrupt information in the device.

[0128] In one embodiment, the working descriptor may be designed to include an interrupt handler (instead of the full MSI address and data value). The interrupt handler in the descriptor specifies an entry in the interrupt information table. The device may implement the interrupt information table in host memory, with each interrupt table entry containing the MSI address and data. Because the interrupt information table is in host memory, not device memory, it can be made large enough to support any number of clients. The interrupt handler in the working descriptor can be used by the device to index into the interrupt table to identify the MSI address and data value used to generate the interrupt when device operation is complete. The device will first verify the interrupt handler using a PASID to ensure that the client is allowed to use that particular interrupt handler. The device may verify the interrupt handler by using a PASID-granular interrupt information table or by including the PASID in the interrupt table entry during interrupt setup and generation, matching the PASID of the entry with the client's PASID. To avoid each descriptor having its interrupt table entry read from host memory, an interrupt information cache within the device may cache frequently used interrupt entries.

[0129] In addition to reducing or eliminating per-customer status on the device, some embodiments provide efficient processing of work from a large number of customers. Embodiments may allow prioritization of work from time-sensitive customers while ensuring the positive progress of work from other customers. Embodiments may prevent negative impacts on other customers due to errors or performance issues of some customers.

[0130] A work submission entry is an mechanism by which a client can submit work requests to a device. In one embodiment, a SWQ may have more than one work submission entry for clients to submit work, rather than a single work submission entry mapped to all clients using the SWQ. Using a single work submission entry per SWQ may cause clients to constantly retry work submissions because they may experience the SWQ being full, making the device difficult to use and unpredictable for other clients. Conversely, using multiple work submission queues per SWQ according to some embodiments can provide priority for work requests and prevent some clients from being starved. In embodiments, a work submission entry may be implemented as a memory-mapped I / O (MMIO) address that a client can write to submit a work request, such that multiple work submission entries can be provided by assigning more than one MMIO address to the SWQ and providing different MMIO addresses to different clients, without requiring additional logic circuitry or storage in the device.

[0131] In various embodiments, different job submission entries for the SWQ can have different characteristics, such as different job acceptance priorities for different clients. For example, the SWQ can designate a first submission entry as a restricted entry and a second submission entry as an unrestricted entry. The SWQ can have configurable thresholds, which can be used to reserve some entries specifically for jobs submitted through the unrestricted entry. For example, the SWQ can be configured to use up to 80% (threshold) of the SWQ space for jobs submitted through the restricted entry, while jobs submitted through the unrestricted entry can use 100% of the SWQ space. The permissions software (e.g., a device driver) can then map the restricted entry to the user-space client and reserve the unrestricted entry for itself. If a user-space client experiences an SWQ full state (e.g., when the SWQ is 80% full, the SWQ replies "try again" to the user-space client), instead of continuously retrying the job submission itself, they can make a request to the device driver to submit a job descriptor on their behalf. The device driver can serialize the requests from the user-space client and submit job requests using the unrestricted entry. Because 20% of the SWQ space is reserved for unrestricted entry points, job submissions for device drivers are likely to succeed.

[0132] Embodiments may also provide for handling a SWQ that is 100% full (e.g., even an unrestricted entry responding with "retry"). In one embodiment, the device driver may respond to the client with "retry" as if "retry" had been received directly by the device. In one embodiment, the device driver may block the client until a job can be submitted, and, in the meantime, the device driver may schedule another client. In one embodiment, the device driver may place a job descriptor in a software-defined job queue until it can be submitted to the device, but reply to the client as if the job has been successfully submitted to the device. With the latter approach, the client can continue operating while waiting for the device to catch up. Embodiments may provide for use in this latter approach by determining that all descriptors to the device are independent of each other in terms of order, or by preventing the client from directly submitting any processable descriptors to the device before the descriptors are queued by the device driver in the software. This prevention measure can be implemented by removing the device submission entry from the client's memory graph, preventing clients from directly submitting work to the device, or by locking the SWQ so that no client can submit work to complete it. In this locking approach, all client work submissions will respond with a "retry" message, and the client will have to request the device driver to submit its work. This provides fairness but can also be burdensome due to the bottleneck of work submissions through the device driver (which may be acceptable since it will only occur when the shared work queue is fully loaded).

[0133] Embodiments may also provide configurability for the work queues themselves. For example, any one or more multiple work queues can be configured as dedicated or shared on demand upon customer request. Work queues can be specified and configured with different priorities by the software. The device can deliver commands from higher-priority work queues before commands from lower-priority work queues without starving the lower-priority work queues. Some customers may already have access to multiple work queues and therefore have the ability to prioritize their own work, while other customers may only have access to a single work queue, thus resolving the priority order of all the work they submit.

[0134] Embodiments may also provide for mitigating the problem of a device being blocked while performing an operation because it is waiting for a response from another part of the system (e.g., completing a memory read, address translation, or handling a page fault). This problem is called head-of-line blocking because an operation is being performed on the device, preventing other operations at the back of the queue from being performed.

[0135] In various embodiments, to mitigate head-of-line obstruction, the device may include multiple operating components (engines) capable of processing individual job descriptors in parallel, such as engines 1330, 1332, 1334, and 1336. In one embodiment, one or more job queues may be clustered with one or more engines. Queues may support several groups, such as groups 1340 and 1342. Each job queue and each engine may be configured by software as part of any group. Job descriptors from one or more job queues in a group may be dispatched to any engine in that group. Thus, if an engine in a group is processing a descriptor from a job queue while waiting for an external response, other engines in that group can continue processing other job descriptors from the same or other job queues.

[0136] In an alternative embodiment, the apparatus may implement an out-of-order processing engine that can pause work descriptors waiting for external responses and process other work descriptors from the same or other work queues at the same time.

[0137] Furthermore, in various embodiments, the apparatus can allow the internal resources used by the engine (e.g., internal device memory) to process work descriptors from various clients. If resources are limited, the apparatus can prioritize (or provide QoS to) these resources for use by different clients to ensure that work descriptors from one or a few clients (e.g., relatively large or time-consuming ones) do not consume most or all of the internal resources, thereby facilitating processing for other clients and the overall performance of the apparatus. Prioritization can be accomplished using a trust-based system, where trust represents internal resources. Trusts can be assigned to groups, individual job queues, or individual engines to control the amount of resources that each group, job queue, or engine is allowed to use to process its work descriptors. In embodiments, the apparatus can define two trust thresholds for each group, job queue, or engine: a first threshold indicating the minimum amount of trust reserved for a group, job queue, or engine (minimum guarantee or reserved trust); and a second threshold indicating the maximum amount of trust allowed for a group, job queue, or engine (maximum allowed trust).

[0138] Embodiments may also provide methods for effectively handling page seek errors. If the device supports virtual memory (e.g., Shared Virtual Memory (SVM) or I / O Virtual Address (IOVA)), the address assigned to the device in the working descriptor is not guaranteed to be mapped to physical memory. Before accessing main memory (e.g., via Direct Memory Access (DMA)), the device may, for example, use the address translation service described in the PCIe specification, request an address translation from the I / O Memory Management Unit (IOMMU). The IOMMU traverses the address translation table and, if a translation is found, returns the translated physical address to the device, allowing the device to access the data in memory. However, if the virtual address is not currently present in main memory, the result will be a translation error (I / O page seek error). Page seek errors can also occur when a page is present, but the processor or device does not have the right to perform that type of access request (e.g., the device wants to write to a read-only page).

[0139] When a device encounters a page lookup error, it cannot handle the page lookup error itself because the memory management system software is not running on the device. Therefore, according to the method shown in Figure 14 (1400), after the application submits a command to the device (1410), the device wants to access the page (1420), and the IOMMU responds with a page lookup error (1430). The device sends a page lookup error notification to the OS through the IOMMU (1440) and blocks the descriptor processing until the page lookup error is resolved. After the page lookup error is resolved (1450), the OS responds through the IOMMU that the page is available to the device (1460). Then, the device wants to access the page again, and this time the access is successful (1470).

[0140] The device typically implements a limited number of simultaneous significant I / O paging error notifications to the OS. Therefore, when supporting a large number of customers, the device may encounter many paging errors and can usually wait for at least one paging error to be resolved, which will significantly reduce the device's performance.

[0141] Therefore, unlike blocking I / O page lookup errors, some embodiments of method 1500 of FIG15 may include (after the application submits a command to the device (1510), the device wants to access the page (1520), and the IOMMU responds to the page lookup error (1530)), the device directly notifies the client about the page lookup error (1540) and terminates the processing of the working descriptor that caused the page lookup error. Then, while the application resolves or (as described below) responds to the page lookup error (1550), the device can continue to process other working descriptors without blocking. After the page lookup error is resolved, the application can submit a command to the device again (1560), and the device can want to access the page again (1570).

[0142] According to an embodiment of method 1500, page lookup error handling can be left to the client. For example, the client application can request the OS to resolve the page lookup error (e.g., by accessing the missed page) and resubmit the work descriptor to resume work after the page lookup error is resolved. Alternatively, the client can decide to use some other method instead of using the device to complete the remaining work, such as by using the CPU to perform the operation.

[0143] The mechanism used by the device to notify the application that it has encountered a page lookup error is referred to as partial completion. In embodiments that include partial completion, the device may report the completion of the operation to the client in a general manner (e.g., by setting a device register, modifying the tail index of a queue or ring buffer, writing to a shared memory location, generating an interrupt, or any combination thereof), but the completion log information may include the following additional elements: a status field indicating that a page lookup error occurred, an indication of how much operation was completed before the page lookup error, a virtual address that cannot be translated, an indication that the device wants to read or write to the untranslatable address, and any other information required by the software to recover the operation (see examples below).

[0144] As the name suggests, partial completion indicates that the device may have performed part of the requested operation before encountering a page lookup error. By reporting partial completion to the customer, the customer (e.g., application software) can begin using the completed result, even while the page lookup error is being resolved and the remaining operations are being performed by the device.

[0145] In an embodiment, partial completion can report that none of the operations have been completed, for example, if the device encounters a page lookup error on the first page where the operation needs to be started.

[0146] In an embodiment, depending on the type, length, and complexity of the operation, the device may restart the operation from the beginning rather than from the point where a page lookup error occurred. In this case, the device may report that no operation was completed, even if the page lookup error was not on the first page (assuming that the partially completed operation did not overwrite any of its inputs).

[0147] In an embodiment, the partial completion information includes all the information required to respond to the operation. The client can respond to the operation by submitting a new command that begins where the previous operation stopped. For operations carrying forward data through the operation (e.g., CRC calculation), if a page fault occurs midway through the operation, intermediate results can be retained for use when responding to the operation. Intermediate results can be stored in the completion record along with page fault information. When a page fault is satisfied, the application responds to the operation by transmitting the intermediate results along with the command. A method and apparatus for high-performance page fault handling for multi-tenant scalable accelerators.

[0148] Accelerators are often configured to use shared virtual memory (SVM), which provides an ubiquitous planning model between host / CPU and accelerator offloading. At the same time, there is rapid growth in highly multi-tenant (VM or container) environments, which makes it challenging to support SVM and I / O paging errors in these environments.

[0149] For example, SVM fault blocking and SVM fault and streaming accelerator modes have been used to address these limitations. With SVM fault blocking, the accelerator / engine blocks until the I / O paging fault is resolved by the OS / VMM software, and a response is sent back to continue the remaining work. With SVM fault and streaming, the accelerator / engine context switches to another offload context, and the I / O paging fault is resolved for the given context.

[0150] These existing models have various limitations. SVM errors hinder scaling and multi-tenancy challenges. If the accelerator only has 4 engines, I / O paging errors cannot scale to more than 4 simultaneous clients or present challenges related to noisy neighbors in multi-tenancy (e.g., a paging error from one tenant will delay the offloading execution of other tenants). SVM errors and streaming present challenges related to increased device complexity and the burden of storage / re-storage states. Furthermore, prior art only supports paging errors on the data buffer, not on the control structure.

[0151] Embodiments of the present invention include techniques for supporting efficient I / O paging error handling of accelerator devices in highly multi-tenant and scalable environments, while continuously suppressing accelerator complexity and cost. More specifically, the embodiments described herein provide paging error handling for accelerators with per-job queue capability, directly notifying application / unloading clients of accelerator paging errors, and providing an event logging mechanism to allow the accelerator driver to delegate paging error handling / notification to unloading clients (when direct notification is not feasible / recommended). Additionally, some embodiments can pre-execute the error context and immediately switch to the next context, allowing software to handle paging errors and complete the remaining work on the host processor (e.g., CPU) or re-unload to the accelerator. Furthermore, extensions are also described for handling batch descriptors.

[0152] These embodiments address scaling and complexity-related challenges, enabling non-stop VM migration and designated accelerators, and enhancing the performance of accelerator page seek error handling. Therefore, the embodiments described herein make SVM applications more feasible / practical in virtualization configurations.

[0153] Referring to FIG. 16, one embodiment of the accelerator 1600 includes a job receiving unit 1610 comprising a plurality of job queues (WQs) 1601A-D, which can be grouped according to the workload characteristics described above. A plurality of execution units, or "engines" 1621A-D, are assigned to process job descriptors from one or more of the job queues 1601A-D. One or more job schedulers 1630 dispatch jobs specified in the descriptors from the job queues 1601A-D to the execution engines 1621A-D.

[0154] Execution engines 1621A-D are typically shared among multiple clients, which can be drives, applications, virtual machines (VMs), containers, or any other functional software components. Resource sharing reduces the cost / burden of building independent engines for each client. Work columns 1601A-D assign work to these engines 1621A-D and assign it to individual clients (e.g., dedicated work columns 1310, 1314 in Figure 13) or share it among them (e.g., shared work column 1312 in Figure 13).

[0155] Referring to Figure 17, in the shared virtual memory planning model, as part of processing a working descriptor, the accelerator 1600 will want to obtain, for example, an address translation associated with the address specified in the working descriptor using a PCIe address translation service. The accelerator 1600 may include a translation lookahead buffer 1705 to cache virtual-to-physical address translations. If a specific translation is not found in the TLB 1705, a translation request 1750 is sent to the IOMMU 1725 within the root complex 1720 of the host processor 1710. The IOMMU will retrieve the translation from its TLB or from memory 1715 and will then transmit the translation response 1751 to the accelerator 1600 that has the translation.

[0156] The IOMMU 1725 and the accelerator 1600 must communicate to ensure that the TLB 1705 of the accelerator 1600 remains consistent with the TLB of the host processor 1710. Therefore, in response to certain events such as the modification of a translated entry or a context switch, the IOMMU 1725 will send an invalidation request 1753 to the accelerator 1600, which will invalidate the relevant TLB entry and, upon completion, send back an invalidation awareness response 1754.

[0157] In the event that the page does not appear in memory 1715 or, if permitted, is insufficient to access the page, translation request 1750 will generate page request 1755, for example, by using the PCIe page request service. This page request is received by IOMMU 1725 and transmitted to system software (e.g., OS / VMM) to handle I / O paging errors. The system software will correct the paging error and return a success page response 1756 to the accelerator device via IOMMU 1725. In the event that access to the page is denied, a page response with a corresponding error is returned to accelerator 1600.

[0158] During this sequential operation, the accelerator 1600 (or the accelerator's engine) can halt the engine / execution unit until an I / O paging error is handled (similar to how an application running on the kernel halts until a CPU paging error is handled), known as "SVM error blocking mode". Alternatively, the accelerator / engine can generate a page request, store the current working context, and move to the next working descriptor, resuming work once the paging error is handled, known as "SVM error and streaming mode".

[0159] As described, the page lookup blocking mode presents scaling and noisy neighbor-related challenges. For example, in a scenario where four job queues related to four different clients are mapped to one engine, a page lookup error from one client will cause the engine to stop, resulting in delayed execution for other clients. This is even more problematic for virtualized configurations, where page lookup error handling latency is high and the behavior of one VM / tenant will impact the service quality of other VMs / tenants sharing the same engine.

[0160] Missed and streaming modes aim to address this stalling issue; however, it requires complex hardware that can support storing and recovering workload contexts, and presents challenges in terms of cost and time-consuming aspects related to context switching and storage / recovery operations.

[0161] Furthermore, additional latency and burden are introduced by these traditional virtualization configuration methods, where a page lookup error will cause a virtual machine (VM) to leave, and at the same time, another VM will need to leave to queue page responses. This also creates additional challenges when supporting VM migrations with specified accelerator resources for non-downtime operation. For example, some VMMs first suspend virtual processors, and then suspend virtual devices used by the VMs, which can cause a deadlock due to circular dependencies.

[0162] Figure 18 illustrates an example of an accelerator 1800 on which embodiments of the present invention may be implemented. A majority of engines 1821A-C process descriptors from a majority of working queues 1801A-C. Each accelerator engine 1821A-C includes error handling logic 1805A-C in response to a page lookup error state as described herein (although for simplicity, only engine 1821A is illustrated). Engines 1821A-C can be any type of processing engine for the accelerator, including, but not limited to, data copy engines, data compression engines, security engines, communication engines, and graphics engines.

[0163] In one embodiment, unlike locking onto an I / O paging error until it is resolved, the error handling logic 1805A directly notifies the client 1801 and terminates working descriptor processing. This allows the engine 1801A to continue processing other working descriptors without obstruction; the client 1801 can then perform paging error handling via the driver, OS, or other privileged software. For example, the client application can then request the OS to resolve the paging error (e.g., by accessing the failed page) and resubmit the working descriptor to the working queue 1801A to resume work after the paging error is resolved. Alternatively, the client application 1801 can decide to use some other method instead of using the accelerator 1800 to complete the remaining work, such as by using the host CPU 1710 to perform the operation.

[0164] In various embodiments, I / O paging errors are reported and delegated to client application 1801 via a designated mechanism, such as event log 1812. System software (e.g., device driver or OS) can then correct the paging error based on information received in the event log entry and transmit a completion record to client 1801 (acting as an agent). In some embodiments, completion record buffer 1811 is used to directly notify client 1801 of paging errors and corresponding information.

[0165] A single accelerator device 1800 can use any of the above technologies at different times or for different targets.

[0166] The following are typical sources of page seek errors in an accelerator SVM environment: 1. Source / Destination Buffers: Most accelerator devices have source / input buffers on which data is read, processed / operated, and then written to the destination / output buffer. 2. Completion-Log / Response Queue Buffers: Many high-performance and scalable devices rely on completion logs or response queues, where memory writes are generated to notify the software of job completion. 3. Descriptor List Buffers / Rings: Many high-performance devices rely on descriptor lists or rings to communicate with single job submissions / doorbell hits / execute multiple descriptors. 4. Spread-Collection List Buffers: Some accelerator devices transmit the address of the spread collection list instead of directly transmitting the source / destination address. 5. Operation-Specific Buffers: Some accelerator devices allow the software to specify additional buffer addresses depending on the operation (e.g., CRC seed address, exhaust readback address, differential record address, etc.). 6. Configuration and Control Structure: Some accelerator devices may also have a configuration and control structure that can handle page seek errors encountered during workload (e.g., unload / working context, allow table, ...) execution.

[0167] Figure 19A illustrates an example of a job descriptor 1900, which can be submitted to job queue 1801A and interpreted by accelerator engine 1821A to perform a job. The job descriptor 1900 includes: an operation field 1901 to indicate the operation to be performed, multiple flags 1902 (e.g., completion record address valid, request completion record, request completion interruption), a processing address space identifier (PASID) field 1903 to associate the job descriptor with the program / application that generated the job, a completion record address field 1904 to indicate the memory location used for the completion record (e.g., for storing metadata related to the job being performed); a source address field 1905 to indicate the memory location used for the source data; a destination address field 1906 to indicate the memory location used for the result data; a completion interruption handling 1907; a transfer size field 1908; and (possibly) one or more operation-specific fields 1909 to indicate additional details of the operation to be performed.

[0168] An example of batch descriptor 1950 shown in Figure 19B contains many of the same fields as working descriptor 1900, except for a descriptor name unit address 1951, which indicates the memory location of the list (or batch) of descriptors, and a descriptor count field 1952, which indicates the number of descriptors in the list.

[0169] Figure 20 illustrates an example of a completion record 2000. In one embodiment, the accelerator engine 1821A specified by the descriptor generates a completion record, which is stored in a completion record buffer 1811. The client 1801 that submits the work can then retrieve the completion record from the buffer.

[0170] As shown in FIG20, in some embodiments, when a request for work is completed or an error is encountered, the completion record 2000 is a 32-byte structure and is written to the buffer 1811. In some embodiments, the engine 1821A writes sufficient information to the completion record 2000 to allow the engine 1821A to continue operation if the operation is partially completed due to a page lookup error.

[0171] The completion status bar 2004 indicates whether the operation has been completed. If the operation is completed successfully, the completion record 2000 may contain the operation result, if any, depending on the operation type (e.g., in the operation-specific bar 2006 or the result bar 2003). The result may also be stored in a different location in memory and specified by the address in the completion record 2000. If the operation is not completed successfully, the completion record contains error or mistake information in the error information bar 2003.

[0172] In one embodiment, if this completion record 2000 is used as a descriptor for submission as part of a batch, then an index field (not shown) contains the index in the descriptor batch in which this completion record was generated. For batch descriptors, this field can be 0xff. For any other descriptor that is not part of a batch, this field can be reserved.

[0173] In one embodiment, if an operation is partially completed due to a page seek error, the byte completion field 2001 indicates the number of source bytes processed before the error occurred. All source bytes represented by this count have been fully processed and the results have been written to the destination address as required, depending on the operation type. For some operation types, this field may also be used when the operation stops before completion for reasons other than an error. If the operation is fully completed, this field can be set to 0. For operation types where the output size cannot be quickly determined by this value, the completion record 2000 also includes the number of bytes written to the destination address. If the operation is partially completed due to a page seek error, the error address field 2005 includes the address that caused the error.

[0174] As described, this embodiment of the invention uses a completion record buffer 1811 to directly notify the client 1801 of a page lookup error and provide corresponding information. For example, the error address field 2005 indicates the address associated with the page lookup error; the error information field 2002 captures information related to the page lookup error, such as the buffer type and whether the error address field 2005 is valid, and the status field 2004 communicates relevant status information.

[0175] When a page lookup error is observed at the completion record address itself, the completion record buffer 1811 cannot be used to convey this information to the client 1801. In this situation, a memory-based event log 1812 can be used to record such events. This type of event log 1812 can be implemented per accelerator unit 1800, per engine 1821A-C, and / or per work queue 1801A-C.

[0176] Figure 21 illustrates an example of an event log entry 2100 with multiple fields to provide information about the relevant descriptor and / or error status. Errors that do not have a valid completion record address on the descriptor's completion record 2000 or during descriptor processing are typically reported in a register (software error register). Multiple occurrences of such errors before the software has processed the register result in an overflow condition.

[0177] In contrast, embodiments of the present invention support logging such events in the event log 1812 in memory. As shown in FIG22, the event log configuration register (EVLCFG) 2201 is configured to store the address and size of the event log memory area. When the event log enable bit is set to 1 in the accelerometer control register, the event log 1812 is enabled, as shown in the general configuration register (GENCFG) 2202 in FIG22.

[0178] Relative to write to completion record buffer 1811, write to event log 1812 may issue a translated or untranslated memory access. In some implementations, software pins correspond to memory pages of the event log and event log writes are performed with a traffic category (TC) value of 0.

[0179] In at least some embodiments, if the PASID enable field 2201C in EFLCFG 2201 is 1, a write to event log 1812 is issued using the PASID and corresponding permission level as a write (in some embodiments, also stored in EFLCFG 2201). If event log 1812 is enabled, accelerator device 1800 initializes the header field 2203A and tail field 2203B in event log state register (EVLSTATUS) 2203 (when device 1800 is enabled). Once enabled, the hardware writes each event to the offset specified in the event log tail field 2203B and increments the tail value 2203B. When the tail reaches the end of the log, it wraps back to a value of 0. The next event to be processed by the software is specified by event log header field 2203A. After processing one or more events in the event log header, the software updates header field 2203A. The log is filled when the tail value + 1 mod log size = header value.

[0180] When writing an event to the event log 1812, if the event log interrupt enable field 2204A in the accelerator control register (GENCTRL) 2204 is 1 and the interrupt pause bit 2203C in EVLSTATUS is 0, the hardware sets the interrupt pause bit 2203C to 1, sets the event log field 2205A in the interrupt cause register (INTCAUSE) 2205 to 1, and generates an interrupt (e.g., if the accelerator 1800 includes MSI-X support, then MSI-X entry 0 is used). No further interrupts are generated for additional log entries until the software clears the interrupt pause bit 2203C. If the event log 1812 is full when the hardware attempts to attach an event, the hardware blocks until the software updates the event log header field 2203A after processing one or more events from the log header. Therefore, the software must ensure that the event log area in memory is of an appropriate size and that event log entries are processed in a timely manner.

[0181] In various embodiments, if the hardware encounters a page lookup error at a completion record address while the Page Request Service (PRS) is disabled, it reports it as an error. If the event log 1812 is enabled, the hardware writes an appropriate error code indicating the cause of the page lookup error to the event log entry; otherwise, it is reported via column 2206A in the software error register (SWERROR) 2206. In the former case, the hardware also writes the completion record 2000 used for the descriptor to the event log entry. The completion record 2000 written to the event log 1812 has the same format as described above. The software responsible for processing the event log 1812 is expected to perform the necessary actions to pass the completion record 2000 to the software entity (e.g., client 1801) that submitted the error descriptor when appropriate. The software may also generate a completion interruption if requested.

[0182] Referring to FIG23, if a completion record for any descriptor in a batch is written to event log 1812 due to a paging error at the completion address, then if the completion record or completion interruption is required for the batch descriptor, a batch completion record 2300 for the corresponding batch descriptor 1950 is also written to event log 1812. In this case, the error code in the event log entry for batch descriptor 1950 indicates that one or more descriptors in the batch have associated the event log entry with a completion record 2000 that must be processed by the software. In various embodiments, accelerator 1800 generates a batch identifier value to allow the software to associate event log entry 1812 with descriptors within the batch and the corresponding batch descriptor 1950 and report it in the batch identifier column of the event log entry 1812. Once the event log entry for the batch descriptor has been written, the batch identifier can be reused by the hardware. An event log entry with a first error in the batch flag is 1, indicating the first entry for that batch. This allows the software to identify any expired event log entries with the same batch identifier. If the software encounters an entry with this flag set to 1, any previously recorded pending page misses using the same batch identifier can be discarded.

[0183] An example emission descriptor 2400 and emission completion record 2401 are illustrated in Figure 24. The emission descriptor awaits completion of certain previous descriptors submitted by the emission descriptor in work queue 1801A. If emission descriptor 2400 is submitted to a dedicated work queue, it awaits completion of all descriptors in that work queue. If emission descriptor is submitted to a shared work queue 1801A, it awaits descriptors in the work queue that have the same PASID as the emission descriptor. To await all descriptors with a specific PASID, the software submits separate emission descriptors to each work queue that uses that PASID.

[0184] In some embodiments, the completion of emission descriptor 2400 is permanently written to event log 1812 if it is enabled. If event log 1812 is not enabled, emission descriptor completion record 2401 is written to the completion record address.

[0185] As illustrated in FIG25, at least some embodiments of the present invention implement per-WQ Page Request Service (PRS) 2501-2502, which can be dynamically enabled and disabled on a per-WQ basis. In FIG25, for example, PRS 2501 and PRS 2502 have been dynamically enabled for job queues 1801B and 1801C, respectively, and disabled for job queue 1801C, which uses the efficient techniques described herein instead of PRS (e.g., terminating the job and submitting login items to event log 1812 and / or completion record buffer 1811).

[0186] In one embodiment, capability bits are provided in a control register to indicate whether each WQ PRS can be disabled in a given scalable accelerator 1800. Capability bits can be provided in any of the aforementioned registers. When supported, each WQ control bit indicates whether a particular WQ PRS is enabled or disabled—even when enabled at the level of accelerator device 1800, fine-grained control is provided for page fault handling. In some implementations, for example, when each WQ control bit is set (i.e., set to 1) in a particular working queue, one or more scalable page fault handling techniques described herein are used. When cleared (i.e., binary 0), legacy page fault handling techniques are used.

[0187] Figure 26 illustrates a method according to an embodiment of the present invention. At 2601, a working descriptor is received in the working queue of the accelerator, and at 2602, a page lookup error is detected for the working of the descriptor in a particular working queue.

[0188] Pager errors are handled differently depending on the pager error mode for a specific work column as determined in 2603. For example, when a pager error occurs and PRS 2501-2502 is enabled for the relevant work columns 1801A-B (mode 2 in Figure 26), the work related to that descriptor is suspended and the pager error is reported as a PRS request to IOMMU 1725 for service by the OS pager error handler in 2611. IOMMU 1725 notifies the OS via an interrupt. The OS verifies the address and, upon successful verification, establishes a mapping in the page table and returns a PRS response via IOMMU 1725 in 2612. The descriptor that encountered the error is blocked until a PRS response is received. Other operations following the descriptor with the error are also blocked. If the OS fails to establish a mapping, it returns an error response and the descriptor is completed with an error. The error report is the same as the paging error report when the PRS is disabled, as described in the next section.

[0189] As described above, for work queue 1801A with PRS deactivation (mode 1 in FIG. 26), work related to the descriptor terminates at 2604. When a page fault occurs at the completion record address as determined at 2605, the error is reported in the event log if enabled, at 2606 (or in the SWERROR register 2206 in some embodiments). At 2607, the client resolves the page fault and determines the next steps based on the event log. The completion record fault reported in event log 1812 is recoverable. The descriptor completion and event log entries contain the completion record address and the contents of the completion record. After resolving the page fault, the system software can copy the completion record to the completion record address. The completion record fault reported in SWERROR may not be recoverable; the fault may be lost because only a single error is logged; and the descriptor may not have completed and must be restarted because partial completion information was not recorded.

[0190] If it is determined at 2605 that a page lookup error occurred at one address in the descriptor, rather than a completion record address, at 2608, engine 1821A stops operating and writes the partial completion status, along with the error address and progress information, to the completion record in completion record buffer 1911 (as described above). When the client software receives the completion record indicating partial completion, at 2609, it resolves the page lookup error and determines the next steps based on the completion record. For example, the client has the option to overcome the error on the host processor (e.g., by touching the page) and submit a new work descriptor with remaining work. Alternatively, the software can complete the remaining work on the host processor.

[0191] Operations with PRS deactivation and event log enablement as described above reduce the impact on other applications when page lookup errors occur, thereby improving performance.

[0192] In some implementations, if a descriptor within batch descriptor 1950 uses an error due to a completion address, a log entry is pushed into event log 1812. Before the event log entry can be processed (e.g., by device driver software), client 1801 may observe an update to the completion record 2200 for the entire batch descriptor – thereby causing a mismatch in completion record update status or a sequence / timing problem. Similar problems apply to discharge descriptor 2300.

[0193] The following embodiments address this problem. If a completion record for any descriptor in a batch is written to the event log 1812 (e.g., due to a page lookup error related to the completion record), then the completion for the corresponding batch descriptor 1950 is also written to the event log if the completion record or completion interruption is required for batch descriptor 1950.

[0194] Each event log entry for a batch descriptor or a batch descriptor with a page seek error related to an error code contains a batch identifier, which is used (e.g., for a kernel mode driver (KMD)) to be associated with the same batch in the event log completion record.

[0195] If, for a batch descriptor, a page seek error occurs at completion record 2200, and no descriptor in the batch has an event log entry with error code ABC written, then the event log entry for that batch descriptor is written with error ABC. If, for a batch descriptor, a page seek error occurs at completion record address, and error code ABC is written to the event log entry for any descriptor in the batch, then the event log entry for the batch descriptor is written with error XYZ. Using different error codes ABC / XYZ allows the software to distinguish between these two states.

[0196] In some embodiments, when PRS 2501-2502 is disabled, page lookup errors are handled by stopping the operation and reporting a partial completion status on the completion record. Additionally, page lookup errors at completion record addresses are reported via event log 1812, which is enabled simultaneously. In at least one embodiment, the kernel mode driver (KMD) is responsible for configuring and enabling event log 1812. In these embodiments, the KMD must ensure that event log 1812 is large enough and that entries are processed in a timely manner to prevent subsequent event log writes from blocking the device due to the event log being completely consumed.

[0197] In the case where client 1801 is notified of a page lookup error directly through a completion record, the client can overcome (validate) the page lookup error by accessing the page. Once the page lookup error is corrected, client 1801 has the ability to complete the remaining work on the CPU or restart / continue work by unloading it back to accelerator 1800 (e.g., storing a new job descriptor in job queue 1801A).

[0198] In various embodiments, when processing entries in event log 1812 for page seek errors on completion records, the KMD or other authorization software components perform the following operations: 1. If the first error in the batch flag is 1, any previously recorded errors regarding the batch identifier are discarded. This may also occur when batch completion is lost due to an abort command or internal hardware error. Normally, no errors are logged, and no action is required. 2. An attempt is made to correct the page seek error corresponding to the missed address and the PASID reported in event log 1812, and if successful, a completion record is written to the missed address, and if the event log entry indicates that a completion interruption should be generated, a completion interruption is generated. 3. If an error is written to the completion record and the completion record is used for a descriptor in a batch, the KMD (or other software component) associates the error with the batch identifier of the event log entry and tracks it until the event log entry for the corresponding batch descriptor is recognized. The KMD does not need to successfully track the write to the completion record.

[0199] When processing an event log entry for a batch descriptor, if an error code indicates that one or more descriptors in the batch have an event log entry and the event log entry indicates that a completion record should be written for that batch descriptor, assuming an error has already been logged with a matching batch identifier, the KMD or other authorization software component performs the following actions before writing the batch completion record to memory: 1. If the status of the completion record in the event log entry indicates that all descriptors are successful, the KMD (or other component) changes it to indicate that one or more descriptors failed. 2. The KMD or other component should then clear the error log to prepare the same batch identifier for the next batch.

[0200] If no errors were logged for this batch (all completion records were successfully written), the KMD or other components write the batch completion record as "Yes". If the event log entry indicates that an interrupt should be generated, the software should then generate a completion interrupt.

[0201] When an application, user-mode driver (UMD), or other client 1801 receives a completion record indicating partial completion, it can choose to overcome page lookup errors and resubmit the descriptor to the accelerator device 1800 to complete the remaining operations. In most cases, the original descriptor may need to be updated to adjust the transfer size column based on the number of jobs completed. For some operations, additional updates to the original descriptor may be required. When resubmitting a previously terminated batch descriptor, the software can set a batch error flag in the descriptor based on the status of the partially completed batch to ensure that the status of the final completion record for that batch reflects the correct status across all descriptors in that batch.

[0202] For virtualization configuration, the host software can expose virtual event logs to the client and inject error information into the client (e.g., via client KMD) to manage page lookup errors as described above.

[0203] The embodiments of the present invention described herein include one or more of the following: • Selection of per-WQ paging error handling capabilities, including a choice between PRS-based paging error handling and efficient paging error handling as described above. • The ability to directly notify application / uninstall clients of accelerator paging errors (when possible) and the use of event logs, allowing the accelerator driver to delegate paging error handling / notification to the uninstall client (when direct notification is not feasible / not recommended). • Early completion of the error context and immediate switch to the next context. • Handling paging errors in software and completing the remaining work on the host processor or by re-uninstalling to the accelerator device. • Techniques for handling batch descriptors.

[0204] Embodiments of the present invention may include various steps, as described above. These steps may be implemented in machine-executable instructions that cause a general-purpose or special-purpose processor to perform these steps. Alternatively, these steps may be performed by specific hardware components that include hard-wired logic for performing these steps, or by planning any combination of computer components and client hardware components to perform these steps.

[0205] Example

[0206] The following are exemplary embodiments of different embodiments of the present invention.

[0207] Example 1. An apparatus comprising: one or more accelerator engines for processing work descriptors submitted by a client to a plurality of job queues; and error handling hardware logic associated with the one or more accelerator engines, the error handling hardware logic implementing a specified paging error handling mode for each job queue of the plurality of job queues, the paging error handling mode including a first paging error handling mode and a second paging error handling mode.

[0208] Example 2. The device of Example 1, wherein in the first page lookup error handling mode, the error handling logic is used to notify a customer and terminate the processing of the work descriptor associated with the page lookup error.

[0209] Example 3. The device of Example 2, wherein the error handling hardware logic is used to respond to the page lookup error by submitting information to a completion record buffer and / or an event log, the information being relevant to the page lookup error and being usable by the client and / or system software to resolve the page lookup error.

[0210] Example 4. The device of Example 3, wherein the information is used to allow the customer to continue processing or resubmit work related to the descriptor if the work is only partially completed due to the page lookup error.

[0211] Example 5. The device of Example 4, wherein the information includes an error address and a byte completion field to indicate the number of source bytes processed before the page lookup error occurred.

[0212] Example 6. The device of Example 3, wherein if the page seek error occurs at an address associated with the completion record buffer, the information is submitted to the event log instead of the completion record buffer.

[0213] Example 7. The device of Example 6, wherein the event log is used to relate to a specific accelerator engine of the one or more accelerator engines or a specific job column of the majority of job columns.

[0214] Example 8. The device of Example 1, wherein in the second page fault handling mode, the processing of the working descriptor is suspended and the fault handling hardware logic is used to generate a page request to the memory management hardware logic, and the processing of the working descriptor only resumes after receiving a response from the memory management hardware logic.

[0215] Example 9. A method comprising: processing a work descriptor, the work descriptor being submitted by a client to a majority of work queues, using an accelerator engine; responding to the detection of a page fault with respect to a work descriptor in a particular work queue; determining a page fault handling pattern for the work queue; and, if the page fault handling pattern includes a first page fault handling pattern, notifying the client and terminating processing of the work descriptor associated with the page fault.

[0216] Example 10. The method of Example 9 further includes: if the paging error handling mode includes a second paging error handling mode, then the following operations are performed: suspending the work associated with the work descriptor and transmitting the paging error request to the memory management hardware logic, and resuming the work associated with the work descriptor after receiving a response from the memory management hardware logic.

[0217] Example 11. The method of Example 9 further includes: in response to the page lookup error, submitting information to the completion record buffer and / or event log, the information relating to the page lookup error.

[0218] Example 12. The method of Example 11, wherein, based on the information, if the job is only partially completed due to the page lookup error, the customer is used to continue processing or resubmit the job related to the job descriptor.

[0219] Example 13. The method of Example 12, wherein the information includes an error address and a byte completion field to indicate the number of source bytes that have been processed before the page lookup error occurs.

[0220] Example 14. The method of Example 11, wherein if the page seek error occurs at an address associated with the completion record buffer, the information is submitted to the event log instead of the completion record buffer.

[0221] Example 15. The method of Example 11, wherein if the paging error information for the first working descriptor is submitted to the event log, then the paging error information for the second working descriptor is also submitted to the event log instead of the completion record buffer.

[0222] Example 16. The method of Example 15, wherein at least one working descriptor contains a batch descriptor containing a descriptor name unit address, identifies a memory location of a batch descriptor or emission descriptor, such that the accelerator engine waits for the completion of a previous descriptor in the working queue before processing the emission descriptor.

[0223] Example 17. A machine-readable medium having code stored thereon, which, when executed by a machine, causes the machine to perform the following operations: process a work descriptor by an accelerator engine, the work descriptor being submitted by a client to a majority of work queues; in response to detecting a page fault associated with a work descriptor in a particular work queue, determine a page fault handling mode associated with the work queue, and if the page fault handling mode includes a first page fault handling mode, notify the client and terminate the processing of the work descriptor associated with the page fault.

[0224] Example 18. The method of Example 17 further includes: if the paging error handling mode includes a second paging error handling mode, then performing the following operations: suspending the work associated with the work descriptor and transmitting the paging error request to the memory management hardware logic, and resuming the work associated with the work descriptor after receiving a response from the memory management hardware logic.

[0225] Example 19. The method of Example 17 further includes: in response to the page lookup error, submitting information to the completion record buffer and / or event log, the information being related to the page lookup error.

[0226] Example 20. The method of Example 19, wherein if the work is only partially completed due to the page lookup error, the customer is used to continue processing or resubmit the work related to the descriptor based on the information.

[0227] Example 21. The method of Example 20, wherein the information includes an error address and a byte completion field to indicate the number of source bytes processed before the page lookup error occurred.

[0228] Example 22. The method of Example 19, wherein if the page seek error occurs at an address associated with the completion record buffer, the information is submitted to the event log instead of the completion record buffer.

[0229] Example 23. The method of Example 19, wherein if the page fault information for the first working descriptor is submitted to the event log, then the page fault information for the second working descriptor is also submitted to the event log instead of the completion record buffer.

[0230] Example 24. The method of Example 23, wherein at least one working descriptor contains a batch descriptor, which contains a descriptor name unit address indicating the memory location of a batch descriptor or emission descriptor, such that the accelerator engine waits for the completion of a specified previous descriptor in the working queue before processing the emission descriptor.

[0231] As described above, instructions can be represented as a specific configuration of hardware such as an application-specific integrated circuit (ASIC) configured to perform certain operations stored in memory and implemented as non-transitory computer-readable media, or software instructions with predetermined functions. Therefore, the techniques shown in these figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., terminals, network components, etc.). These electronic devices use computer-readable media such as non-transitory computer-readable storage media (e.g., magnetic disks; optical disks; random access memory; read-only memory; flash memory devices; phase-change memory) and transient computer-readable communication media (e.g., electrical, optical, acoustic, or other forms of signal transmission—e.g., carrier waves, infrared signals, digital signals, etc.) to store and communicate (internal and / or via networks with other electronic devices) code and data. Additionally, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input / output devices (e.g., keyboards, touchscreens, and / or displays), and network connectivity. The coupling of this set of processors to other components is typically via one or more buses and bridges (also called bus controllers). Storage devices and signals carrying network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Therefore, the storage devices of a given electronic device typically store code and / or data for execution on the set of one or more processors of the electronic device. Of course, one or more portions of embodiments of the invention may be implemented using different software, firmware, and / or hardware. For purposes of explanation, various specific details throughout the detailed description have been described to provide a full understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without some of these specific details. In some instances, known structures and functions have not been described redundantly to avoid obscuring the subject matter of the invention. Therefore, the scope and spirit of the invention are determined by the following claims. [Simplified Explanation of the Diagram]

[0005] A preferred understanding of the present invention can be obtained from the following detailed description, in conjunction with the accompanying drawings, in which:

[0006] A preferred understanding of the present invention can be obtained from the following detailed description, in conjunction with the accompanying drawings, in which:

[0007] [Figure 1] Example of a computer system architecture;

[0008] [Figure 2] illustrates a processor containing multiple cores;

[0009] [Figure 3A] illustrates a multi-stage processing pipeline;

[0010] [Figure 3B] illustrates the core details of an embodiment;

[0011] [Figure 4] illustrates an execution circuit according to an embodiment;

[0012] [Figure 5] illustrates a temporary register architecture of one embodiment;

[0013] [Figure 6] illustrates an example instruction format;

[0014] [Figure 7] illustrates an addressing technique according to one embodiment;

[0015] [Figure 8] illustrates an embodiment of instruction pre-processing;

[0016] [Figures 9(A)-9(D)] illustrate an example of how the preceding R, X and B fields are used;

[0017] [Figures 10(A)-(B)] illustrate an example of prepositioning the second instruction;

[0018] [Figure 11] illustrates a pre-instruction payload byte in one embodiment;

[0019] [Figure 12] Illustrate the implementation of instruction conversion and binary conversion;

[0020] [Figure 13] Illustrate a scalable device according to an embodiment of the present invention;

[0021] [Figure 14] illustrates an example of a method for handling page lookup errors;

[0022] [Figure 15] illustrates another example of a method for handling page lookup errors according to an embodiment of the present invention;

[0023] [Figure 16] illustrates an accelerator having a work receiving unit, a work scheduler, and a work execution unit;

[0024] [Figure 17] illustrates a transaction between the accelerator and the host root complex;

[0025] [Figure 18] Illustrate an accelerator with error handling logic according to an embodiment of the present invention;

[0026] [Figure 19A] Illustrate a descriptor according to an embodiment of the present invention;

[0027] [Figure 19B] Illustrate a batch descriptor according to an embodiment of the present invention;

[0028] [Figure 20] illustrates the completion record generated by the accelerator;

[0029] [Figure 21] illustrates an event log entry generated by an accelerator according to an embodiment of the present invention;

[0030] [Figure 22] illustrates an accelerator containing multiple control registers;

[0031] [Figure 23] An example of a batch completion record;

[0032] [Figure 24] Illustrated emission descriptors and emission completion records;

[0033] [Figure 25] illustrates an accelerator with multiple engines and job queues, at least a portion of which uses a page request service; and

[0034] [Figure 26] illustrates a method according to an embodiment of the present invention.

Claims

1. A paging error handling apparatus, comprising: one or more accelerator engines for processing work descriptors submitted by a client to a plurality of work queues; and error handling hardware logic associated with the one or more accelerator engines, the error handling hardware logic implementing a specified paging error handling mode for each work queue of the plurality of work queues, the paging error handling mode including a first paging error handling mode and a second paging error handling mode, wherein in the first paging error handling mode, the error handling logic is configured to notify the client and terminate processing of the work descriptor associated with the paging error, wherein the error handling hardware logic is configured to respond to the paging error by submitting information to a completion record buffer and / or an event log, the information being related to the paging error and usable by the client and / or system software to resolve the paging error, and wherein if the paging error occurs at an address associated with the completion record buffer, the information is submitted to the event log instead of the completion record buffer.

2. The device as requested in item 1, wherein the information is used to allow the customer to continue processing or resubmitting work related to the descriptor if the work is only partially completed due to the page lookup error.

3. The device as requested in item 2, wherein the information includes an error address and a byte completion field to indicate the number of source bytes processed before the page lookup error occurred.

4. The device as requested in item 1, wherein the event log is used to relate to a specific accelerator engine of the one or more accelerator engines or a specific job column of the majority job columns.

5. The device as requested in item 1, wherein in the second page fault handling mode, the processing of the working descriptor is suspended and the fault handling hardware logic is used to generate a page request to the memory management hardware logic, and the processing of the working descriptor only resumes after receiving a response from the memory management hardware logic.

6. A method for handling page retrieval errors, comprising: processing a work descriptor, the work descriptor being submitted by a client to a majority of work queues, using an accelerator engine; responding to the detection of a page retrieval error relating to a work descriptor in a particular work queue; determining a page retrieval error handling mode relating to the work queue; if the page retrieval error handling mode includes a first page retrieval error handling mode, notifying the client and terminating processing of the work descriptor relating to the page retrieval error; and responding to the page retrieval error by submitting information to a completion record buffer and / or an event log, the information relating to the page retrieval error, wherein if the page retrieval error occurs at an address associated with the completion record buffer, the information is submitted to the event log but not to the completion record buffer.

7. If the method of request item 6 further includes: if the paging error handling mode includes a second paging error handling mode, then perform the following operations: suspend the work associated with the work descriptor and transmit the paging error request to the memory management hardware logic, and resume the work associated with the work descriptor after receiving a response from the memory management hardware logic.

8. As in request item 6, where, based on the information, if the job is only partially completed due to the page lookup error, the customer is used to continue processing or resubmit the job related to the job descriptor.

9. The method of request item 8, wherein the information includes an error address and a byte completion field to indicate the number of source bytes that were processed before the page lookup error occurred.

10. The method of request item 6, wherein if the paging error information for the first working descriptor is submitted to the event log, the paging error information for the second working descriptor is also submitted to the event log, but not to the completion record buffer.

11. The method of claim 6, wherein at least one working descriptor includes a batch descriptor containing a descriptor name unit address that identifies a memory location of a batch descriptor or emission descriptor, such that the accelerator engine waits for the completion of a specified previous descriptor in the working queue before processing the emission descriptor.

12. A machine-readable medium having code stored thereon, which, when executed by a machine, causes the machine to perform the following operations: Processing a work descriptor by an accelerator engine, the work descriptor being submitted by a client to a majority of work queues; In response to detecting a page fault associated with a work descriptor in a particular work queue: Determining a page fault handling mode associated with the work queue; If the page fault handling mode includes a first page fault handling mode, notifying the client and terminating processing of the work descriptor associated with the page fault; and In response to the page fault, submitting information to a completion record buffer and / or an event log, the information relating to the page fault, wherein if the page fault occurred at an address associated with the completion record buffer, the information is submitted to the event log but not to the completion record buffer.

13. The machine-readable medium of request item 12 further includes: if the paging error handling mode includes a second paging error handling mode, then performing the following operations: suspending the work associated with the work descriptor and transmitting a paging error request to the memory management hardware logic, and resuming the work associated with the work descriptor after receiving a response from the memory management hardware logic.

14. A machine-readable medium as described in request item 12, wherein, If the job is only partially completed due to the page lookup error, the customer is using this information to continue processing or resubmit the job related to that descriptor.

15. The machine-readable medium as requested in item 14, wherein the information includes an error address and a byte completion field to indicate the number of source bytes processed before the page lookup error occurred.

16. The machine-readable medium of request item 12, wherein if the page seek error information for the first working descriptor is submitted to the event log, the page seek error information for the second working descriptor is also submitted to the event log, but not to the completion record buffer.

17. The machine-readable medium of claim 12, wherein at least one working descriptor contains a batch descriptor that includes a descriptor name unit address identifying a memory location of a batch descriptor or emission descriptor, such that the accelerator engine waits for completion of a specified previous descriptor in the working queue before processing the emission descriptor.

18. An apparatus for handling page lookup errors, comprising: means for processing a work descriptor submitted by a client to a majority of work queues; in response to detecting a page lookup error associated with a work descriptor in a particular work queue, the means for processing the work descriptor being configured to: determine a page lookup error handling mode associated with the work queue; if the page lookup error handling mode includes a first page lookup error handling mode, notify the client and terminate processing of the work descriptor associated with the page lookup error; and in response to the page lookup error, submit information to a completion record buffer and / or an event log, the information relating to the page lookup error, wherein if the page lookup error occurs at an address associated with the completion record buffer, the information is submitted to the event log but not to the completion record buffer.

Images