System and method for authenticating extended service microcode updates

Abstract

The invention relates to a system and method for authenticating extended service microcode updates. Apparatus and methods for authenticating extension service microcode updates are described. For example, one embodiment of a method includes storing an extended service microcode update (MCU) in a memory of a processor; reading processor signature data, platform identification data, and processor extension service data from one or more registers of the processor; identifying MCU extended service period data based on the processor signature data and the platform identification data; it is determined whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service period data and the processor extended service data.

Description

Technical Field

[0001] The present disclosure relates generally to computer processors and, more particularly, to extending microcode patching for processor authentication. Background Art

[0002] A processor or a collection of processors executes instructions from an instruction set, such as an instruction set architecture (ISA). An instruction set is the portion of a computer architecture that is relevant to programming, and generally includes 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" herein may refer to macroinstructions, e.g., instructions provided to a processor for execution. Summary of the invention

[0003] According to one aspect of the present disclosure, a method is provided, comprising: loading an extended service microcode update (MCU) into a memory of a processor; reading processor identification data and processor extended service data from one or more registers of the processor; identifying an MCU extended service value in the MCU based on the processor identification data; and determining whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service value and the processor extended service data.

[0004] According to another aspect of the present disclosure, a processor is provided, comprising: a memory for storing an extended service microcode update (MCU); one or more registers for storing processor identification data and processor extended service data; an execution circuit for executing instructions to: read an MCU extended service value from the MCU, the MCU extended service value being identified based on the processor identification data; and determine whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service value and the processor extended service data.

[0005] According to another aspect of the present disclosure, a machine-readable medium storing code is provided, which, when executed by a processor, causes the processor to perform a method, the method comprising: storing an extended service microcode update (MCU) in a memory; reading processor identification data and processor extended service data from one or more registers of the processor; identifying an MCU extended service value of the MCU based on the processor identification data; and determining whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service value and the processor extended service data. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure is illustrated by way of example and not limitation in the accompanying figures in which like references indicate similar elements, and in which:

[0007] Figure 1 A system including a mainboard with a hardware processor according to an embodiment of the present disclosure is illustrated.

[0008] Figure 2 Illustrated is a processor core coupled to a cache in accordance with an embodiment of the present disclosure.

[0009] Figure 3 A processor core according to an embodiment of the present disclosure is illustrated.

[0010] Figure 4 A system including a read-only memory, a patch memory, and a cache according to an embodiment of the present disclosure is illustrated.

[0011] Figure 5A-Figure 5C Extended patching in a system including a read-only memory, a patch memory, and a cache according to an embodiment of the present disclosure is illustrated.

[0012] Figure 6 Extended patching in a system including a read-only memory, a patch memory, a cache, and a system memory according to an embodiment of the present disclosure is illustrated.

[0013] Figure 7 Extended patching in a system including a patch memory, a cache, and a system memory according to an embodiment of the present disclosure is illustrated.

[0014] Figure 8 Extended patching in a system including a patch memory, a cache, and a system memory according to an embodiment of the present disclosure is illustrated.

[0015] Fig. 9 Extended patching in a system including a control register, a read-only memory, a patch memory, and a cache according to an embodiment of the present disclosure is illustrated.

[0016] Fig.10 A flowchart of extended patching according to an embodiment of the present disclosure is illustrated.

[0017] Fig.11 A flowchart of extended patching according to an embodiment of the present disclosure is illustrated.

[0018] Fig.12 A flowchart of extended patching according to an embodiment of the present disclosure is illustrated.

[0019] FIG13(A) illustrates the various stages of a processing pipeline;

[0020] FIG13(B) illustrates details of one embodiment of a core;

[0021] Fig.14 illustrates an execution circuit according to one embodiment;

[0022] Fig.15 One embodiment of a register architecture is illustrated;

[0023] Fig.16 An example of an instruction format is illustrated;

[0024] Fig.17 illustrates an addressing technique according to one embodiment;

[0025] Fig.18 An embodiment of an instruction prefix is ​​illustrated;

[0026] Figure 19(A)-Figure 19(D) illustrates an embodiment of how the R, X, and B fields of the prefix are used;

[0027] Figure 20(A)-Figure 20(B) An example of a second instruction prefix is ​​illustrated;

[0028] Fig.21 illustrates the payload bytes of one embodiment of an instruction prefix;

[0029] Fig. 22 illustrates an example development architecture for IP core development;

[0030] Fig.23 The diagram shows how instruction conversion and binary translation are implemented;

[0031] Fig.24 One embodiment of an architecture for authenticating microcode patches is illustrated.

[0032] Fig.25 An example of a microcode update register for extended service authentication is illustrated.

[0033] Fig.26 A microcode updater in accordance with at least one embodiment is illustrated.

[0034] Figure 27A-27B A data structure for associating microcode update period values ​​with different processors is illustrated.

[0035] Fig.28 A status register for storing an indication of a microcode update failure is illustrated.

[0036] Fig.29 A method according to an embodiment of the present invention is illustrated. DETAILED DESCRIPTION

[0037] In the following description, many specific details are set forth. However, it is to be understood that embodiments of the present disclosure may be implemented without these specific details. In other cases, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this specification.

[0038] References in the specification to "one embodiment", "an embodiment", "an exemplary embodiment", etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment may include the particular feature, structure, or characteristic. In addition, such phrases do not necessarily refer to the same embodiment. In addition, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is considered to be within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments (whether or not explicitly described).

[0039] A (e.g., hardware) processor (e.g., having one or more cores) may execute (e.g., user-level) instructions (e.g., threads of instructions) to operate on data, e.g., to perform arithmetic, logical, or other functions. For example, software may include multiple instructions (e.g., macroinstructions) that are provided to a processor (e.g., one or more cores thereof), which then executes (e.g., decodes and executes) the multiple instructions to perform corresponding operations. In some embodiments, the processor includes circuitry (e.g., decoder circuitry) to translate (e.g., decode) instructions into one or more micro-operations (μop or micro-op), e.g., that are directly executed by hardware. The one or more micro-operations corresponding to an instruction (e.g., a macroinstruction) may be referred to as a microcode stream for the instruction. A micro-operation may be referred to as a microinstruction, e.g., a microinstruction generated by a processor decoding a macroinstruction. In one embodiment, the instruction is a 64-bit and / or 32-bit instruction of an instruction set architecture (ISA). In one embodiment, the instruction is (eg, 64-bit and / or 32-bit) instructions of an instruction set architecture (ISA). In some embodiments, translating instructions into one or more micro-operations is associated with an instruction fetch and / or decode portion of a pipeline of a processor.

[0040] In some (e.g., out-of-order) processors, microcode (e.g., including micro-operations) is stored in a read-only memory (ROM) of the processor, for example, where the ROM is generally referred to as a microcode ROM or μROM. Reading the microcode from the ROM (e.g., reading one or more micro-operations) is performed by a microcode sequencer (e.g., a microcode sequencer circuit) of the processor. In one embodiment, the data (e.g., micro-operations) in the ROM is stored there during the manufacturing process, for example, and the data is unmodifiable (e.g., when in the possession of a consumer). Thus, in some embodiments, the unmodifiable nature of the ROM storing the microcode prevents updates to the microcode.

[0041] Some processors include a patch memory for patching one or more micro-operations of the read-only memory. For example, for an instruction to be executed, the processor obtains a set of micro-operations for the instruction from the patch memory instead of a (e.g., outdated) set of micro-operations for the instruction stored in the read-only memory. In some embodiments, the data stored in the patch memory is modifiable (e.g., when owned by a consumer).

[0042] In some embodiments, the patch memory is within the microcode sequencer circuit (e.g., within the core of the processor), thereby imposing a practical limit on the size of the available patch memory. In one embodiment, the patch memory stores approximately 512 micro-ops. In some embodiments, the read-only memory is within the microcode sequencer circuit, thereby imposing a practical limit on the size of the available read-only memory. In one embodiment, the read-only memory stores approximately 40,000 micro-ops. As an example, multiple critical functional or safety issues to be repaired in the field via microcode patching (e.g., by patching to different micro-ops, which may be referred to as patching microcode) may include providing multiple (e.g., larger in size than the patch memory) micro-ops, and the fixed storage size of the patch memory (e.g., approximately 512 micro-ops) may result in an inability to patch such critical issues.

[0043] Certain embodiments herein extend microcode patching by on-die and off-die (e.g., secure) memory (e.g., storage elements), thereby improving the functionality of the processor. Certain embodiments herein provide additional storage resources for storing a large number (e.g., one thousand or thousands) of additional micro-operations, for example, for patching critical issues and / or adding innovative features and capabilities after manufacturing (e.g., after product release). In one embodiment, the additional storage resource for storing micro-operations is a (one or more) sections of a cache that are not used at runtime and / or are not used by the configuration (e.g., usage environment) of the processor. For example, the additional storage resource can be a section of a cache that is used to store context information for the core when the core is transitioned to a power state that shuts down the voltage to the core. Non-limiting examples of such segments include one or more segments for: storage of context information for a thread (e.g., when the core supports multithreading) transitioning to an idle or off state; storage of context information for a core (e.g., for a multi-core processor) transitioning to an idle or off state; or storage of coherence information for a cache coherence circuit (e.g., a cache box (CBo)) transitioning to an idle or off state. For example, additional storage resources of a processor (e.g., a core) used in a server configuration that does not utilize a graphics processor may be a cache segment reserved for storing context information for (one or more) graphics threads. For example, additional storage resources of a processor (e.g., a core) that does not implement a virtual machine may be a cache segment reserved for storing context information for a virtual machine (e.g., a virtual machine control structure (VMCS)). Certain embodiments of the present invention provide enhanced patch code (e.g., non-transitory storage for enhanced patch code) to allow (e.g., securely) use of additional storage resources for microcode patching. Reference will be made below to Figure 1-Figure 3 An example of a processor having one or more cores patched with extended microcode is initially discussed.

[0044] Figure 1A system 100 including a motherboard 102 having a hardware processor 104 is illustrated in accordance with an embodiment of the present disclosure. The depicted motherboard 102 includes a processor 104 coupled to a hardware initialization manager (non-transitory) storage device 106 and a system memory 108 (e.g., dynamic random-access memory (DRAM)). In one embodiment, the hardware initialization manager (non-transitory) storage device 106 stores hardware initialization manager firmware (e.g., or software). In one embodiment, the hardware initialization manager (non-transitory) storage device 106 stores Basic Input / Output System (BIOS) firmware. In another embodiment, the hardware initialization manager (non-transitory) storage device 106 stores Unified Extensible Firmware Interface (UEFI) firmware. In some embodiments (e.g., triggered by power-on or reboot of the processor), the processor 104 executes hardware initialization manager firmware (e.g., or software) stored in the hardware initialization manager (non-volatile) storage device 106 to initialize the processor to operate, for example, to begin executing an operating system (OS) and / or initialize and test (e.g., hardware) components of the system 100.

[0045] The processor 104 depicted is a multi-core processor including a core circuit 112 having a plurality of cores 110_0 through 110_N, where N is any integer. In another embodiment, the processor includes only a single core. The cores 110_0 through 110_N may be coupled to each other via an interconnect 116 or other electrical coupling. Each core may include components discussed herein, such as, for example, Figure 2 or Figure 3 As shown. The depicted processor 104 includes non-core circuitry 114 that is separate from (e.g., external to) the core circuitry 112. The non-core circuitry 114 may include any combination of the following: a shared cache 118 (e.g., static random-access memory (SRAM)) (e.g., a last-level cache), a memory controller 120 (e.g., to maintain cache coherence in the cache and / or to obtain and retrieve data from the system memory 108 or other memory), and an interface 122 (e.g., to provide coupling with various components that are not part of the processor 104 (e.g., but not limited to peripherals, mass storage devices, etc.).

[0046] For example, Figure 2 and Figure 3As shown, each core can include its own (e.g., unshared) cache layer within the core. Each core (e.g., and individual components of the core) and / or other components of the system 100 can be powered separately, for example, placed in one of a plurality of power states or taken out of the power state. In some embodiments, each power state is a power state according to an Advanced Configuration and Power Interface (ACPI) standard (e.g., Advanced Configuration and Power Interface (ACPI) Specification Revision 5.0A, November 13, 2023). In some embodiments, there is a core state (c-state) for each core, and / or a processor (or package) state (p-state) for each processor.

[0047] Non-limiting examples of p-states are: the P0 performance state, in which the device or processor uses its maximum performance capabilities in this state and may consume maximum power; the P1 performance state, in which the performance capabilities of the device or processor are limited to below their maximum value (e.g., via a lower voltage and / or frequency than P0), and consume less than maximum power; through the Pn performance state, in which the performance capabilities of the device or processor are at their lowest level and consume minimal power while remaining in an active state (e.g., where state n is a maximum number and is processor or device dependent). In some embodiments, processors and devices define support for an arbitrary number of performance states (e.g., not more than 16).

[0048] Non-limiting examples of c-states are: a C0 processor core power state (e.g., an operational power state) in which the processor core is in an executing power state; a C1 processor core power state in which the processor core has sufficiently low hardware latency, low enough that operating software does not consider latency aspects of the state when deciding whether to use the state (e.g., this state has no other software-visible effects other than placing the processor in a non-executing power state); a C2 processor power state that is more power-efficient than the C1 state (e.g., the worst-case hardware latency of this state is provided via the ACPI system firmware, and operating software can use this information to determine when the C1 state should be used instead of the C2 state, and / or this state has no other software-visible effects other than placing the processor core in a non-executing power state); and a C3 processor core power state that is more power-efficient than both the C1 and C2 states. (For example, the worst-case hardware latency for this state is provided via the ACPI system firmware, and operating software can use this information to determine when the C2 state should be used instead of the C3 state, and / or when in the C3 state, the processor's (e.g., core's) caches maintain state but ignore any snooping. For example, the operating software is responsible for ensuring that the caches maintain coherency. Manufacturers can define additional states for their processors. As an example, a C6 processor core power state can be used, in which power (e.g., voltage) to the core is turned off, for example, and entering the C6 state causes the core state (e.g., up and down of the core and / or threads operating on the core) to be changed. In one embodiment, the core 100 is powered down (e.g., the core clock is stopped and / or the core voltage is reduced to zero volts). As another example, a C7 processor core power state may be used that includes a C6 state change, but in which the last level cache (e.g., shared cache 118) is also flushed. In one embodiment, a power manager 124 (e.g., circuitry) controls power levels of components (e.g., cores) of system 100, e.g., based on the power state. In one embodiment, an operating system executing on processor 104 requests a power state change implemented by power manager 124.

[0049] A processor (e.g., each core thereof) may include a microcode sequencer. Certain embodiments herein improve the functionality of a processor by extending microcode patching performed by a microcode sequencer (e.g., circuitry). Figure 2 and Figure 3 , illustrating examples of cores (e.g., Figure 1 Each of the cores 110_0 to 110_N is Figure 2 Core 200 or Figure 3 300 core instances in ).

[0050] Figure 2 A processor core 200 is illustrated coupled to a cache 236 (e.g., a cache external to core 200) in accordance with an embodiment of the present disclosure. In one embodiment, cache 236 includes a dedicated section for storing context information (e.g., a core state, which is different from the core power state) from core 200 when core 200 is transitioned (e.g., from an active power state) to a power state (e.g., a C6 or C7 power state) that shuts down voltage to the core but does not shut down cache 236. Certain embodiments herein utilize cache 236 (e.g., a cache external to core 200) to extend microcode patching performed by microcode sequencer 202 (e.g., circuitry). Certain embodiments herein utilize a dedicated (e.g., C6 or C7) section of cache 236 (e.g., a cache external to core 200) to extend microcode patching performed by microcode sequencer 202 (e.g., circuitry). Certain embodiments herein utilize system memory (e.g., Figure 1 The microcode patching performed by the microcode sequencer 202 (e.g., circuit) can be further extended by utilizing system memory 108 in the microcode sequencer 202 (e.g., circuit), for example by utilizing system memory to provide further (or backup) storage for the microcode patches for the microcode sequencer 202 (e.g., circuit).

[0051] The microcode sequencer 202 may include (i) a read-only memory 204 (ROM) therein (e.g., ROM is generally referred to as microcode ROM or microcode sequencer ROM (MS-ROM or MS-μROM)) 204, and / or (ii) a patch memory 206 therein, for example, patch memory is generally referred to as microcode sequencer writable memory or microcode sequencer random access memory (MS-RAM or MS-μRAM). In one embodiment, the read-only memory 204 of the microcode sequencer 202 stores microcode (e.g., including micro-operations), for example, the microcode sequencer 202 (e.g., microcode sequencer circuit) reads one or more micro-operations from the read-only memory 204 in response to a request for those one or more micro-operations of an instruction (e.g., a macroinstruction). In one embodiment, the micro-operations in the read-only memory 204 are stored therein during the manufacturing process, for example, so that the data is unmodifiable (e.g., when in the possession of a customer). Thus, in some embodiments, the unmodifiable nature of the read-only memory storing the microcode prevents updates to the microcode.

[0052] Some processors include a patch memory 206 for patching one or more micro-operations of the read-only memory 204. For example, for an instruction to be executed, the processor obtains a set of micro-operations for the instruction from the patch memory 206 instead of a (e.g., outdated) set of micro-operations for the instruction stored in the read-only memory 204. In some embodiments, the data stored in the patch memory 206 is modifiable (e.g., when owned by a consumer).

[0053] The depicted core 200 includes a front-end circuit 208 that can be used to perform instruction fetching and translate (e.g., decode) the fetched instructions into one or more micro-operations (μops or micro-ops), which are, for example, directly executed by (one or more) execution circuits 228. The front-end circuit 208 may include any combination of the following: a fetch circuit 210 to fetch instructions requested for execution (e.g., by software); a microcode sequencer 202 (e.g., which utilizes the extended patch disclosed herein); an instruction cache 212 (e.g., which stores macroinstructions, e.g., as a backing store for instruction bytes); a decode stream buffer 214 (e.g., a decode instruction cache) (e.g., to provide a micro-operation stream for instructions); and an instruction decoder circuit 216 (e.g., to perform a decode operation to decode the instruction into (one or more) micro-operations). In one embodiment, the instruction decoder circuit 216 includes multiple instruction inputs and simultaneously determines a set of one or more micro-operations for each instruction. In one embodiment, there is a first proper subset of the plurality of inputs to decoder circuit 216 that decodes all instructions with up to a certain number of micro-operations per group (e.g., decodes all instructions with up to 2, 3, 4, 5, 6, 7, 8, 9, 10, or any other number of micro-operations), and / or a second proper subset of the plurality of inputs to decoder circuit 216 that decodes all instructions with up to a different number of micro-operations per group (e.g., decodes only instructions with a single micro-operation in its group). In some embodiments, instructions with a group of micro-operations greater than a threshold number (e.g., 2, 3, 4, 5, 6, 7, 8, 9, 10, or any other number of micro-operations) are sent to microcode sequencer 202 so that it determines the group of micro-operations for each instruction. Front end circuit 208 may include a queue for micro-operations at its output. Instructions may be identified by their opcodes, for example, as described below. The decode stream buffer 214 (eg, a decode instruction cache) may receive instructions (eg, an opcode for the instruction) from a branch predictor circuit (eg, a branch predictor unit).

[0054] In some embodiments, fetch circuitry 210 fetches instructions (e.g., from memory or instruction cache 212) and feeds them to instruction decoder circuitry 216 to be decoded into micro-operations (e.g., primitives) for execution by execution circuitry(s) 228. In some embodiments, microcode sequencer 202 interfaces with one or more of the various front-end components to initiate and handle microcode fetches from microcode storage locations, e.g., when instruction decoder circuitry 216 does not decode a given instruction. Stream buffer 214 may be used to interface with the memory hierarchy to enable fetching of instructions that were missed in instruction cache 212. In one embodiment, an instruction is provided to decoder circuitry 216, which then causes decode stream buffer 214 to be searched for the set of one or more micro-operations for the instruction. Additionally or alternatively, the instruction is provided to decoder circuit 216, which then causes microcode sequencer 202 to search for the set of one or more micro-operations (e.g., when the set of micro-operations for the instruction exceeds a threshold number, or when the instruction is an instruction to be patched, e.g., this information is determined from a table of circuits for the instruction). In some embodiments, after the instruction is translated (e.g., decoded) into its set of one or more micro-operations, it is then sent to execution circuit(s) 228 for execution.

[0055] exist Figure 2 In the embodiment, an optional out-of-order (OoO) engine 218 (e.g., circuit) is coupled between the front-end circuit 208 and the execution circuit(s) 228 (e.g., execution unit(s)). The out-of-order engine 218 may be used to receive micro-operations and prepare them for execution. In one embodiment, the out-of-order engine 218 may include various buffers to reorder the micro-operation stream and allocate various resources for execution, and to provide renaming of logical registers to storage locations within various register files such as the register file 220 and the extended register file 226. The register file 220 may include separate register files for integer operations and floating-point operations. The register file 220 may include (one or more) model-specific registers 222 and / or (one or more) micropatch matching registers 224. In one embodiment, the model-specific register(s) 222 are used as control registers, for example, to control the operation of the core (e.g., to control the operation of the microcode sequencer 202). The extended register file 226 may provide storage for vector data, for example, 256 or 512 bits per register.

[0056] Various resources may be present in the execution circuitry 228, including, for example, one or more integer, floating point, or single instruction multiple data (SIMD) execution stacks (e.g., execution units), and / or other specialized hardware. For example, such execution circuitry 228 may include one or more arithmetic logic units (ALUs) 230. In some embodiments, the results are provided to a retirement circuitry 232 (e.g., a reorder buffer (ROB)). In one embodiment, the retirement circuitry 232 includes various arrays and circuits for receiving information associated with each instruction executed, which is then checked to determine whether the instruction can be effectively retired and the result data is committed to the architectural state of the processor, for example, or whether one or more exceptions have occurred, preventing the correct retirement of the instruction. The retirement circuitry 232 may handle other operations associated with retirement.

[0057] In some embodiments, the result data is stored in a cache 234 of the core 200 (e.g., as a level 1 (L1) cache or a level 2 (L2) cache) and / or in a cache 236 separate from the core (e.g., as a cache shared by multiple cores, such as a shared L2 or shared level 3 (L3) cache). In one embodiment, the cache shared by multiple cores is powered separately from the cores, for example, so that a single core can be powered down without powering down the shared cache (e.g., so that data stored in the shared cache is not deleted).

[0058] In some embodiments, the program-order core 200 fetches instructions and decodes them into micro-operations (micro-ops) to provide a continuous stream of micro-ops for the next pipeline stage from the (e.g., most likely) path that the program will execute. In some embodiments, the non-program-order core 200 includes an out-of-order engine 218 that reorders the micro-ops into data flow order so that they can be executed as soon as their sources (e.g., input operands) are ready and execution resources are available, and retirement circuitry 232 ensures that the results of the execution of the micro-ops (including any exceptions they may encounter) are visible according to the original program order.

[0059] Figure 3Processor core 300 is illustrated in accordance with an embodiment of the present disclosure. In one embodiment, cache 336 includes a dedicated section for storing context information (e.g., core state, which is different from the core power state) from core 300 (e.g., via port 338) when core 338 is transitioned (e.g., from an active power state) to a power state that shuts down voltage to the core but does not shut down cache 336 (e.g., a C6 or C7 power state). In one embodiment, a power manager (e.g., Figure 1 The power manager 124 in provides a power value 340 to the core to set the core to a certain power level (eg, turn on, reduce but not shut down, and / or shut down power to the core).

[0060] Certain embodiments herein utilize cache 336 (e.g., a cache external to core 300) to extend microcode patching by microcode sequencer 302 (e.g., circuitry). Certain embodiments herein utilize dedicated (e.g., C6 or C7) sections of cache 336 (e.g., a cache external to core 300) to extend microcode patching by microcode sequencer 302 (e.g., circuitry). Certain embodiments herein utilize system memory (e.g., Figure 1 The system memory 108 in the microcode sequencer 302 (e.g., circuit) can be used to further extend the microcode patching performed by the microcode sequencer 302 (e.g., circuit), for example by utilizing system memory to provide further (or backup) storage for the microcode patches for the microcode sequencer 302 (e.g., circuit).

[0061] The microcode sequencer 302 may include (i) a read-only memory 304 (ROM) therein (e.g., ROM is generally referred to as microcode ROM or microcode sequencer ROM (MS-ROM or MS-μROM)) 304, and / or (ii) a patch memory 306 therein (e.g., patch memory is generally referred to as microcode sequencer writable memory or microcode sequencer random access memory (MS-RAM or MS-μRAM)). In one embodiment, the read-only memory 304 of the microcode sequencer 302 stores microcode (e.g., including micro-operations), for example, the microcode sequencer 302 (e.g., microcode sequencer circuit) reads one or more micro-operations from the read-only memory 304 in response to a request for those one or more micro-operations of an instruction (e.g., a macroinstruction). In one embodiment, the micro-operations in the read-only memory 304 are stored therein during the manufacturing process, for example, so that the data is unmodifiable (e.g., when in the possession of a customer). Thus, in some embodiments, the unmodifiable nature of the read-only memory storing the microcode prevents updates to the microcode.

[0062] Some processors include a patch memory 306 for patching one or more micro-operations of the read-only memory 304. For example, for an instruction to be executed, the processor obtains a set of micro-operations for the instruction from the patch memory 306 instead of a (e.g., outdated) set of micro-operations for the instruction stored in the read-only memory 304. In some embodiments, the data stored in the patch memory 306 is modifiable (e.g., when owned by a consumer).

[0063] The depicted core 300 includes a fetch circuit 310 for fetching instructions requested for execution (e.g., by software); a microcode sequencer 302 (e.g., which utilizes the extension patch disclosed herein); a decoded instruction cache 312 (e.g., which provides a set of micro-operations for previously decoded instructions); and an instruction decoder circuit 316 (e.g., for performing a decode operation to decode an instruction into (one or more) micro-operations). In one embodiment, the instruction decoder circuit 316 includes multiple instruction inputs and simultaneously determines a set of one or more micro-operations for each instruction. In one embodiment, there is a first proper subset of the multiple inputs to the decoder circuit 316, which decodes all instructions with up to a certain number of micro-operations per group (e.g., decodes all instructions with up to 3, 3, 4, 5, 6, 7, 8, 9, 10, or any other number of micro-operations), and / or a second proper subset of the multiple inputs to the decoder circuit 316, which decodes all instructions with up to a different number of micro-operations per group (e.g., only decodes instructions with a single micro-operation in its group). In some embodiments, instructions having a set of micro-operations greater than a threshold number (e.g., 3, 3, 4, 5, 6, 7, 8, 9, 10, or any other number of micro-operations) are sent to the microcode sequencer 302 so that it determines the set of micro-operations for each instruction. The core 300 may include an instruction decode queue 308 (e.g., a micro-op queue) to store micro-operations (e.g., from the microcode sequencer 302, the decoded instruction cache 312, the instruction decoder circuit 316, or any combination thereof) and then input them to the execution circuit(s) 328. An instruction may be identified by its opcode, for example, as described below.

[0064] The fetch circuit 310 may send the fetched instruction to the microcode sequencer 302 (e.g., via line 342), the decoded instruction cache 312 (e.g., via line 344), the instruction decoder circuit 316, or any combination thereof. In one embodiment, the fetch circuit 310 sends the fetched instruction to the instruction decoder circuit 316, and the instruction decoder circuit 316 sends the instruction to the microcode sequencer 302 (e.g., via line 342) and / or the decoded instruction cache 312.

[0065] Certain arrows represent bidirectional communication (eg, to and from a component), although unidirectional communication may be used in some embodiments. Certain arrows represent unidirectional communication (eg, to a component), although bidirectional communication may be used in some embodiments.

[0066] In some embodiments, the fetch circuit 310 fetches instructions (e.g., from memory or an instruction cache) and feeds them to the instruction decoder circuit 316 to be decoded into micro-operations (e.g., primitives) for execution by the execution circuit(s) 328. In some embodiments, the microcode sequencer 302 interfaces with one or more core components to initiate and handle microcode fetches from microcode storage locations, for example, when the instruction decoder circuit 316 does not decode a given instruction. In one embodiment, the instruction is provided to the decoder circuit 316, which then causes the decoded instruction cache 312 to be searched for the set of one or more micro-operations for the instruction. Additionally or alternatively, the instruction is provided to the decoder circuit 316, which then causes the microcode sequencer 302 to search the set of one or more micro-operations (e.g., when the set of micro-operations for the instruction exceeds a threshold number, or when the instruction is an instruction to be patched, for example, such information is determined from a table of circuits for the instruction). In some embodiments, after the instruction is translated (eg, decoded) into its set of one or more micro-ops, it is then sent (eg, via optional instruction decode queue 308) to execution circuit(s) 328 for execution.

[0067] Various resources may be present in the execution circuitry 328, including, for example, one or more integer, floating point, or single instruction multiple data (SIMD) execution stacks (e.g., execution units), and / or other specialized hardware. For example, such execution circuitry 328 may include one or more arithmetic logic units (ALUs). In some embodiments, the results are provided to the retirement circuitry 332. In one embodiment, the retirement circuitry 332 includes various arrays and circuits for receiving information associated with each instruction executed, which is then checked to determine whether the instruction can be effectively retired and the result data is submitted to the architectural state of the processor, for example, or whether one or more exceptions have occurred that prevent the correct retirement of the instruction. The retirement circuitry 332 may handle other operations associated with retirement.

[0068] In some embodiments, the result data is saved to an optional cache 334 of the core 300 (e.g., as a level 1 (L1) cache or a level 3 (L2) cache) and / or saved to a cache 336 separate from the core (e.g., as a cache shared by multiple cores, such as a shared L2 or shared level 3 (L3) cache). In one embodiment, the cache 336 is powered separately from the core 300, for example, so that the core 300 can be powered down without powering down the cache 336 (e.g., so that data stored in the shared cache is not deleted). An example of how the microcode sequencer can extend the microcode patching with specific storage (e.g., memory and cache) is provided.

[0069] Figure 4 A system 400 including a read-only memory 404, a patch memory 406, and a cache 408 according to an embodiment of the present disclosure is illustrated. In some embodiments, the system 400 utilizes the cache 408 to extend microcode patching. In some embodiments, the read-only memory 404 (ROM) (e.g., ROM is generally referred to as microcode ROM or microcode sequencer ROM (MS-ROM or MS-μROM)) 404 and / or (ii) the patch memory 406 (e.g., patch memory is generally referred to as microcode sequencer writable memory or microcode sequencer random access memory (MS-RAM or MS-μRAM)) is located within a microcode sequencer 402 (e.g., a microcode sequencer circuit) and / or is reserved for exclusive use (e.g., and / or access) by the microcode sequencer 402. In one embodiment, the microcode sequencer 402 is Figure 2 The microcode sequencer 202 or Figure 3 4. In one embodiment, a read-only memory 404 of the microcode sequencer 402 stores microcode (e.g., including micro-operations), for example, the microcode sequencer 402 (e.g., a microcode sequencer circuit) reads one or more micro-operations from the read-only memory 404 in response to a request for those one or more micro-operations of an instruction (e.g., a macroinstruction). In one embodiment, the micro-operations in the read-only memory 404 are stored there during the manufacturing process, for example, so that the data is unmodifiable (e.g., when in the possession of a consumer). Thus, in some embodiments, the unmodifiable nature of the read-only memory storing the microcode prevents updates to the microcode. Some processors include a patch memory 406 for patching one or more micro-operations of the read-only memory 404. For example, for an instruction to be executed, the processor obtains a set of one or more micro-operations for the instruction from the patch memory 406 instead of the (e.g., now obsolete) set of micro-operations for the instruction stored in the read-only memory 404. In some embodiments, data stored in patch storage 406 is modifiable (eg, when owned by a customer).

[0070] In some embodiments, patch memory 406 is within the microcode sequencer circuit (e.g., within the core of the processor), thereby imposing a limit on the size of the available patch memory. In one embodiment, patch memory 406 stores approximately 512 micro-ops. In some embodiments, read-only memory 404 is within the microcode sequencer circuit, thereby imposing a practical limit on the size of the available read-only memory. In one embodiment, the read-only memory can store approximately 40,000 micro-ops. As an example, multiple critical functional or safety issues to be repaired in the field via microcode patching (e.g., by patching to different micro-ops, which may be referred to as patching microcode) may include providing multiple (e.g., larger than the size of the patch memory) micro-ops, and the fixed storage size of patch memory 406 (e.g., approximately 512 micro-ops) may result in an inability to patch such critical issues.

[0071] Certain embodiments herein extend microcode patching by on-die and off-die (e.g., secure) memory (e.g., storage elements), thereby improving the functionality of the system 400. Certain embodiments herein provide additional storage resources in the cache 408 for storing a large number (e.g., one thousand or thousands) of additional micro-operations. The cache 408 may include a copy of the micro-operations (e.g., patches) for the patch memory 406, for example, to recover the contents of the volatile patch memory 406 that are lost when its power is reduced, while the cache 408 is non-volatile or its power is not reduced to a level that causes the contents to be lost. Certain embodiments herein include storage of extended patch content 412 (e.g., patch micro-operations). In one embodiment, the microcode sequencer 402 executes code that causes data to be copied from the cache 408 to the patch memory 406. However, since actual resources in the system 400 may be limited, making the solution more than just allocating new storage for storing only the extended patch content, certain embodiments herein utilize (e.g., scavenge) memory segments that also have other uses. In one embodiment, storage for extended patch content (eg, micro-operations) is not accessible to users, such as for security purposes.

[0072] Certain embodiments herein utilize secure on-die storage in a cache (e.g., C6 SRAM) for extended patch content (e.g., micro-ops). A first mode of extended patching (e.g., a "ghost" patch embodiment) uses cache segments (e.g., in C6 SRAM) that are not used while the core is running, idle, and / or shut down. A second mode of extended patching (e.g., a "super-ghost" patch embodiment) uses cache segments (e.g., in C6 SRAM) that are not used while the core is running (e.g., a storage area for storing context information from the core when the core is transitioned to a power state that shuts down voltage to the core) (e.g., thread 0, thread 1 to thread 2 in C6 SRAM), and may also be stored (e.g., with integrity encryption) in external storage (e.g., DRAM) (e.g., Figure 1 in system memory 108). The micro-operations of the extended patch contents may be referred to as ghost micro-operations because they are not located in patch memory (e.g., MS-RAM), but are instead located in cache (e.g., C6 SRAM) or system memory (e.g., DRAM). A third mode of extended patching (e.g., an "uber-ghost" patch embodiment) allows dynamic selection (e.g., via control registers) of a true subset of enhanced patch components of the first mode or second mode of extended patching, e.g., depending on platform configuration and / or workload requirements. In some embodiments, the third mode of extended patching allows a user to dynamically select specific portions of performance-sensitive functionality from a unified extended microcode patch having first mode or second mode components at runtime, depending on platform configuration and / or workload requirements.

[0073] Some embodiments of microcode patching are extended by storing a (e.g., small) microcode routine (e.g., code including a set of micro-operations, which may be referred to as enhanced patch code) in a patch memory, which, when executed, causes one or more patch micro-operations of the extended patch content to be stored (e.g., copied) from an extended patch storage area (e.g., a cached C6 power state storage segment) to the patch memory, for use, for example, by a microcode sequencer to translate (e.g., decode) the patched instructions. Note that enhanced patch code may refer to the extended micro-operations that cause storage, but an extended patch storage area may refer to a storage area for micro-operations that are used as patches for instructions themselves (e.g., micro-operations that change the functionality of the instructions).

[0074] In one embodiment, a microcode routine (e.g., code including a set of micro-ops, which may be referred to as enhanced patch code) may be any combination of the following: called from different patch points, obtain exclusive access to execution resources so that only one (e.g., central processing unit (CPU) or logical core) thread is executing, load (e.g., copy without destroying) a (e.g., given) number of micro-ops per instruction from the extended patch storage area into the patch memory, execute those micro-ops for the instruction, and copy (e.g., copy without destroying) the data from the previous patch memory. Figure 4 The microcode sequencer dynamically reconfigures the runtime patch memory (e.g., MS-RAM) to include performance-sensitive micro-operation segments grouped by function (e.g., by macroinstructions), which the platform owner can select from a menu of microcode patch functions of multiple selectable functions via a software interface (e.g., control registers), but these functions cannot all be loaded into the runtime patch memory (e.g., a microcode patch may include two performance-sensitive functions, component 1 and component 2, but only component 1 or component 2 can be loaded into the runtime patch memory, but not both at the same time).

[0075] In some embodiments, microcode patching is extended (e.g., to allow storage of large numbers of micro-ops that can be used to address critical functional and security vulnerabilities or drive innovative capabilities after product release) by leveraging (i) completely unused segments in the cache (e.g., the cached C6 power state segments) (e.g., in a “spectre” patch embodiment) and / or (ii) runtime unused segments of the cache (e.g., the cached C6 power state segments) and system memory (e.g., DRAM backing of C6 SRAM) (e.g., in a “super specter” patch embodiment).

[0076] In some embodiments, due to the single-threaded execution, the extended patch content is copied from the cache (e.g., C6 SRAM) to the patch memory (e.g., MS-RAM), and then the runtime patch content (e.g., from Figure 4Patch content 410) is copied from a cache (e.g., C6 SRAM) to a patch memory (e.g., MS-RAM). Patch swapping may result in a performance penalty, but there are many latency-insensitive or infrequently called functions and security fixes (e.g., filtering processor accesses to devices such as the platform controller hub (PCH), which may take thousands of core cycles to complete) that can fully benefit from the extended patch functionality.

[0077] Certain processor cores (e.g., for client use or server use) may employ on-die storage (e.g., cache segments for storing contextual information for power state changes) for storing thread, core, and / or uncore circuit states (e.g., contextual information) for various environments (e.g., runtime or other copies of microcode patches to patch memory, thread states for low power states (e.g., TC6 / TC7), core states for low power states (e.g., CC6 / CC7), virtual machine caching structure (VMCS) state, graphics state storage (e.g., for graphics thread (GT)), segments used when not at runtime but not used during runtime, storage of coherence information (e.g., low power package state) for transitions of cache coherence circuitry (e.g., cache box (CBo)), thread states upon entering system management mode (SMM), etc.).

[0078] For example, a processor core for use by a server may include an unused section of a cache (e.g., C6 SRAM) (called an address hole, which has a storage area behind it) and / or other unused sections of a cache (e.g., C6 SRAM) (e.g., graphics state storage when the server is not performing graphics processing), and these unused sections of the cache (e.g., C6 SRAM) can be used to store additional microcode patch micro-operation content (e.g., in a "ghost" patch embodiment). In one embodiment, the extended patch content is a micro-operation for patching instructions, and the extended patch content is part of the microcode patch binary image encrypted and signed by the manufacturer, and at the patch load time after the patch authentication is successful, it is written to the unused section of the cache (e.g., C6 SRAM). In some embodiments, the extended patch content (e.g., also) includes a list of micropatch matching registers, which (e.g., when a certain (certain) bit is set) causes an interception (e.g., interruption) of processor execution, and calls to execute enhanced patch code (e.g., "ghost" patch routine) from any process that wishes to use the extended patch (e.g., "ghost" patch) function. In one embodiment, the micropatch matching register includes one or more bits (e.g., ). In one embodiment, the microcode patch loader code, when executed, causes a copy of the patch memory (e.g., a runtime segment of the microcode patch including micro-ops and micro-patch matching registers) to be saved in a segment of the cache (e.g., C6 SRAM), for example, and the extended patch content is saved in a different segment. In some embodiments, the enhancement patch code (e.g., a "ghost" patch routine portion of the runtime MS-RAM) obtains exclusive access so that only one thread is executing (e.g., in the core), and then copies the requested extended patch content segment (e.g., (one or more) patch micro-ops) from the corresponding location in the cache (e.g., C6 SRAM) to the patch memory (e.g., MS-RAM). In one embodiment, the core will copy the patch memory (e.g., MS-RAM) (e.g., Figure 2 Patch memory 206 in Figure 4 Patch memory 306 or Figure 4 406 in the cache (eg, C6 SRAM) to execute (one or more) patch micro-operations and, at the end, to read from a copy of the patch memory stored in another section of the cache (eg, C6 SRAM) (eg, from Figure 4 The patch content 410 in (e.g., a runtime section of a microcode patch including micro-ops and micro-patch matching registers) copies the "original" micro-ops back into the (e.g., runtime) patch memory (e.g., MS-RAM), which can then release exclusive access and return to the interrupt flow.

[0079] In some embodiments, the microcode update populates the patch memory (e.g., Figure 2 206) and matching register(s) (e.g., Figure 2 (one or more) micropatch matching registers 224 in the read-only memory (e.g., Figure 2 204 in the MS-ROM to allow a jump to the patch memory (e.g., Figure 2 In one embodiment, a matching operation is performed for each micro-operation (requested to be executed) with a micro-operation identified as comprising a patch by the matching register(s) (e.g., by comparing a micro-operation pointer (e.g., a microcode instruction pointer (UIP)) with all the multiple pointers of the patched micro-operations stored in the matching registers), and any match results in a jump to (e.g., execution of) the corresponding destination micro-operation address in the patch memory. In one embodiment, a match then triggers the execution of code (e.g., Figures 5A-5C In one embodiment, the matching register includes a microcode matching address (e.g., a micro-operation address of a read-only memory, such as Figure 2 The address of a particular micro-operation in MS-ROM 204 in the patch memory) and the microcode destination address of the patch memory (e.g., Figure 2 The address of (one or more) patched micro-operations in MS-RAM 206 in FIG.

[0080] In some embodiments, a subset (e.g., less than all) of the extended patch content (e.g., micro-operations (one or more)) copied from the extended patch storage segment of the cache (e.g., C6 SRAM) to the patch memory (e.g., MS-RAM) depends on the function that calls the enhanced patch code. In one embodiment, for performance reasons, execution of the enhanced patch code results in loading (e.g., copying) only a subset of the extended patch content (e.g., micro-operations (one or more)), rather than all.

[0081] For example, a processor core for client use may not have enough unused space in the cache segment (e.g., C6 SRAM), so one of the other patch extension modes discussed herein (e.g., the second or third mode) is utilized. For example, a processor core for server use may require more microcode patch storage space than previously unused segments in the cache (e.g., C6 SRAM). In one embodiment, the second mode of patching micro-operations uses existing segments of the cache (e.g., C6 SRAM) that are used when the core / thread is in a low power state, but are not used at runtime (e.g., a thread / core cannot be in an active state and a dormant state at the same time, such as TC6 or TC7 or CC6 or CC7). In one embodiment, when the second mode is enabled, a hardware initialization manager (e.g., BIOS) or software (e.g., OS or virtual machine monitor (VMM)) allocates a reserved area in system memory (e.g., main memory) (e.g., DRAM) via a control register (e.g., a model specific register (MSR) interface).

[0082] In one embodiment, when the second mode is enabled, at patch loading time, if the reserved area is allocated before the microcode patch loading trigger operation, the microcode patch section will store the extended patch content (e.g., micro-operations) in the context information storage section (e.g., for TC6 / TC7 low power state) of the corresponding thread in the cache (e.g., C6 section of SRAM) when loading, and will also store the content in the reserved area in the system memory under integrity protection encryption. In some embodiments, the low power state exit code (e.g., recovery code) (e.g., implementing TC6 / TC7 exit recovery) causes the encrypted version of the extended patch content to be loaded (e.g., copied) from the system memory, decrypted, and the decrypted extended patch content is stored (e.g., if authenticated) back to the context information storage section (e.g., for TC6 / TC7 low power state) of the cache (e.g., C6 SRAM). In one embodiment, the low power state exit code is stored in a (e.g., different) section of the cache (e.g., C6 SRAM), for example, a previously unused section in the cache. In one embodiment, encryption is performed using a (e.g., 128-bit) encryption algorithm (e.g., an Advanced Encryption Standard (AES) encryption algorithm) key generated by an on-die digital random number generator (DRNG), an initialization vector (IV) is a value of the same number of bits (e.g., 128 bits) generated by the on-die digital random number generator (DRNG), the calculated key schedule and IV are stored in (e.g., a fast scratch pad) register located in the core, and integrity is calculated based on the (e.g., AES-Galois / Counter Mode (AES-GCM)) encryption algorithm. In one embodiment, if the microcode patch integrity check fails, the thread will enter an unbreakable shutdown state.

[0083] In some embodiments, at runtime, the functionality of the second mode of extended patching (e.g., a "super ghost" patch embodiment) is the same as the functionality of the first mode of extended patching (e.g., a "ghost" patch embodiment), except that when a thread or core is not running, the extended patch content is copied from the same location that is also used to store context information for the thread or core, respectively, for example, rather than copying the extended patch content from a previously unused segment (e.g., a "hole" that is not set aside for any purpose).

[0084] In some embodiments, a third mode of extended patching (e.g., a "spectre" patching embodiment) allows runtime patch memory (e.g., MS-RAM) to be dynamically reconfigured for performance-sensitive portions of functionality (e.g., to select Fig. 9 ). In one embodiment, a user (e.g., a platform owner or administrator) selects which extended patch functionality (e.g., component(s)) is active at runtime based on a control register (e.g., MSR). In certain embodiments, a third mode of extended patching (e.g., a "very ghost" patch embodiment) includes multiple components that are, for example, part of a microcode patch and are defined as first mode or second mode patch components. In one embodiment, all multiple components of the extended patch content cannot be loaded into the runtime patch memory (e.g., MS-RAM). For example, there may be two components that are part of a given microcode patch, but only one of them can be loaded into the patch memory (e.g., MS-RAM). In one embodiment, a control register (e.g., MSR) allows selection of any component and causes the microcode (e.g., micro-operations) of that component to be copied from that segment of the cache (e.g., the C6 segment of the SRAM) to the patch memory (e.g., MS-RAM).

[0085] Figure 5A-Figure 9 The various storage locations of the code and the extended patch content are illustrated respectively. It should be understood that Figure 5A-Figure 9 Each read-only memory in can be any read-only memory, for example, Figure 2 The read-only memory 204, Figure 3 The read-only memory 304 or Figure 4 The read-only memory 404 in FIG. Figure 5A-Figure 9 Each patch memory in can be any patch memory, for example, Figure 2 Patch memory 206 in Figure 4 Patch memory 306 in or Figure 4 The patch memory 406 in FIG. 406 is shown in FIG. 406. It should be understood that Figure 5A-Figure 9 Each system memory in may be any system memory, for example, Figure 1 108 in the system memory. It should be understood that all storage (eg, memory) may be non-transitory.

[0086] In some embodiments, the read-only memory is loaded with its data (e.g., as shown in the figure) at the time of manufacture. In some embodiments, the patch memory and / or cache is loaded with its data (e.g., as shown in the figure) through a microcode patch binary image sent by the manufacturer, or the firmware is updated to cause the loading of this data.

[0087] Figure 5A-Figure 5CFIG. 5 illustrates extended patching in a system 500 including a read-only memory 504, a patch memory 506, and a cache 508 according to an embodiment of the present disclosure. Figure 5A In some embodiments, the read-only memory 504 includes microcode patch match trigger code 512 and code 516 for copying data from the cache 508 to the patch memory 506. In some embodiments, an instruction is received (e.g., received by a microcode sequencer) for decoding, and it is determined (e.g., by comparing the address, pointer, or opcode of the instruction with the address, pointer, or opcode of the patched instruction list) that the instruction is an instruction to be patched (e.g., using additional and / or different micro-operations than the instructions stored in the read-only memory 504). In some embodiments, receiving the instruction (e.g., for decoding) causes (e.g., by a microcode sequencer) to compare the instruction (e.g., one or more micro-operations of the instruction) with the list of patched instructions (e.g., patched micro-operations). In one embodiment, when a match is determined (e.g., for an enhancement patch), the microcode patch match trigger code 512 then triggers execution of the enhancement patch code 514 (e.g., "ghost" patch code) stored in the patch memory 506. In some embodiments, execution of enhanced patch code 514 (e.g., “ghost” patch code) stored in patch memory 506 causes execution of code 516 to copy extended patch content 520 (e.g., micro-operations) (e.g., all or a proper subset thereof) from cache 508 to patch memory 506, for example, and overwrite micro-operations already stored in patch memory 506.

[0088] exist Figure 5B , a copy 522 of the extended patch content 520 has been saved in the patch storage 506. In one embodiment, the copy 522 overwrites the enhanced patch code 514. In another embodiment, the copy 522 does not overwrite the enhanced patch code 514. Optionally, the completion of saving the copy 522 of the extended patch content in the patch storage 506 is indicated to the code 516, for example, because the code will cause the copy 522 of the extended patch content from the patch storage 506 to be executed.

[0089] exist Figure 5C, execution of the copy 522 of the extended patch content from the patch memory 506 is complete, so the code 516 then causes the data in the patch memory 506 (e.g., all data or just the overwritten data) to be loaded (e.g., restored) from the copy 518 of the overwritten data (e.g., the patch content, but not the extended patch content) to restore the patch content 524. In one embodiment, after the patch content 524 is stored (e.g., restored) in the patch memory 506, for example, an indication of this is sent to the microcode patch match trigger code 512, which allows the microcode sequencer to transfer to decoding the next instruction (e.g., and / or remove the core from single-threaded mode).

[0090] Figure 6 FIG. 6 illustrates extended patching in a system 600 including a read-only memory 604, a patch memory 606, a cache 608, and a system memory 610 according to an embodiment of the present disclosure. Figure 6 Storage and code for multiple patching modes (eg, first, second, and third modes) are illustrated, but it should be understood that any one or more of these components may be used, such as a core for operating in a single patching mode.

[0091] exist Figure 6 In some embodiments, the patch memory 606 includes enhanced patch code 612, which, when executed, causes data (e.g., one or more micro-operations) to be copied from the extended patch storage area (e.g., 618, 620 in the cache 608) to the patch memory 606. The enhanced patch code 612 may include a microcode patch match trigger code. In some embodiments, an instruction is received (e.g., received by a microcode sequencer) for decoding, and it is determined (e.g., by comparing the opcode of the instruction with a list of opcodes of instructions to be patched) that the instruction is an instruction to be patched (e.g., using additional and / or different micro-operations than the instructions stored in the read-only memory 604). In some embodiments, receiving the instruction for decoding causes the execution of the enhanced patch code 612, which compares the instruction (e.g., its opcode) with a list of opcodes of (one or more) instructions to be patched. In one embodiment, when a match is determined, the enhanced patch code 612 causes the extended patch content (e.g., 618 or 620) (e.g., micro-operations) (e.g., all or a proper subset thereof) to be loaded from the cache 608 to the patch memory 606, for example, and overwrites the micro-operations already stored in the patch memory 606.

[0092] The patch memory 606 (or the read-only memory 604) may include a patch load-time code 614 that, when executed, causes the extended patch code (e.g., micro-operations) to be stored in the system memory 610 (e.g., and integrity encrypted). The read-only memory 604 (or the patch memory 606) may include a code 616 that, when executed, causes the patch content to be loaded from the patch content storage area 622 of the cache 608 (e.g., the C6 segment of the cache) into the patch memory 606. In one embodiment, a reset of the processor (e.g., core) causes the execution of the code 616.

[0093] The depicted cache 608 includes two sections 618 and 620 (although a single or any number of sections may be used) that are reserved (e.g., with the highest priority) for context information (e.g., thread state) for each thread (T0 and T1) that is to be shut down (e.g., powering off the core or execution resource for the thread). In one embodiment, the thread state includes the contents of register(s), cache(s), and / or other data in the execution resource at the time of the stop. In some embodiments, one or more of sections 618 and 620 are used as an extended patch storage area for microcode patching (e.g., when each thread is running and has not yet stored its state). The depicted system memory 610 (e.g., in a second mode of microcode patching) includes a partition 628 that is allocated for storing (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 618 of thread 0 of cache 608, such that, for example, when the reserved segment 618 is used to store thread 0 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 628 of system memory 610 into a now unused but reserved segment 618 of thread 0 of cache 608. The depicted system memory 610 (e.g., in a second mode of microcode patching) includes a partition 630 that is allocated for storing (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 620 of thread 1 of cache 608, such that, for example, when the reserved segment 620 is used to store thread 1 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 630 of system memory 610 into a now unused but reserved segment 620 of thread 1 of cache 608.

[0094] The cache 608 may include a copy of the (non-extended) patch content stored in the patch content storage area 622 , eg, a copy of the patch memory 606 before being overwritten with the extended patch content (eg, micro-operations).

[0095] Cache 608 may include low power state exit code 624 (e.g., core or thread context information restoration code), which when executed will copy the extended patch content from system memory 610 (e.g., its partition 628 and / or partition 630) to cache 608 (e.g., its section 618 and / or section 620) (e.g., and perform decryption and authentication). Cache 608 may include other storage areas for non-core circuit state or core state 626, for example, storage areas not utilized during extended microcode patching.

[0096] Figure 7 Extended patching in a system 700 including a patch memory 706, a cache 708, and a system memory 710 is illustrated according to an embodiment of the present disclosure. In one embodiment, the system 700 implements a second mode of extended patching (eg, a "super ghost" patching embodiment).

[0097] exist Figure 7In the embodiment, the patch memory 706 may include a patch load-time code 714, which, when executed, causes the extended patch code (e.g., micro-operations) to be stored in the cache 708 (e.g., stored in the C6 context information storage segment (e.g., block) of the cache), and the extended patch code to be stored in the system memory 710 (e.g., and integrity encrypted). The depicted cache 708 includes two segments 718 and 720 (but a single or any number of segments may be used), which are reserved (e.g., with the highest priority) for context information (e.g., thread state) of each thread (T0 and T1) that is to be shut down (e.g., powering off the core or the execution resource of the thread). In one embodiment, the thread state includes the contents of (one or more) registers, (one or more) caches, and / or other data in the execution resource when stopped. In some embodiments, one or more of the segments 718 and 720 are used as an extended patch storage area for microcode patching (e.g., when each thread is running and its state has not yet been stored). The depicted system memory 710 (e.g., in a second mode of microcode patching) includes a partition 728 that is allocated for storing (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 718 of thread 0 of cache 708, such that, for example, when the reserved segment 718 is used to store thread 0 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 728 of system memory 710 into a now unused but reserved segment 718 of thread 0 of cache 708. The depicted system memory 710 (e.g., in a second mode of microcode patching) includes a partition 730 that is allocated for storing (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 720 of thread 1 of cache 708, such that, for example, when the reserved segment 720 is used to store thread 1 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 730 of system memory 710 into a now unused but reserved segment 720 of thread 1 of cache 708.

[0098] The cache 708 may include a copy 722 of the (non-extended) patch contents, eg, a copy of the patch memory 706 before being overwritten with the extended patch contents (eg, micro-operations).

[0099] Cache 708 may include low (e.g., lower) power state exit code 724 (e.g., core or thread context information recovery code), which when executed copies the extended patch content from system memory 710 (e.g., its partition 728 and / or partition 730) to cache 708 (e.g., its segment 718 and / or segment 720) (e.g., and performs decryption and authentication).

[0100] In some embodiments, at microcode patch load time (e.g., triggered by executing a write to control register instruction to set one or more bits of a control register), patch load time code 714 (e.g., a microcode patch loader) is executed (e.g., after authenticating a new microcode patch specified by software) to cause the extended patch content (e.g., micro-operations) to be stored in the context information storage segment (e.g., 718 or 720 of the TC6 / TC7 low power state) of the corresponding thread of the cache (e.g., the C6 segment of the SRAM), and stored in a reserved area of ​​the system memory 710 with integrity protection encryption. In some embodiments, the low power state exit code 724 (e.g., recovery code) (e.g., implementing TC6 / TC7 exit recovery) causes the encrypted version of the extended patch content to be loaded (e.g., copied) from the system memory 710, decrypted, and the decrypted extended patch content to be stored (e.g., if authenticated) back in the context information storage section (e.g., 718 or 720 for the TC6 / TC7 low power state) of the cache 708 (e.g., C6 SRAM).

[0101] In one embodiment, execution of the patch loading code 714 results in the execution of Figure 7 Storage of one or more (e.g., any combination) of the entries depicted in cache 708 and / or system memory 710.

[0102] Figure 8 Extended patching in a system 800 including a patch memory 806, a cache 808, and a system memory 810 is illustrated according to an embodiment of the present disclosure. In one embodiment, the system 800 implements a second mode of extended patching (eg, a "super ghost" patching embodiment).

[0103] exist Figure 8In some embodiments, the patch memory 806 includes enhanced patch code 812, which, when executed, causes data (e.g., one or more micro-operations) to be copied from the extended patch storage area (e.g., 818, 820 in the cache 808) to the patch memory 806. The enhanced patch code 812 may include a microcode patch match trigger code. In some embodiments, an instruction is received (e.g., received by a microcode sequencer) for decoding, and it is determined (e.g., by comparing the opcode of the instruction with a list of opcodes of instructions to be patched) that the instruction is an instruction to be patched (e.g., using additional and / or different micro-operations than the instructions stored in the read-only memory). In some embodiments, receiving the instruction for decoding causes the execution of enhanced patch code 812, which compares the instruction (e.g., its opcode) with a list of opcodes of (one or more) instructions to be patched. Note the discussion of the opcode field below. In one embodiment, when a match is determined, the enhanced patch code 812 causes the extended patch content (e.g., from 818 or 820) (e.g., micro-ops) (e.g., all or a proper subset thereof) to be loaded from the cache 808 to the patch memory 806, for example, and overwrites the micro-ops already stored in the patch memory 806.

[0104] Patch memory 806 (or read-only memory) may include patch load-time code that, when executed, causes extended patch code (eg, micro-operations) to be stored in system memory 810 (eg, and integrity encrypted).

[0105] The depicted cache 808 includes two sections 818 and 820 (although a single or any number of sections may be used) that are reserved (e.g., with the highest priority) for context information (e.g., thread state) for each thread (T0 and T1) that is to be shut down (e.g., powering off the core or execution resource for that thread). In one embodiment, the thread state includes the contents of register(s), cache(s), and / or other data in the execution resource at the time of the stop. In some embodiments, one or more of sections 818 and 820 are used as an extended patch storage area for microcode patching (e.g., when each thread is running and has not yet stored its state). The depicted system memory 810 (e.g., in a second mode of microcode patching) includes a partition 828 that is allocated to store (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 818 of thread 0 of cache 808, such that, for example, when the reserved segment 818 is used to store thread 0 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 828 of system memory 810 into a now unused but reserved segment 818 of thread 0 of cache 808. The depicted system memory 810 (e.g., in a second mode of microcode patching) includes a partition 830 that is allocated for storing (e.g., at runtime) a (e.g., encrypted) copy of extended patch content (e.g., micro-operations) stored in a reserved segment 820 of thread 1 of cache 808, such that, for example, when the reserved segment 820 is used to store thread 1 state, when the thread state is restored to the thread's execution resources, a copy of the extended patch content is loaded (e.g., copied) from partition 830 of system memory 810 into a now unused but reserved segment 820 of thread 1 of cache 808.

[0106] The cache 808 may include a copy 822 of the (non-extended) patch content, e.g., a copy of the patch memory 806 before being overwritten with the extended patch content (e.g., micro-operations). The cache 808 may include a low-power state exit code 824 (e.g., core or thread context information recovery code) that, when executed, copies the extended patch content from the system memory 810 (e.g., its partition 828 and / or partition 830) to the cache 808 (e.g., its section 818 and / or section 820) (e.g., and performs decryption and authentication).

[0107] In one embodiment, execution of the extended patch code 812 results in the execution of Figure 8 Storage and / or loading of one or more (eg, any combination) of the entries depicted in cache 808 and / or system memory 810.

[0108] In one embodiment, exiting a power state that results in storage of core and / or thread context information to storage segments 818 or 820 (e.g., a TC6 low power state or a TC7 low power state) will result in execution of low power state exit code 824 (e.g., core or thread context information recovery code) which copies the extended patch content from system memory 810 (e.g., partition 828 and / or partition 830 thereof) to cache 808 (e.g., segment 818 and / or segment 820 thereof) (e.g., and decrypts and authenticates / integrity checks it).

[0109] Fig. 9 Extended patching in a system including control registers 940, read-only memory 904, patch memory 906, and cache 908 according to an embodiment of the present disclosure is illustrated. In one embodiment, system 900 implements a third mode of extended patching (eg, a "ghost-like" patching embodiment).

[0110] exist Fig. 9 In the embodiment, the patch memory 906 includes an enhanced patch code 912, which, when executed, reads the value stored in the control register 940, and based on the value, selects one or more extended patch components 1-N (where N is an arbitrary integer) (for example, selects any combination of these components), and causes these components (for example, one or more micro-operations) to be copied from the extended patch storage area 942 to the patch memory 906.

[0111] In one embodiment, the component(s) of the enhanced patch code 912 loaded from the extended patch component storage area 942 of the cache 908 remain stored in the patch memory 906, for example, and overwrite the micro-operations already stored in the patch memory 906. In one embodiment, the extended patch content remains stored in the patch memory until the core is reset or the workload changes (e.g., a change from a first virtual machine to a second virtual machine).

[0112] The cache 908 may include a copy of the (non-extended) patch content stored in the patch content storage area 922, for example, a copy of the patch memory 906 before being overwritten with (one or more) extended patch content components (e.g., micro-operations). In one embodiment, a user (e.g., a platform owner or administrator) selects which extended patch function (e.g., a component or which of the components 1-N) is active at runtime based on the control register 940. In some embodiments, a third mode of extended patching (e.g., a "very ghost" patch embodiment) includes multiple components 1-N, which are, for example, part of a microcode patch and are also defined under the first patch mode or the second patch mode. In one embodiment, all multiple components of the extended patch component cannot be loaded into the runtime patch memory 906 (e.g., MS-RAM). For example, there may be N components as part of a given microcode patch, but only a true subset (e.g., less than N) can be loaded into the patch memory 906 (e.g., MS-RAM). In some embodiments, control registers 940 allow any (one or more) components to be selected (e.g., by software) and cause the microcode (e.g., micro-operations) for that component to be copied from a cached extended patch storage segment 942 (e.g., the C6 segment of SRAM) and then reside in patch memory 906 (e.g., MS-RAM).

[0113] The read-only memory 904 (or patch memory 906) may include code 916 that, when executed, causes patch content to be loaded from a patch content storage area 922 of the cache 908 (e.g., the C6 segment of the cache) into the patch memory 906. In one embodiment, a reset of the processor (e.g., core) causes execution of the code 916.

[0114] In some embodiments herein, the patch memory does not have storage space for the entire set of micro-ops, so the microcode sequencer may iteratively (e.g., serially) swap less than all of the entire set from a cache (e.g., a C6 segment of an SRAM) into a patch memory (e.g., an MS-RAM) until the instruction that caused the extended patching to be used has executed the entire set of micro-ops. In one embodiment, the latency of a core-to-uncore operation (e.g., about 40 core clock cycles) is lower than the latency of a core-to-system memory operation (e.g., about 300 core clock cycles).

[0115] In some embodiments, only microcode (e.g., not user-provided instructions) can access a certain section of the cache (e.g., the C6 section). In one embodiment, a hardware initialization manager (e.g., executing BIOS or UEFI firmware) causes one or more codes discussed herein to be loaded into a storage area, for example, into a certain section of the cache (e.g., the C6 section).

[0116] In some embodiments, a microcode sequencer (e.g., a microcode sequencer circuit) includes code discussed herein, for example, the microcode sequencer causes code to be executed to perform the extended patching, for example, when it receives an instruction to be decoded. The microcode sequencer may utilize any of the methods or processes discussed herein, for example, Figure 10-12 Any of the processes discussed in.

[0117] Fig.10 A flowchart 1000 of extended patching according to an embodiment of the present disclosure is illustrated. The depicted process 1000 includes: utilizing a fetch circuit of a core of a processor to fetch a first instruction, a second instruction, and a third instruction 1002; utilizing a decoder circuit of the core to decode the first instruction into a first group of at least one micro-operation 1004; transmitting the first group of at least one micro-operation from the decoder circuit to an execution circuit of the core 1006; when the core is transitioned to a power state that shuts down a voltage to the core, storing a third group of at least one micro-operation of a third instruction in a segment of a cache storing context information from the core 1008; transmitting, by a microcode sequencer of the core, a second group of at least one micro-operation of a second instruction stored in a read-only memory of the microcode sequencer to an execution circuit of the core 1010; loading, by the microcode sequencer of the core, the third group of at least one micro-operation from the segment of the cache into a patch memory of the microcode sequencer 1012; transmitting, by the microcode sequencer of the core, the third group of at least one micro-operation from the patch memory to the execution circuit 1014; and executing the first, second, and third groups of micro-operations 1016 using the execution circuit of the core.

[0118] Fig.11A flowchart 1100 of extended patching according to an embodiment of the present disclosure is illustrated. The depicted flow 1100 includes: utilizing a fetch circuit of a core of a processor to fetch a first instruction, a second instruction, and a third instruction 1102; utilizing a decoder circuit of the core to decode the first instruction into a first set of at least one micro-operation 1104; transmitting the first set of at least one micro-operation from the decoder circuit to an execution circuit of the core 1106; when the core is transitioned to a power state that shuts down a voltage to the core, storing a third set of at least one micro-operation of the third instruction in a section of a cache storing context information from the core 1108; storing a copy of the third set of at least one micro-operation in a system memory coupled to the processor 1110; and, by a microcode sequencer of the core, storing the microcode sequence stored in the microcode sequencer. sending a second group of at least one micro-operation of a second instruction in the read-only memory to the execution circuit of the core 1112; storing at least one micro-operation of a fourth group in the patch memory, wherein the microcode sequencer causes execution of the fourth group so that at least one micro-operation of a third group is loaded from the system memory into the segment of the cache 1114; loading, by the microcode sequencer of the core, at least one micro-operation of the third group from the segment of the cache into the patch memory of the microcode sequencer 1116; sending, by the microcode sequencer of the core, at least one micro-operation of the third group from the patch memory to the execution circuit 1118; and executing the first, second and third groups of micro-operations using the execution circuit of the core 1120.

[0119] Fig.12A flowchart 1200 of extended patching according to an embodiment of the present disclosure is illustrated. The depicted flow 1200 includes storing a first value or a second value in a patch control field of a control register of a core of a processor 1202; utilizing a fetch circuit of the core of the processor to fetch a first instruction, a second instruction, a third instruction, and a fourth instruction 1204; utilizing a decoder circuit of the core to decode the first instruction into a first set of at least one micro-operation 1206; transmitting the first set of at least one micro-operation from the decoder circuit to an execution circuit of the core 1208; when the core is transitioned to a power state in which a voltage to the core is turned off, storing a third set of at least one micro-operation of the third instruction in a section of a cache storing context information from the core 1210; when the core is transitioned to a power state in which a voltage to the core is turned off, storing a fourth set of at least one micro-operation of the fourth instruction in the section of a cache storing context information from the core 1212; and, by a microcode sequencer of the core, storing a second set of at least one micro-operation of the second instruction stored in a read-only memory of the microcode sequencer 1213. at least one micro-operation is sent to the execution circuit 1214 of the core; when the first value is stored in the patch control field of the control register, the microcode sequencer of the core loads at least one micro-operation of the third group from the segment of the cache into the patch memory of the microcode sequencer, and when the first value is stored in the patch control field of the control register, the microcode sequencer of the core sends at least one micro-operation of the third group from the patch memory to the execution circuit 1216; when the second value is stored in the patch control field of the control register, the microcode sequencer of the core loads at least one micro-operation of the fourth group from the segment of the cache into the patch memory of the microcode sequencer, and when the second value is stored in the patch control field of the control register, the microcode sequencer of the core sends at least one micro-operation of the fourth group from the patch memory to the execution circuit 1218; and the first, second and third or fourth groups of micro-operations are executed using the execution circuit of the core 1220.

[0120] In one embodiment, a processor includes a core, a cache having a (e.g., user-inaccessible) section for storing context information from the core when the core is transitioned to a power state that shuts down a voltage to the core, a fetch circuit of the core for fetching a first instruction, a second instruction, and a third instruction, a decoder circuit of the core coupled to the fetch circuit for (e.g., without using a microcode sequencer) decoding the first instruction into a first set of at least one micro-operation, an execution circuit for executing the micro-operations, and a microcode sequencer of the core coupled to the fetch circuit (and / or the decoder circuit) and including a patch memory and a read-only memory (e.g., user-inaccessible) storing a plurality of micro-operations, wherein the microcode sequencer, for a second instruction received from the fetch circuit, sends to the execution circuit a second set of at least one micro-operation from the plurality of micro-operations stored in the read-only memory, and for a third instruction received from the fetch circuit, causes a third set of at least one micro-operation to be loaded from the section of the cache into the patch memory, and sends the third set of at least one micro-operation from the patch memory to the execution circuit. The power state may be a C6 (or deeper) power state according to the Advanced Configuration and Power Interface (ACPI) standard. The patch memory may include a fourth group of at least one micro-operation (e.g., enhancement patch code) for the third instruction, and when the microcode sequencer causes the fourth group to be executed, the third group of at least one micro-operation is loaded from the section of the cache into the patch memory. The firmware stored in a non-volatile storage device (e.g., a hardware initialization manager storage device) coupled to the processor may include instructions that, when decoded and executed by the processor, cause the processor to insert the fourth group of at least one micro-operation into the patch memory for the third instruction. The third group of at least one micro-operation loaded into the patch memory may overwrite at least one of the plurality of micro-operations stored in the patch memory, and when execution of the third group of at least one micro-operation is completed, the microcode sequencer may reload at least one of the overwritten plurality of micro-operations. The microcode sequencer may cause, for a fourth instruction fetched by the fetch circuit, a fourth group of at least one micro-operation different from the third group to be loaded into the patch memory from the section of the cache, and the fourth group of at least one micro-operation to be sent from the patch memory to the execution circuit. The processor may include a system memory coupled to the processor, the system memory including a copy of the third set of at least one micro-operation, wherein the patch memory includes a fourth set of at least one micro-operation that causes the third set of at least one micro-operation to be loaded from the system memory (e.g., only after decryption and authentication) into the segment of the cache when the microcode sequencer causes the fourth set to be executed. The microcode sequencer may cause the fourth set to be executed when the core is transitioned to a power state that turns on a voltage to the core (e.g., ACPI C0).

[0121] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operation objects and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the fields included are usually in the same order, but at least some have different bit positions because the fields included are less) and / or defined as having given fields interpreted in different ways. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed with a given instruction template in the instruction template of the instruction format), and includes fields for specifying operations and operation objects. For example, an exemplary ADD instruction has a specific opcode and instruction format, the instruction format including an opcode field to specify the opcode and an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in an instruction stream will have specific content in the operand field that selects the specific operand. A set of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) and using the Vector Extension (VEX) encoding scheme have been released and / or published (e.g., see 64 and IA-32 Architectures Software Developer's Manual, May 2018; and see Architecture Instruction Set Extension Programming Reference, May 2018).

[0122] Example core architectures—in-order and out-of-order core block diagrams.

[0123] Figure 13(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example. Figure 13(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example. Figure 13 (A) - Figure 13 (B) The solid line boxes in illustrate the in-order pipeline and in-order core, while the optionally added dashed line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0124] In FIG. 13(A), the processor pipeline 1300 includes a fetch stage 1302, an optional length decoding stage 1304, a decode stage 1306, an optional allocation (Alloc) stage 1308, an optional rename stage 1310, a dispatch (also called dispatch or issue) stage 1312, an optional register read / memory read stage 1314, an execute stage 1316, a write back / memory write stage 1318, an optional exception handling stage 1322, and an optional commit stage 1324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1302, one or more instructions are fetched from the instruction memory, and during the decode stage 1306, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In some examples, decode stage 1306 and register read / memory read stage 1314 can be combined into one pipeline stage. In some examples, during execute stage 1316, decoded instructions can be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface can be performed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, and the like.

[0125] As an example, the example register renaming, out-of-order issue / execution architecture core of FIG. 13(B) may implement pipeline 1300 in the following manner: 1) instruction fetch circuit 1338 performs fetch and length decoding stages 1302 and 1304; 2) decoding circuit 1340 performs decoding stage 1306; 3) renaming / allocator unit circuit 1352 performs allocation stage 1308 and renaming stage 1310; 4) (one or more) scheduler circuit 1356 performs scheduling stage 1312; 5) (one or more) physical registers The register file circuit 1358 and the memory unit circuit 1370 perform the register read / memory read phase 1314; (one or more) execution clusters 1360 perform the execute phase 1316; 6) the memory unit circuit 1370 and (one or more) physical register file circuits 1358 perform the write back / memory write phase 1318; 7) various circuits may be involved in the exception handling phase 1322; and 8) the retirement unit circuit 1354 and (one or more) physical register file circuits 1358 perform the commit phase 1324.

[0126] 13(B) shows that the processor core 1390 includes a front end unit circuit 1330 coupled to an execution engine unit circuit 1350, and both are coupled to a memory unit circuit 1370. The core 1390 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1390 can be a special-purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0127] The front end unit circuit 1330 may include a branch prediction circuit 1332 coupled to an instruction cache circuit 1334 coupled to an instruction translation lookaside buffer (TLB) 1336 coupled to an instruction fetch circuit 1338 coupled to a decode circuit 1340. In some examples, the instruction cache circuit 1334 is included in the memory unit circuit 1370 instead of the front end circuit 1330. The decode circuit 1340 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, micro-instructions, other instructions, or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode circuit 1340 may also include an address generation unit (AGU, not shown) circuit. In some examples, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuit 1340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In some examples, the core 1390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit 1340 or otherwise within the front end circuit 1330). In some examples, the decode circuit 1340 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1300. The decode circuit 1340 may be coupled to the rename / allocator unit circuit 1352 in the execution engine circuit 1350.

[0128] The execution engine circuit 1350 includes a rename / allocator unit circuit 1352, which is coupled to a retirement unit circuit 1354 and a set of one or more scheduler circuits 1356. The scheduler circuit 1356 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit(s) 1356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit(s) 1356 are coupled to the physical register file(s) circuit(s) 1358. Each of the physical register file circuits 1358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., an instruction pointer that is the address of the next instruction to be executed), and the like. In some examples, the (one or more) physical register file circuits 1358 include vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The (one or more) physical register file circuits 1358 are coupled to the retirement unit circuit 1354 (also called the retirement queue) to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROB) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and pools of registers; etc.). The retirement unit circuit 1354 and the (one or more) physical register file circuits 1358 are coupled to (one or more) execution clusters 1360. The (one or more) execution clusters 1360 include a set of one or more execution unit circuits 1362 and a set of one or more memory access circuits 1364. The execution unit circuit(s) 1362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 1356, physical register file circuit(s) 1358, and execution cluster(s) 1360 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuit(s), physical register file circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has memory access unit circuit(s) 1364 in some examples of the implementation). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0129] In some examples, the execution engine unit circuit 1350 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0130] A set of memory access circuits 1364 are coupled to the memory cell circuit 1370, which includes a data TLB circuit 1372, which is coupled to a data cache circuit 1374, which is coupled to a level 2 (L2) cache circuit 1376. In some examples, the memory access circuit 1364 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 1372 in the memory cell circuit 1370. The instruction cache circuit 1334 is further coupled to the level 2 (L2) cache circuit 1376 in the memory cell circuit 1370. In some examples, the instruction cache 1334 and the data cache 1374 are combined into a single instruction and data cache in the L2 cache circuit 1376, a level 3 (L3) cache circuit (not shown), and / or a main memory (not shown). The L2 cache circuit 1376 is coupled to one or more other levels of cache and ultimately to the main memory.

[0131] Core 1390 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added with newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In some examples, core 1390 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data.

[0132] Example execution unit circuit(s).

[0133] Fig.14 An example of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 1362 of FIG. 13 (B). As shown, (one or more) execution unit circuits 1362 may include one or more ALU circuits 1401, optional vector / single instruction multiple data (single instruction multiple data, SIMD) circuits 1403, load / store circuits 1405, branch / jump circuits 1407, and / or floating-point unit (FPU) circuits 1409. ALU circuits 1401 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1403 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 1405 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 1405 may also generate addresses. Branch / jump circuits 1407 cause branches or jumps to a certain memory address depending on the instruction. FPU circuit 1409 performs floating point arithmetic. The width of execution unit circuit(s) 1362 varies depending on the example and may range, for example, from 16 bits to 1024 bits. In some examples, 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).

[0134] Example register architecture.

[0135] Fig.151 is a block diagram of a register architecture 1500 according to some examples. As shown, the register architecture 1500 includes a vector / SIMD register 1510, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1510 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some examples, the vector / SIMD register 1510 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the example.

[0136] In some examples, the register architecture 1500 includes a write mask / predicate register 1515. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 1515 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1515 corresponds to a data element position at the destination. In other examples, the write mask / predicate register 1515 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).

[0137] The register architecture 1500 includes a plurality of general purpose registers 1525. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some examples, these registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0138] In some examples, register architecture 1500 includes a scalar floating-point (FP) register file 1545, which is used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set architecture extensions, or as an MMX register to perform operations on 64-bit packed integer data, and to store operands for some operations performed between MMX and XMM registers.

[0139] One or more flag registers 1540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1540 can store condition code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1540 are referred to as program status and control registers.

[0140] Segment registers 1520 contain segment points for accessing memory. In some examples, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0141] Model specific registers or machine specific registers (MSRs) 1535 control and report processor performance. Most MSRs 1535 handle system-related functions and are not accessible to applications. For example, MSRs may provide control of one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal management and power management, instruction specific support, and / or processor feature / mode support. Machine check registers 1560 consist of control, status, and error reporting MSRs for detecting and reporting hardware errors. (One or more) control registers 1555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors `BPA70, `BPA80, `BPA38, `BPA18, and / or `BPB00) and the characteristics of the currently executing task. In some examples, MSRs 1535 are a subset of control registers 1555.

[0142] One or more instruction pointer registers 1530 store instruction pointer values. Debug registers 1550 control and allow monitoring of debug operations of the processor or core.

[0143] Memory (mem) management registers 1565 specify the location of data structures used in protected mode memory management. These registers may include global descriptor table registers (GDTR), interrupt descriptor table registers (IDTR), task registers, and local descriptor table registers (LDTR) registers.

[0144] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer or different register files and registers. Register architecture 1500 may be used, for example, in register file / memory `ISAB08, or (one or more) physical register file circuits 1358.

[0145] Instruction set architecture.

[0146] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, the example ADD instruction has a specific opcode and instruction format, the instruction format includes an opcode field to specify the opcode, and includes an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field that selects the specific operand. In addition, although the following description is made in the context of the x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of the present disclosure to other ISAs.

[0147] Example instruction format.

[0148] The examples of the (one or more) instructions described herein may be implemented in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0149] Fig.16 An example of an instruction format is illustrated. As shown, an instruction may include multiple components, including, but not limited to, one or more fields for: one or more prefixes 1601, an opcode 1603, addressing information 1605 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1607, and / or an immediate value 1609. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1603 field. In some examples, the illustrated order is the order in which the fields are to be encoded, however, it should be understood that in other examples, the fields may be encoded in another order, combined, etc.

[0150] (One or more) prefix fields 1601 modify the instruction when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0151] The opcode field 1603 is used to at least partially define the operation to be performed when the instruction is decoded. In some examples, the length of the primary opcode encoded in the opcode field 1603 is one, two, or three bytes. In other examples, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0152] The addressing information field 1605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig.17An example of an addressing information field 1605 is illustrated. In this illustration, an optional MOD R / M byte 1702 and an optional Scale, Index, Base (SIB) byte 1704 are shown. The MOD R / M byte 1702 and SIB byte 1704 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that these fields are optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 1702 includes a MOD field 1742, a register (reg) field 1744, and an R / M field 1746.

[0153] The content of MOD field 1742 distinguishes between memory access mode and non-memory access mode. In some examples, when MOD field 1742 has a binary value of 11 (11b), register direct addressing mode is utilized, otherwise register indirect addressing mode is used.

[0154] Register field 1744 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register field 1744 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 1744 is supplemented with additional bits from a prefix (e.g., prefix 1601) to allow for greater addressing.

[0155] R / M field 1746 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 1746 may be combined with MOD field 1742 to specify an addressing mode.

[0156] SIB byte 1704 includes a scale field 1752, an index field 1754, and a base address field 1756 for address generation. Scaling field 1752 indicates a scaling factor. Index field 1754 specifies the index register to be used. In some examples, index field 1754 is complemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. Base address field 1756 specifies the base address register to be used. In some examples, base address field 1756 is complemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. In practice, the contents of scale field 1752 allow the contents of index field 1754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0157] Some addressing forms utilize a displacement value to generate a memory address. For example, a memory address may be generated based on 2 scale * index + base address + displacement, index * scale + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 1607 provides this value. In addition, in some examples, the use of a displacement factor is encoded in the MOD field of the addressing information field 1605, which indicates a compressed displacement scheme, for which the displacement value is calculated and stored in the displacement field 1607.

[0158] In some examples, the immediate value field 1609 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, and so on.

[0159] Fig.18 An example of a first prefix 1601(A) is illustrated. In some examples, the first prefix 1601(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction, multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0160] Instructions using the first prefix 1601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702; 2) using the MOD R / M byte 1702 with the SIB byte 1704, including using the reg field 1744 as well as the base field 1756 and the index field 1754; or 3) using the register field of the opcode.

[0161] In the first prefix 1601 (A), bit positions 7:4 of the payload bytes are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0162] Note that adding another bit allows addressing 16 (2 4 ) registers, while the separate MOD R / M reg field 1744 and MOD R / MR / M field 1746 can only address 8 registers each.

[0163] In the first prefix 1601(A), bit position 2 (R) may be an extension of the MOD R / M reg field 1744 and may be used to modify the MOD R / M reg field 1744 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 1702 specifies another register or defines an extended opcode, R is ignored.

[0164] Bit position 1 (X) may modify the SIB byte index field 1754 .

[0165] Bit position 0 (B) may modify the base address in R / M field 1746 or SIB byte base address field 1756 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 1525).

[0166] Figure 19(A)-Figure 19(D) An example of how the R, X, and B fields of the first prefix 1601 (A) are used is illustrated. FIG. 19 (A) illustrates that when the SIB byte 17 04 is not used for memory addressing, the R and B from the first prefix 1601 (A) are used to extend the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702. FIG. 19 (B) illustrates that when the SIB byte 17 04 is not used, the R and B from the first prefix 1601 (A) are used to extend the reg field 1744 and the R / M field 1746 of the MOD R / M byte 1702 (register-register addressing). FIG. 19 (C) illustrates that when the SIB byte 17 04 is used for memory addressing, the R, X, and B from the first prefix 1601 (A) are used to extend the reg field 1744 of the MOD R / M byte 1702 and the index field 1754 and the base address field 1756. 19(D) illustrates that when a register is encoded in the opcode 1603 , the B from the first prefix 1601 (A) is used to extend the reg field 1744 of the MOD R / M byte 1702 .

[0167] Figure 20(A)-Figure 20(B)An example of a second prefix 1601(B) is illustrated. In some examples, the second prefix 1601(B) is an example of a VEX prefix. The second prefix 1601(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD registers 1510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1601(B) provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 1601(B) enables the operands to perform non-destructive operations, such as A=B+C.

[0168] In some examples, the second prefix 1601(B) has two forms - a two-byte form and a three-byte form. The two-byte second prefix 1601(B) is mainly used for 128-bit, scalar and some 256-bit instructions; while the three-byte second prefix 1601(B) provides a compact replacement for 3-byte opcode instructions and the first prefix 1601(A).

[0169] Figure 20 (A) illustrates an example of a two-byte form of the second prefix 1601 (B). In some examples, the format field 2001 (byte 0 2003) contains the value C5H. In some examples, byte 1 2005 includes an "R" value in bit [7]. This value is the complement of the "R" value of the first prefix 1601 (A). Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0170] Instructions using this prefix may use MOD R / MR / M field 1746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0171] Instructions using this prefix may use MOD R / M register field 1744 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0172] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 1746, and MOD R / M register field 1744 encode three of the four operands. Bits [7:4] of immediate value field 1609 are then used to encode the third source register operand.

[0173] Figure 20 (B) illustrates an example of a three-byte form of the second prefix 1601 (B). In some examples, the format field 2011 (byte 0 2013) contains the value C4H. Byte 1 2015 includes "R", "X" and "B" in bit [7:5], which are the complements of these values ​​of the first prefix 1601 (A). Bit [4:0] (shown as mmmmm) of byte 1 2015 includes the content of encoding one or more implicit leading operation code bytes as needed. For example, 00001 means 0FH leading operation code, 00010 means 0F38H leading operation code, 00011 means 0F3AH leading operation code, etc.

[0174] The use of bit [7] of byte 2 2017 is similar to W of the first prefix 1601 (A), including helping to determine the size of the operand that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0175] Instructions using this prefix may use MOD R / MR / M field 1746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0176] Instructions using this prefix may use MOD R / M register field 1744 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0177] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 1746, and MOD R / M register field 1744 encode three of the four operands. Bits [7:4] of immediate value field 1609 are then used to encode the third source register operand.

[0178] Fig.21 An example of a third prefix 1601(C) is illustrated. In some examples, the third prefix 1601(C) is an example of an EVEX prefix. The third prefix 1601(C) is a four-byte prefix.

[0179] The third prefix 1601(C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see the discussion of registers in previous figures, e.g., Fig.15 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 1601 (B).

[0180] The third prefix 1601(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0181] The first byte of the third prefix 1601 (C) is the format field 2111, which in some examples has a value of 62 H. The subsequent bytes are called payload bytes 2115-2119, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0182] In some examples, P[1:0] of payload byte 2119 is the same as the two mm bits in the lower order. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and the reg field 1744 of MOD R / M. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. 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 combined with the MOD R / M register field 1744 and the MOD R / MR / M field 1746, allows access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

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

[0183] P

[15] is similar to W of the first prefix 1601 (A) and the second prefix 1611 (B), and can be used as an opcode extension bit or an operand size increase.

[0184] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / predicate register 1515). In some examples, a particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in some other examples, the old value of each element of the destination where the corresponding mask bit has a value of 0 is retained. In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in some examples, the elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span of elements modified, from first to last); however, the elements modified do not have to be contiguous. Thus, the operation mask field allows for a subset of vector operations, including loads, stores, arithmetic, logical, and so on. While in the described examples, the contents of the operation mask field selects which of several operation mask registers contains the operation mask to be used (thus the contents of the operation mask field indirectly identify the masking to be performed), alternative examples alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0185] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes various features that vary in different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

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

[0186] An example of the encoding of registers in instructions using the third prefix 1601 (C) is detailed in the table below.

[0187]

[0188] Table 1: 32-register support in 64-bit mode

[0189]

[0190]

[0191] Table 2: Encoding register specifiers in 32-bit mode

[0192]

[0193] Table 3: Operation Mask Register Specifier Encoding

[0194] IP core implementation

[0195] One or more aspects of at least some examples may be implemented by representative code stored on a machine-readable medium, which represents and / or defines logic within an integrated circuit such as a processor. For example, a machine-readable medium may include instructions representing various logics within a processor. When read by a machine, the instructions may cause the machine to make logic to perform the techniques described herein. This form of expression, known as an "IP core," is a reusable unit of logic for an integrated circuit that may be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be provided to various customers or manufacturing facilities, which load the hardware model on a manufacturing machine that manufactures the integrated circuit. An integrated circuit may be made so that the circuit performs the operations described in association with any of the examples described herein.

[0196] Fig. 22 The block diagram of illustrates an IP core development system 2200 according to some examples, which can be used to manufacture integrated circuits to perform operations. The IP core development system 2200 can be used to generate modular, reusable designs that can be included in larger designs or used to construct entire integrated circuits (e.g., SOC integrated circuits). The design facility 2230 can generate a software simulation 2210 of the IP core design in a high-level programming language (e.g., C / C++). The software simulation 2210 can be used to design, test, and verify the behavior of the IP core using a simulation model 2212. The simulation model 2212 may include functional, behavioral, and / or timing simulations. A register transfer level (RTL) design 2215 can then be created or synthesized from the simulation model 2212. The RTL design 2215 is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including associated logic that is executed using the modeled digital signals. In addition to the RTL design 2215, a lower level design at the logic level or transistor level can also be created, designed, or synthesized. Thus, the specific details of the initial design and simulation may vary.

[0197] The RTL design 2215 or equivalent may also be synthesized by the design facility into a hardware model 2220, which may take the form of a hardware description language (HDL), or some other representation of physical design data. The HDL may be further simulated or tested to verify the IP core design. The IP core design may be stored for delivery to a third party fabrication facility 2265 using a non-volatile memory 2240 (e.g., a hard disk, a flash memory, or any other non-volatile storage medium). Alternatively, the IP core design may be transmitted via a wired connection 2250 or a wireless connection 2260 (e.g., via the Internet). The fabrication facility 2265 may then fabricate an integrated circuit based at least in part on the IP core design. The fabricated integrated circuit may be configured to perform operations according to at least some of the examples described herein.

[0198] Fig.23 The block diagram of illustrates the use of a software instruction converter according to an example, which is used to convert binary instructions in a source ISA into binary instructions in a target ISA. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.23 It is shown that a program in a high-level language 2302 can be compiled using a first ISA compiler 2304 to generate first ISA binary code 2306 that can be natively executed by a processor having at least one first ISA core 2316. The processor having at least one first ISA core 2316 represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the first ISA or (2) a program that is natively executed by a processor having at least one first ISA core. The first ISA compiler 2304 represents a compiler operable to generate first ISA binary code 2306 (e.g., object code) that can be executed on a processor 2316 having at least one first ISA core with or without additional linking processing. Similarly, Fig.23It is shown that a program in a high-level language 2302 can be compiled using an alternative ISA compiler 2308 to generate an alternative ISA binary code 2310, which can be executed natively by a processor 2314 without a first ISA core. An instruction converter 2312 is used to convert the first ISA binary code 2306 into code that can be executed natively by a processor 2314 without a first ISA core. This converted code will not necessarily be the same as the alternative ISA binary code 2310; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 2312 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without a first ISA processor or core to execute the first ISA binary code 2306 through simulation, emulation, or any other process.

[0199] System and method for authenticating extended services microcode updates

[0200] As mentioned above, some implementations support the release of processor microcode updates in the field, potentially years after the processor was purchased. Generally speaking, when a processor manufacturer discontinues service for a particular generation of processors, it also discontinues microcode updates. However, in some cases, a processor manufacturer may extend service and continue to release microcode updates for certain customers who are willing to pay for an extended service license. The problem is that there is no enforcement mechanism to prevent these extended service microcode updates from being used by customers who have not paid for the extended service.

[0201] According to an embodiment of the present invention, a customer can purchase an extended service license from a processor manufacturer. The processor is then updated to reflect the new license, including the time period associated with the extended service. Once updated, the processor will report the extended service capabilities and the time period during which the extended service is valid.

[0202] When processor manufacturers subsequently release microcode updates, they will be securely marked as being associated with the Extended Services Capability. These Extended Services microcode updates will be prevented from being loaded onto processors that do not have the necessary license installed.

[0203] Some embodiments provide enumeration of extended service support through one or more architecture capability registers (eg, MSRs) that report the extended service support period. Some embodiments also include a new microcode update format that indicates the extended service period supported by the microcode update.

[0204] Will refer to Fig.24 Describe an embodiment, Fig.24The front-end circuit 2408 of the processor 2490 is shown, including an instruction cache 2411 for storing instructions to be executed, a fetch circuit 2412 for fetching instructions from the instruction cache 2412 and / or a cache / memory subsystem, a decoder circuit 2416 for decoding instructions, and a microcode sequencer 2402 for responsively generating a sequence of micro-operations corresponding to each decoded instruction based on the microcode ROM 2404 and the patch memory 2406.

[0205] Microcode updater 2406 implements one or more techniques described herein to update patch memory 2406 storing microcode patches. Microcode sequencer 2402 uses the microcode patches in conjunction with the original microcode stored in ROM 2404 to generate a microcode sequence for each decoded instruction. Microcode updater 2406 may be implemented in hardware, software / firmware (e.g., system firmware or software), or any combination thereof to provide new microcode updates as described herein.

[0206] Processor registers 2402 include model-specific registers (MSRs) that store (among other things) configuration, state, and control data associated with the processor. MSRs can be package-wide or core / logical processor-wide. Bits within a package-wide MSR are associated with the entire processor package, while a core or logical processor-wide MSR applies to a specific core or logical processor.

[0207] In one embodiment, microcode update (MCU) changes are enumerated by register 2402. For example, architecture capability MSR 2423 includes a plurality of bits to indicate the capabilities of the processor. In a specific embodiment, if bit

[22] is set, this indicates that processor 2490 supports extended services. MCU extended services MSR 2424 indicates the extended services available to processor 2490.

[0208] In one embodiment, the microcode updater 2406 reads the extended service MSR 2424 to determine the supported service period of the processor 2490 (i.e., based on the installed license) to determine whether to install a particular MCU 2410. For example, the microcode updater 2406 may compare the information in the extended service MSR 2424 with the information in the MCU patch header 2410A (stored in the cache 2408 or other accessible memory location) to determine whether the corresponding encrypted MCU patch content 2410B can be applied to the patch memory 2406. If the processor obtains authorization for the encrypted MCU patch content 2410B, the microcode updater 2406 may perform additional verification / security operations (e.g., verifying the hash included in the MCU patch header 2410A, decrypting the MCU patch content 2410B, etc.) before applying the MCU patch content 2410B to the patch memory 2406. In some implementations, when multiple processor steppings and / or models are supported, the MCU extended processor signature 2410C is appended to the end of the encrypted MCU patch content 2410B (e.g., in the form of an extended signature table). The MCU extended processor signature 2410C can be used in the verification process as described below.

[0209] Fig.25 The format of one embodiment of the Extended Services MSR 2424 is illustrated. As shown, in this embodiment, the Extended Services MSR 2424 is package-scoped and read-only. The four bits [3:0] indicate the allowed (one or more) extended service periods. For example, a particular value x encoded in the four bits indicates that for this processor 2490, extended services are allowed within period x.

[0210] Fig.26 Additional details of one embodiment are illustrated. The update loader 2601 (e.g., from the BIOS 2611) loads the MCU update 2410 into secure processor memory (e.g., cache 2408 or other secure memory) during system initialization. The MCU update block 2410 is initially stored in memory of the BIOS 2611 (e.g., in non-volatile memory or other structure on the motherboard) and is loaded into processor memory by the update loader 2601 during initialization.

[0211] The MCU patch authenticator 2606 uses the information in the MCU patch header 2410A and possible MCU extended signatures 2410C to perform various operations to authenticate the MCU patch 2410. In one embodiment, new fields are included in the MCU patch header 2410A to indicate whether the MCU is an extended service MCU and the period of time during which the MCU patch content 2410B is allowed to be applied. The MCU patch authenticator 2606 compares the information in the relevant parts of these new fields with the corresponding information in the processor MSR 2620 (e.g., MCU extended service MSR 2424 and platform ID MSR 2624) to determine whether the MCU 2410 should be applied to the processor. This embodiment of the MCU patch header 2410A and extended signature 2410C includes support for multiple processor signatures and platform identifiers (e.g., signatures indicating the extended family, extended model, type, series, model, and stepping of each processor to which the MCU should be applied).

[0212] Fig.27A One embodiment of an extended service allowed period (ES-AP) field 2702 for a particular supported processor signature is illustrated as a double word (32-bit) field having eight 4-bit subfields corresponding to eight processor flags (P0-P7). As used in this context, a processor "signature" includes any information that can be used to identify a processor with a desired level of specificity, such as one or more of the following: processor type, family (including extended family), model (including extended model), and / or stepping. Each supported processor signature can be associated with a separate ES-AP double word, such as Fig.27A shown.

[0213] Fig.27B The data structure 2701 included in the MCU 2410 (e.g., in the header 2410A and / or the extended signature 2410C) is illustrated. The data structure 2710 includes a sequence of double word entries, including entries ESAP_1 to ESAP_N, each of which corresponds to a different supported processor signature and includes a set of ES-AP bits, such as Fig.27A The first entry ESAP_0 is used as the main header signature, and the second entry ESAP_EXT_NUM indicates the number (N) of ESAP entries (ESAP_1 to ESAP_N) of the processor signature.

[0214] Encoding each ES-AP field 2702 associates a group of four bits with each of eight processor flags (P0 through P7), which eight processor flags correspond to different platform IDs. Each group of four bits indicates the allowed period for each corresponding platform ID. Thus, in addition to verifying the processor signature, the MCU patch authenticator 2606 also determines the expected processor platform type to properly verify and align the microcode update 2410. In one embodiment, the MCU patch authenticator 2606 determines the processor platform type by reading three platform ID bits from the IA32_PLATFORM_ID register 2624 (e.g., reading bits [52:50] using the Read Model Specific Register (RDMSR) instruction). These three bits, when read in the form of a binary coded decimal (BCD) number, indicate the bit positions of the 4-bit values in the corresponding ES-AP doubleword 2702.

[0215] In summary, one embodiment of the MCU patch authenticator 2606 verifies that the processor signature matches the MCU processor signature. It may also save an index of the processor signature in the MCU 2410 (e.g., for matching at the extended signature block 2410C). The MCU patch authenticator 2606 then reads the platform identification information from the platform ID MSR 2624 to identify the processor flags corresponding to the matched processor signature. It checks the ES-AP field corresponding to the matched processor signature and the matched platform identification, reads the corresponding 4-bit value, and compares it with the value in the MCU extended service MSR 2424 to verify that the MCU 2410 can be applied to the processor. In one embodiment, if MCU.ESAP (the 4-bit value read from the ES-AP field) = <IA32_MCU_EXT_SERVICE[ALLOWED_PERIOD]>, then the MCU 2410 can be applied. Once verified, an MCU with a revision ID higher than any existing MCU patch stored in the patch memory 2406 can be applied.

[0216] As Fig.26 shown, one or more additional verifications 2607 may be performed after MCU authentication. For example, after verification by the MCU patch authenticator 2606, the processor hardware may also verify that an MCU specified for an extended service period is not loaded if the processor does not support the extended service period. In one embodiment, additional fields are included in the uCode internal header to be checked by the processor hardware after authentication by the MCU patch authenticator 2606.

[0217] If the additional verification 2607 verifies the update, then the decryption and update logic 2608 in response installs the new MCU patch 2410 in the patch memory 2406. If the process is successful, WRMSR 79H (MCU load flow) succeeds; otherwise, it fails silently.

[0218] For processors that support the IA32_MCU_STATUS MSR (IA32_ARCH_CAPABILITY

[16] ), a new bit (#2) is used to report any such failures. Fig.28 As shown in , if the MCU extended service period is greater than the processor's extended service period (as reported in the MCU_EXT_SERVICE MSR), bit [2] is set to indicate the cause of the failure.

[0219] exist Fig.29 A method according to an embodiment of the present invention is illustrated in FIG. The method can be implemented on various architectures described above, but is not limited to any specific processor or system architecture.

[0220] At 2901, a microcode update (MCU) block is stored in a BIOS memory, such as a flash memory or other non-volatile BIOS memory. At 2902, during system initialization, the MCU is copied to a designated secure processor memory (eg, cache or other local memory).

[0221] If it is determined at 2903 that the MCU is not an extended service MCU, then at 2904, operations are performed to verify and apply the MCU (e.g., as described in reference Figure 1-Figure 12 As described above). If the MCU is an extended service MCU, then at 2905, the processor signature data, the platform ID, and the extended service data are read from the processor (e.g., from a specified processor MSR). At 2906, the relevant extended service data field is identified based on the processor signature data and the platform ID. For example, in one embodiment, a specific group of 4-bit data fields are identified using the processor signature, and a specific 4-bit data field is identified from the group based on the platform ID. In this embodiment, the 4-bit data field indicates the extended service period associated with the MCU.

[0222] At 2907, a determination is made whether to apply the MCU based on a comparison of the MCU Extended Service Data field and the Extended Service Data from the processor (e.g., read from the Extended Service MSR). If the extended service period indicated by the 4-bit Extended Service Data field is later than the Extended Service Data from the processor, then at 2909, the update request is silently failed. The status bits are also updated to reflect the failure.

[0223] If the extended service period indicated by the MCU extended service data field is less than or equal to the extended service period indicated by the processor (e.g., MCU.ESAP = <IA32_MCU_EXT_SERVICE[ALLOWED_PERIOD]), then the MCU is applied to the processor. In 2910, the MCU is decrypted and the patch memory of the microsequencer is updated (as described above).

[0224] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor, such as a general-purpose computing device, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor (e.g., a system-on-a-chip or SoC).

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

[0226] Embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention can be implemented as a computer program or program code executed on a programmable system including 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.

[0227] Examples

[0228] The following are example implementations of different embodiments of the present invention.

[0229] Example 1. A method, comprising: loading an extended service microcode update (MCU) into a memory of a processor; reading processor identification data and processor extended service data from one or more registers of the processor; identifying an MCU extended service value in the MCU based on the processor identification data; and determining whether to apply the extended service MCU to the processor based on a comparison between the MCU extended service value and the processor extended service data.

[0230] Example 2. The method of Example 1, wherein the processor identification data includes processor signature data and platform identification data.

[0231] Example 3. The method of Example 1 or 2, wherein identifying the MCU extended service value comprises: identifying an entry in an MCU data structure corresponding to the processor signature data; and identifying a field within the entry based on the platform identification data, the field encoding the MCU extended service value.

[0232] Example 4. A method as described in any one of Examples 1-3, wherein the platform identification data includes N bits read from a processor register, wherein the identification field includes using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

[0233] Example 5. The method of any of Examples 1-4, wherein the processor signature data includes data indicating one or more of: extended family, extended model, type, family, model, and stepping.

[0234] Example 6. The method of any one of Examples 1-5, wherein if the MCU extended service value is less than or equal to a value of the processor extended service data, the extended service MCU is applied to the processor.

[0235] Example 7. The method of any one of Examples 1-6, wherein the extended service MCU is applied to the processor by writing to a microcode patch memory of a microsequencer of the processor.

[0236] Example 8. The method of any one of Examples 1-7, wherein the value of the processor extended service data comprises an M-bit value read from a processor register, and the MCU extended service value comprises an M-bit value read from a header of the MCU.

[0237] Example 9. The method of any one of Examples 1 to 8, wherein, in response to purchasing an extension license for the processor, the processor extension service data is updated to include an update value, and the update value is compared with the MCU extension service value in a subsequent attempt to apply the MCU to the processor.

[0238] Example 10. A processor comprising: a memory for storing an extended service microcode update (MCU); one or more registers for storing processor identification data and processor extended service data; and an execution circuit for executing instructions to: read an MCU extended service value from the MCU, the MCU extended service value being identified based on the processor identification data; and determine whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service value and the processor extended service data.

[0239] Example 11. The processor of Example 10, wherein the processor identification data comprises processor signature data and platform identification data.

[0240] Example 12. The processor of Example 10 or 11, wherein identifying the MCU extended service value comprises: identifying an entry in an MCU data structure corresponding to the processor signature data; and identifying a field within the entry based on the platform identification data, the field encoding the MCU extended service value.

[0241] Example 13. A processor as described in any of Examples 10-12, wherein the platform identification data includes N bits read from a processor register, wherein the identification field includes using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

[0242] Example 14. The processor of any of Examples 10-13, wherein the processor signature data includes data indicating one or more of: extended family, extended model, type, family, model, and stepping.

[0243] Example 15. The processor of any one of Examples 10-14, wherein if the MCU extended service value is less than or equal to a value of the processor extended service data, the extended service MCU is applied to the processor.

[0244] Example 16. The processor of any one of Examples 10-15, wherein the extended service MCU is applied to the processor by writing to a microcode patch memory of a microsequencer of the processor.

[0245] Example 17. A machine-readable medium storing code that, when executed by a processor, causes the processor to perform a method comprising: storing an extended service microcode update (MCU) in a memory; reading processor identification data and processor extended service data from one or more registers of the processor; identifying an MCU extended service value for the MCU based on the processor identification data; and determining whether to apply the extended service MCU on the processor based on a comparison between the MCU extended service value and the processor extended service data.

[0246] Example 18. The machine-readable medium of Example 17, wherein the processor identification data comprises processor signature data and platform identification data.

[0247] Example 19. The machine-readable medium of any of Examples 17-18, wherein identifying the MCU extended service value comprises: identifying an entry in an MCU data structure corresponding to the processor signature data; and identifying a field within the entry based on the platform identification data, the field encoding the MCU extended service value.

[0248] Example 20. The machine-readable medium of any of Examples 17-19, wherein the platform identification data comprises N bits read from a processor register, wherein the identification field comprises using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

[0249] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into fabrication machines that actually fabricate the logic or processor.

[0250] Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of an article manufactured or formed by a machine or device, including storage media such as a hard disk, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), 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 medium suitable for storing electronic instructions.

[0251] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description language (HDL), that define the features of the structures, circuits, devices, processors and / or systems described herein. Such embodiments may also be referred to as program products.

Claims

1. A method comprising: Loading an extended services microcode update (MCU) into the processor's memory; reading processor identification data and processor extended service data from one or more registers of the processor; identifying an MCU extended service value in the MCU based on the processor identification data; and Based on the comparison between the MCU extended service value and the processor extended service data, it is determined whether to apply the extended service MCU on the processor.

2. The method of claim 1, wherein: The processor identification data includes processor signature data and platform identification data.

3. The method of claim 2, wherein: Identifying the MCU extended service value includes: identifying an entry in an MCU data structure corresponding to the processor signature data; and A field within the entry is identified based on the platform identification data, the field encoding the MCU extended service value.

4. The method of claim 3, wherein: The platform identification data includes N bits read from a processor register, wherein the identification field includes using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

5. The method according to any one of claims 2 to 4, wherein: The processor signature data includes data indicating one or more of: extended family, extended model, type, family, model, and stepping.

6. The method according to any one of claims 1 to 5, wherein: If the MCU extended service value is less than or equal to the value of the processor extended service data, the extended service MCU is applied to the processor.

7. The method of claim 6, wherein: The extended service MCU is applied to the processor by being written into a microcode patch memory of a microsequencer of the processor.

8. The method according to any one of claims 1 to 7, wherein: The value of the processor extended service data includes an M-bit value read from a processor register, and the MCU extended service value includes an M-bit value read from a header of the MCU.

9. The method according to any one of claims 1 to 8, wherein: In response to purchasing an extended license for the processor, the processor extended service data will be updated to include an updated value, and the updated value is compared with the MCU extended service value in a subsequent attempt to apply the MCU to the processor.

10. A processor, comprising: Memory for storing extended service microcode updates (MCU); One or more registers for storing processor identification data and processor extended service data; Execution circuitry, used to execute instructions to: reading an MCU extended service value from the MCU, the MCU extended service value being identified based on the processor identification data; and Based on the comparison between the MCU extended service value and the processor extended service data, it is determined whether to apply the extended service MCU on the processor.

11. The processor of claim 10, wherein: The processor identification data includes processor signature data and platform identification data.

12. The processor of claim 11, wherein: Identifying the MCU extended service value includes: identifying an entry in an MCU data structure corresponding to the processor signature data; and A field within the entry is identified based on the platform identification data, the field encoding the MCU extended service value.

13. The processor of claim 12, wherein: The platform identification data includes N bits read from a processor register, wherein the identification field includes using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

14. A processor according to any one of claims 11 to 13, wherein: The processor signature data includes data indicating one or more of: extended family, extended model, type, family, model, and stepping.

15. The processor of claim 10, wherein: If the MCU extended service value is less than or equal to the value of the processor extended service data, the extended service MCU is applied to the processor.

16. The processor of claim 15, wherein: The extended service MCU is applied to the processor by being written into a microcode patch memory of a microsequencer of the processor.

17. A machine-readable medium storing code, which, when executed by a processor, causes the processor to perform a method comprising: storing an extended services microcode update (MCU) in a memory; reading processor identification data and processor extended service data from one or more registers of the processor; Identifying an MCU extended service value of the MCU based on the processor identification data; and Based on the comparison between the MCU extended service value and the processor extended service data, it is determined whether to apply the extended service MCU on the processor.

18. The machine-readable medium of claim 17, wherein: The processor identification data includes processor signature data and platform identification data.

19. The machine-readable medium of claim 18, wherein: Identifying the MCU extended service value includes: identifying an entry in an MCU data structure corresponding to the processor signature data; and A field within the entry is identified based on the platform identification data, the field encoding the MCU extended service value.

20. The machine-readable medium of claim 19, wherein: The platform identification data includes N bits read from a processor register, wherein the identification field includes using the N bits to identify 2 N A processor flag of one of a plurality of processor flags, the processor flag being associated with the field.

Images