Apparatus and method for secure resource allocation

Abstract

The invention relates to an apparatus and method for secure resource allocation. The processor includes: a plurality of cores, each of the plurality of cores to provide at least one logical processor of the plurality of logical processors; a first plurality of registers, each register of the first plurality of registers to associate a service class (CLOS) value with a corresponding logical processor of the plurality of logical processors; a second plurality of registers, each register in the second plurality of registers to indicate a portion of the shared resource to be allocated to a corresponding CLOS value; a first control register of a first logical processor of the plurality of logical processors configured with a reserved CLOS value associated with the trusted control structure; a resource reservation circuit configurable by the secure firmware or software to indicate a reserved portion of the shared resource associated with the reserved CLOS value; and implementation circuitry to restrict access to the reserved portion of the shared resource to a thread or logical processor associated with the reserved CLOS value.

Description

Technical Field

[0001] The present invention relates generally to the field of computer processors. More particularly, the present invention relates to apparatus and methods for secure resource allocation. Background Art

[0002] The instruction set or instruction set architecture (ISA) is the part of the computer architecture that involves programming, including 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" in this article generally refers to macroinstructions, that is, instructions provided to the processor for execution, rather than microinstructions or microoperations, that is, the microinstructions or microoperations are the result of the processor's decoder decoding the macroinstructions. Microinstructions or microoperations can be configured to instruct the execution unit on the processor to perform operations to implement the logic associated with the macroinstructions.

[0003] ISA is different from microarchitecture, which is a collection of processor design techniques used to implement an instruction set. Processors with different microarchitectures can share a common instruction set. For example, Pentium 4 processor, Core TM (Core TM) processors, and processors from Advanced Micro Devices, Inc. of Sunnyvale, California, implement almost the same version of the x86 instruction set (with some extensions added with updated versions), but have different internal designs. For example, the same register architecture of the ISA can be implemented in different ways in different microarchitectures using well-known techniques, including dedicated physical registers, one or more dynamically allocated physical registers using a register renaming mechanism (e.g., using a register alias table (RAT), a reorder buffer (ROB), and a retirement register file). Unless otherwise specified, the phrases "register architecture", "register file", and "register" are used herein to refer to register architectures, register files, and registers that are visible to software / programmers and to the way instructions specify registers. Where a distinction is needed, the adjectives "logical", "architectural", or "software visible" will be used to indicate registers / register files in a register architecture, while different adjectives will be used to specify registers (e.g., physical registers, reorder buffers, retirement registers, register pools) in a given microarchitecture. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0006] Figure 1 illustrates an example computer system architecture;

[0007] Figure 2 The diagram shows a processor including multiple cores;

[0008] FIG3(A) illustrates the various stages of a processing pipeline;

[0009] FIG3(B) illustrates details of one embodiment of a core;

[0010] Figure 4 FIG. 1 illustrates an execution circuit according to an embodiment;

[0011] Figure 5 One embodiment of a graphical register architecture is shown;

[0012] Figure 6 An example of the illustrated instruction format;

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

[0014] Figure 8 An embodiment of an instruction prefix is ​​shown;

[0015] Figure 9(A)-Figure 9(D) An embodiment illustrating how the R, X, and B fields of a prefix are used;

[0016] Figure 10(A)-Figure 10(B) An example of a second instruction prefix is ​​shown;

[0017] Fig.11 illustrates the payload bytes of one embodiment of an instruction prefix;

[0018] Fig.12 Diagram the implementation of instruction conversion and binary translation;

[0019] Fig.13 illustrates a set of example path masks corresponding to a set of class of service (CLOS) values;

[0020] Fig.14 illustrates one embodiment of an architecture for securely performing cache reservations;

[0021] Fig.15 illustrates an embodiment in which duplicate cache lines are included in both reserved cache areas and non-reserved cache areas;

[0022] Fig.16 illustrates a way mask with reserved mask bits according to an embodiment of the present invention; and

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

[0024] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention described below. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention.

[0025] Exemplary Computer Architecture

[0026] Exemplary computer architectures are described in detail below. Other system designs and configurations for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and a large number of various other electronic devices known in the art are also appropriate. In a word, various systems or electronic devices that can include processors disclosed herein and / or other execution logics are generally appropriate.

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

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

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

[0030] A shared cache (not shown) may be included in either processor 170, 180, or external to both processors but connected to these processors via the PP interconnect, so that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0031] Chipset 190 may be coupled to first interconnect 116 via interface 196. In some embodiments, first interconnect 116 may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some embodiments, one of these interconnects is coupled to a power control unit (PCU) 117, which may include circuitry, software, and / or firmware to perform power management operations with respect to processors 170, 180, and / or coprocessor 138. PCU 117 provides control information to the voltage regulator so that the voltage regulator generates an appropriate regulated voltage. PCU 117 also provides control information to control the generated operating voltage. In various embodiments, PCU 117 may include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

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

[0033] Various I / O devices 114 and an interconnect (bus) bridge 118 may be coupled to the first interconnect 116, and the interconnect (bus) bridge 118 couples the first interconnect 116 to the second interconnect 120. In some embodiments, one or more additional processors 115 are coupled to the first interconnect 116, such as a coprocessor, a high throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some embodiments, the second interconnect 120 may be a low pin count (LPC) interconnect. Various devices may be coupled to the second interconnect 120, including, for example, a keyboard and / or mouse 122, a communication device 127, and a storage unit circuit 128. The storage unit circuit 128 may be a disk drive or other mass storage device, which may include instructions / code and data 130 in some embodiments. In addition, an audio I / O 124 may be coupled to the second interconnect 120. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 100 may implement a multi-drop interconnect or other such architecture rather than a point-to-point architecture.

[0034] Exemplary Core Architectures, Processors, and Computer Architectures

[0035] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores, for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores, for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU, including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor, including one or more special-purpose cores mainly for graphics and / or scientific (throughput) purposes. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip, which may include the above-described coprocessors and additional functionality on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s). An exemplary core architecture is described next, followed by a description of exemplary processor and computer architectures.

[0036] Figure 2 A block diagram of an embodiment of an example processor 200 is illustrated, which may have more than one core, may have an integrated memory controller, and may have an integrated graphics device. The solid-lined box illustrates the processor 200 as having a single core 202(A), a system agent 210, and a set of one or more interconnected controller unit circuits 216, while the optionally added dashed-lined box illustrates an alternative processor 200 as having multiple cores 202(A)-(N), a set of one or more integrated memory control unit circuits 214 in the system agent unit circuit 210, dedicated logic 208, and a set of one or more interconnected controller unit circuits 216. Note that the processor 200 may be Figure 1 One of the processors 170 or 180 or the coprocessors 138 or 115.

[0037] Thus, different implementations of processor 200 may include: 1) a CPU, where dedicated logic 208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 202(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 202(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 202(A)-(N) are a large number of general purpose in-order cores. Thus, processor 200 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit circuit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, and the like. The processor may be implemented on one or more chips. Processor 200 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of process technologies, such as BiCMOS, CMOS, or NMOS.

[0038] The memory hierarchy includes one or more levels of cache unit circuitry 204(A)-(N) within the cores 202(A)-(N), a set of one or more shared cache unit circuitry 206, and external memory (not shown) coupled to the set of integrated memory controller unit circuitry 214. The set of one or more shared cache unit circuitry 206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other level caches, such as last level cache (LLC), and / or combinations thereof. While in some embodiments a ring-based interconnect network circuitry 212 interconnects the dedicated logic 208 (e.g., integrated graphics logic), the set of shared cache unit circuitry 206, and the system agent unit circuitry 210, alternative embodiments interconnect these units using any number of well-known techniques. In some embodiments, coherency is maintained between one or more circuits in the shared cache unit circuitry 206 and the cores 202(A)-(N).

[0039] In some embodiments, one or more of the cores 202(A)-(N) have multi-threading capabilities. The system agent unit circuit 210 includes those components that coordinate and operate the cores 202(A)-(N). The system agent unit circuit 210 may include, for example, a power control unit (PCU) circuit and / or a display unit circuit (not shown). The PCU may be (or may include) the logic and components required to adjust the power state of the cores 202(A)-(N) and / or the dedicated logic 208 (e.g., integrated graphics logic). The display unit circuit is used to drive one or more externally connected displays.

[0040] The cores 202(A)-(N) may be homogeneous or heterogeneous with respect to the architectural instruction set; that is, two or more of the cores 202(A)-(N) may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of the instruction set or may be capable of executing a different ISA.

[0041] Exemplary Core Architecture

[0042] In-order and out-of-order core block diagram

[0043] The block diagram of FIG. 3(A) illustrates both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to an embodiment of the present invention. The block diagram of FIG. 3(B) illustrates both an exemplary embodiment of an in-order architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core according to an embodiment of the present invention. The solid-line boxes in FIG. 3(A)-(B) illustrate the in-order pipeline and the 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.

[0044] In FIG. 3(A), the processor pipeline 300 includes a fetch stage 302, an optional length decode stage 304, a decode stage 306, an optional allocation stage 308, an optional rename stage 310, a dispatch (also called dispatch or issue) stage 312, an optional register read / memory read stage 314, an execute stage 316, a write back / memory write stage 318, an optional exception handling stage 322, and an optional commit stage 324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 302, one or more instructions are fetched from the instruction memory, during the decode stage 306, 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 one embodiment, the decode stage 306 and the register read / memory read stage 314 may be combined into one pipeline stage. In one embodiment, during the execution stage 316, decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0045] As an example, the exemplary register renaming, out-of-order issue / execution core architecture may implement the pipeline 300 in the following manner: 1) instruction fetch 338 performs fetch and length decode stages 302 and 304; 2) decode unit circuit 340 performs decode stage 306; 3) rename / allocator unit circuit 352 performs allocation stage 308 and rename stage 310; 4) (one or more) scheduler unit circuit 356 performs scheduling stage 312; 5) (one or more) physical register file unit circuit 358 and memory unit circuit 370 perform register read / memory read stage 314; execution cluster 360 performs execution stage 316; 6) memory unit circuit 370 and (one or more) physical register file unit circuit 358 perform write back / memory write stage 318; 7) various units (unit circuits) may be involved in the exception handling stage 322; and 8) retirement unit circuit 354 and (one or more) physical register file unit circuit 358 perform commit stage 324.

[0046] 3(B) shows that the processor core 390 includes a front end unit circuit 330 coupled to an execution engine unit circuit 350, and both are coupled to a memory unit circuit 370. The core 390 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 390 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.

[0047] The front end unit circuit 330 may include a branch prediction unit circuit 332, which is coupled to an instruction cache unit circuit 334, which is coupled to an instruction translation lookaside buffer (TLB) 336, which is coupled to an instruction fetch unit circuit 338, which is coupled to a decode unit circuit 340. In one embodiment, the instruction cache unit circuit 334 is included in the memory unit circuit 370 instead of the front end unit circuit 330. The decode unit circuit 340 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, 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 unit circuit 340 may also include an address generation unit (AGU, not shown). In one embodiment, 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 unit circuit 340 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 one embodiment, the core 390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode unit circuit 340 or otherwise within the front end unit circuit 330). In one embodiment, the decode unit circuit 340 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during the decode or other stages of the processor pipeline 300. The decode unit circuit 340 may be coupled to the rename / allocator unit circuit 352 in the execution engine unit circuit 350.

[0048] The execution engine circuitry 350 includes a rename / allocator unit circuitry 352 coupled to a retirement unit circuitry 354 and a set of one or more scheduler circuits 356. The scheduler circuitry 356 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some embodiments, the scheduler circuitry 356 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 circuitry 356 is coupled to a physical register file(s) circuitry 358. Each of the physical register file(s) circuitry 358 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., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In one embodiment, the physical register file unit circuitry 358 includes vector register unit circuitry, write mask register unit circuitry, and scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general purpose registers, and the like. The physical register file unit circuitry 358 is overlapped by a retirement unit circuitry 354 (also referred to as a retirement queue) to demonstrate various ways in which register renaming and out-of-order execution may be implemented (e.g., utilizing reorder buffers (ROBs) and retirement register files (ROBs); utilizing future stacks (ROBs), history buffers (ROBs), and retirement register files (ROBs); utilizing register maps and register pools; and the like). The retirement unit circuitry 354 and the physical register file circuitry 358 are coupled to execution clusters (one or more) 360. The execution clusters (one or more) 360 include a set of one or more execution unit circuits 362 and a set of one or more memory access circuits 364. Execution unit circuitry 362 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 floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other embodiments may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 356, physical register file unit circuit(s) 358, and execution cluster(s) 360 are shown as potentially multiple because some embodiments 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 unit circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, some embodiments implemented only the execution cluster of that pipeline has memory access unit circuit(s) 364). 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.

[0049] In some embodiments, the execution engine unit circuit 350 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.

[0050] A set of memory access circuits 364 are coupled to the memory cell circuit 370, which includes a data TLB unit circuit 372, which is coupled to a data cache circuit 374, which is coupled to a level 2 (L2) cache circuit 376. In an exemplary embodiment, the memory access unit circuit 364 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 372 in the memory cell circuit 370. The instruction cache circuit 334 is further coupled to the level 2 (L2) cache unit circuit 376 in the memory cell circuit 370. In one embodiment, the instruction cache 334 and the data cache 374 are combined into a single instruction and data cache in the L2 cache unit circuit 376, a level 3 (L3) cache unit circuit (not shown), and / or a main memory (not shown). The L2 cache unit circuit 376 is coupled to one or more other levels of cache and ultimately coupled to the main memory.

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

[0052] Exemplary Execution Unit Circuits

[0053] Figure 4 An embodiment of (one or more) execution unit circuits is illustrated, such as (one or more) execution unit circuits 362 of FIG. 3(B). As shown, (one or more) execution unit circuits 362 may include one or more ALU circuits 401, vector / SIMD unit circuits 403, load / store unit circuits 405, and / or branch / jump unit circuits 407. ALU circuits 401 perform integer arithmetic and / or Boolean operations. Vector / SIMD unit circuits 403 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store unit circuits 405 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store unit circuits 405 may also generate addresses. Branch / jump unit circuits 407 cause branches or jumps to a certain memory address depending on the instruction. Floating-point unit (FPU) circuits 409 perform floating-point arithmetic. The width of execution unit circuitry 362 varies depending on the embodiment and may range from 16 bits to 1024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0054] Exemplary Register Architecture

[0055] Figure 5 5 is a block diagram of a register architecture 500 according to some embodiments. As shown, there is a vector / SIMD register 510, whose width varies from 128 bits to 1024 bits. In some embodiments, the vector / SIMD register 510 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some embodiments, the vector / SIMD register 510 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 embodiments, 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 embodiment.

[0056] In some embodiments, the register architecture 500 includes write mask / predicate registers 515. For example, in some embodiments, 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 registers 515 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 embodiments, each data element position in a given write mask / predicate register 515 corresponds to a data element position in the destination. In other embodiments, the write mask / predicate registers 515 are scalable and consist of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

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

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

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

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

[0061] Machine-specific registers (MSRs) 535 control and report processor performance. Most MSRs 535 handle system-related functions and are not accessible to applications. Machine check registers 560 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0062] One or more instruction pointer registers 530 store instruction pointer values. Control register(s) 555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processor 170, 180, 138, 115, and / or 200) and the characteristics of the task currently being executed. Debug registers 550 control and allow monitoring of debug operations of a processor or core.

[0063] Memory management registers 565 specify the location of data structures used in protected mode memory management. These registers may include the GDTR, IDTR, task register, and LDTR registers.

[0064] Alternative embodiments of the present invention may use wider or narrower registers. In addition, alternative embodiments of the present invention may use more, fewer or different register files and registers.

[0065] Instruction Set

[0066] 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, an exemplary ADD instruction has a specific opcode and instruction format, which includes 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 the instruction stream will have specific content in the operand field to select the specific operand.

[0067] Example instruction format

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

[0069] Figure 6 An embodiment of an instruction format is illustrated. As shown, an instruction may include multiple components, including but not limited to one or more fields for the following items: one or more prefixes 601, opcode 603, addressing information 605 (e.g., register identifier, memory addressing information, etc.), displacement value 607, and / or immediate value 609. Note that some instructions utilize some or all fields of the format, while other instructions may only use the opcode 603 field. In some embodiments, the illustrated order is the order in which these fields are to be encoded, however, it should be understood that in other embodiments, these fields may be encoded in another order, combined, etc.

[0070] (One or more) prefix fields 601 modify the instruction when used. In some embodiments, 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.

[0071] The opcode field 603 is used to at least partially define the operation to be performed when the instruction is decoded. In some embodiments, the length of the primary opcode encoded in the opcode field 603 is 1, 2 or 3 bytes. In other embodiments, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0072] The addressing field 605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Figure 7605. An embodiment of the addressing field 605 is illustrated. In this illustration, an optional MOD R / M byte 702 and an optional Scale, Index, Base (SIB) byte 704 are shown. The MOD R / M byte 702 and SIB byte 704 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that each of these fields is optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 702 includes a MOD field 742, a register field 744, and an R / M field 746.

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

[0074] Register field 744 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 index field 744 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some embodiments, register field 744 is supplemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing.

[0075] R / M field 746 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 embodiments, R / M field 746 may be combined with MOD field 742 to specify an addressing mode.

[0076] SIB byte 704 includes a scaling field 752, an index field 754, and a base address field 756 for address generation. Scaling field 752 indicates a scaling factor. Index field 754 specifies the index register to be used. In some embodiments, index field 754 is complemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. Base address field 756 specifies the base address register to be used. In some embodiments, base address field 756 is complemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. In practice, the contents of scaling field 752 allow the contents of index field 754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0077] Some addressing forms use displacement values ​​to generate memory addresses. For example,缩放 * index + base + displacement, index * scaling + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. to generate a memory address. The displacement can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some embodiments, the displacement field 607 provides this value. In addition, in some embodiments, the use of a displacement factor is encoded in the MOD field of the addressing field 605, which indicates a compressed displacement scheme, for which the displacement value is calculated by multiplying disp8 with a scaling factor N determined based on the vector length, the value of the b bit, and the input element size of the instruction. The displacement value is stored in the displacement field 607.

[0078] In some embodiments, the immediate value field 609 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, etc.

[0079] Figure 8 An embodiment of a first prefix 601(A) is illustrated. In some embodiments, the first prefix 601(A) is an embodiment of a REX prefix. Instructions using this prefix may specify general purpose 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).

[0080] Instructions using the first prefix 601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 744 and the R / M field 746 of the MOD R / M byte 702; 2) using the MOD R / M byte 702 with the SIB byte 704, including using the reg field 744 as well as the base field 756 and the index field 754; or 3) using the register field of the opcode.

[0081] In the first prefix 601 (A), bit positions 7:4 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.

[0082] Note that adding another bit allows for 16 (2 4 ) registers, while the separate MOD R / M reg field 744 and the R / M field 746 of MOD R / M can only address 8 registers each.

[0083] In the first prefix 601(A), bit position 2 (R) may be an extension of the MOD R / M reg field 744 and may be used to modify the MOD R / M reg field 744 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 702 specifies other registers or defines an extended opcode, R is ignored.

[0084] Bit position 1 (X) X bits may modify the SIB byte index field 754 .

[0085] Bit position B (B) B may modify the base address in the R / M field 746 or SIB byte base address field 756 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 525).

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

[0087] Figure 10(A)-Figure 10(B) An embodiment of a second prefix 601(B) is illustrated. In some embodiments, the second prefix 601(B) is an embodiment of a VEX prefix. The second prefix 601(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD registers 510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 601(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 601(B) enables the operands to perform non-destructive operations, such as A=B+C.

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

[0089] Figure 10 (A) illustrates an embodiment of the two-byte form of the second prefix 601 (B). In one example, the format field 1001 (byte 0 1003) contains the value C5H. In one example, byte 1 1005 includes an "R" value in bit [7]. This value is the complement of the same value of the first prefix 601 (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 and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0090] Instructions using this prefix may use the R / M field 746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0091] Instructions using this prefix may use the reg field 744 of MOD R / M to encode either a destination register operand or a source register operand, treated as an opcode extension and not used to encode any instruction operand.

[0092] For instruction syntax supporting four operands, vvvv, the R / M field 746 of MOD R / M, and the reg field 744 of MOD R / M encode three of the four operands. Bits [7:4] of the immediate 609 are then used to encode the third source register operand.

[0093] FIG. 10 (B) illustrates an embodiment of a three-byte form of the second prefix 601 (B). In one example, the format field 1011 (byte 0 1013) contains the value C4H. Byte 1 1015 includes "R", "X" and "B" in bit [7:5], which are the complements of these values ​​of the first prefix 601 (A). Bit [4:0] (shown as mmmm) of byte 1 1015 includes the content of encoding one or more implicit leading opcode bytes as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means 0F3AH leading opcode, and so on.

[0094] The use of bit [7] of byte 2 1017 is similar to W of the first prefix 601 (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.

[0095] Instructions using this prefix may use the R / M field 746 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0096] Instructions using this prefix may use the reg field 744 of MOD R / M 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.

[0097] For instruction syntax supporting four operands, vvvv, the R / M field 746 of MOD R / M, and the reg field 744 of MOD R / M encode three of the four operands. Bits [7:4] of the immediate 609 are then used to encode the third source register operand.

[0098] Fig.11An embodiment of a third prefix 601(C) is illustrated. In some embodiments, the third prefix 601(C) is an embodiment of an EVEX prefix. The third prefix 601(C) is a four-byte prefix.

[0099] The third prefix 601 (C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some embodiments, write masks / operation masks are used (see the discussion of registers in previous figures, e.g., Figure 5 ) 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 601 (B).

[0100] The third prefix 601(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.).

[0101] The first byte of the third prefix 601 (C) is the format field 1111, which in one example has a value of 62 H. The subsequent bytes are referred to as payload bytes 1115-1119, 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).

[0102] In some embodiments, P[1:0] of payload byte 1119 is the same as the two lower mm bits. In some embodiments, 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 744 of MOD R / M. P[6] can also provide access to the upper 16 vector registers when SIB type addressing is not required. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 744 and the R / M field 746 of MOD R / M, 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 embodiments. 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.

[0103] P

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

[0104] P[18:16] specifies the index of a register in the operation mask (write mask) register (e.g., write mask / predicate register 515). In one embodiment of the invention, the 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 another embodiment, the old value of each element of the destination is retained (if the corresponding mask bit has a value of 0). 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 one embodiment, 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 (i.e., the span of elements modified, from first to last) of the operation being performed; however, the elements modified do not have to be contiguous. Thus, the operation mask field enables a subset of vector operations, including loads, stores, arithmetic, logical, etc. Although in the described embodiment of the invention, the contents of the operation mask field select 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 embodiments alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0105] 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).

[0106] The following table details an exemplary embodiment of the encoding of registers in instructions using the third prefix 601 (C). Table 1: 32-register support in 64-bit mode Table 2: Encoding register specifiers in 32-bit mode Table 3: Operation Mask Register Specifier Encoding

[0107] 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 present application, a processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0108] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0109] The embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation approaches. Embodiments of the present invention may 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.

[0110] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represent various logic within a processor, which, when read by a machine, causes the machine to fabricate logic for performing the techniques described herein. These 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 a fabrication machine that actually fabricates the logic or processor.

[0111] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by a machine or device, including storage media such as: hard disks, 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 (e.g., 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 cards or optical cards, or any other type of medium suitable for storing electronic instructions.

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

[0113] Emulation (including binary translation, code deformation, etc.)

[0114] In some cases, the instruction converter can be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0115] Fig.12A block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to some implementations. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Fig.12 A program in a high-level language 1202 is shown to be compiled using a first ISA compiler 1204 to generate first ISA binary code 1206 that can be natively executed by a processor 1216 having at least one first ISA instruction set core. The processor 1216 having at least one first ISA instruction set core represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the instruction set of the first ISA instruction set core or (2) executing a program in a first ISA instruction set core in a manner compatible with or otherwise processing the instruction set of the processor. The first ISA compiler 1204 represents a compiler operable to generate first ISA binary code 1206 (e.g., object code) that can be executed on a processor 1216 having at least one first ISA instruction set core with or without additional linking processing.

[0116] Similarly, Fig.12 It is shown that a program in a high-level language 1202 can be compiled using an alternative instruction set compiler 1208 to generate an alternative instruction set binary code 1210, which can be executed natively by a processor 1214 without a first ISA core. An instruction converter 1212 is used to convert the first ISA binary code 1206 into code that can be executed natively by a processor 1214 without a first ISA instruction set core. This converted code may not be the same as the alternative instruction set binary code 1210, because an instruction converter that can do this is difficult to make; however, the converted code will implement the overall operation and be composed of instructions from the alternative instruction set. Thus, the instruction converter 1212 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device that does not have a first ISA instruction set processor or core to execute the first ISA binary code 1206 through simulation, emulation, or any other process. Apparatus and method for secure resource allocation

[0117] Trust Domain Extension (TDX) is a technology that extends Virtual Machines Extension (VMX) and facilitates the deployment of hardware-isolated virtual machines (VMs) called trust domains (TDs). TDX is designed to protect the confidentiality of the memory contents and CPU state of each TD stored in TD private pages from any other software (including the controlling virtual-machine manager (VMM) / hypervisor) unless the TD itself is explicitly shared (i.e., via TD shared pages). TDX is built using a combination of Virtual Machine Extension (VMX) and Multi-Key Total Memory Encryption (MKTME), utilizing a verified software module (TDX module) to implement the TDX architecture. TD and TDX modules run in SEAM (Secure Arbitration Mode) non-root mode and root mode, respectively.

[0118] To achieve TD isolation, TDX relies on a series of memory protection mechanisms to prevent unauthorized access to TD private pages. TDX also implements various mitigations to prevent indirect leakage of TD private data via side-channel attacks. Side-channel attacks enable attackers in one trust domain to indirectly infer sensitive data processed by another isolated trust domain using byproduct information such as timing and power-related information (traditional side-channel attacks) even without direct access to the data. It also enables attackers to read arbitrary memory locations of the program via new transient execution attacks. TDX's enhancements to side-channel attacks include mitigations for transient execution attacks such as Spectre, Meltdown, and Microarchitecture Data Sampling (MDS) attacks, mitigations for branch prediction side-channel attacks, and mitigations for single-step and zero-step attacks. One class of side-channel attacks that TDX currently cannot address is cache-based side-channel attacks.

[0119] Cache side channel attacks are one of the most widely studied side channel attacks, which exploit the timing differences between hits and misses in the CPU cache to learn memory access patterns and further infer secret data if the memory access pattern depends on the secret data. Fundamentally, cache attacks can be categorized as follows:

[0120] Contention-based attacks: A processor's cache is a resource that is shared in space or time by all software running on the machine. When an attacker and a victim contend for the same shared resource, interference can occur, causing the attacker and victim programs to evict each other's data from the cache. Prime+Probe is a well-known attack technique that exploits cache contention: by forcing a cache set into a known state ("Prime"), the attacker can then precisely monitor the changes that the victim makes to the cache set ("Probe").

[0121] Reuse-based attacks : If the attacker and the victim share memory, for example, both use the same dynamic link library code, then the attacker can monitor the victim's access pattern to the shared memory and thus learn the victim's control flow or data flow. A Flush+Reload attack is an attack technique that exploits shared memory, in which the attacker can observe the victim's access pattern to the shared memory by first flushing ("Flush") the target cache line from the cache and then measuring the reload ("Reload") time of the cache line.

[0122] Contention-based attacks are more relevant to TDX because TD private pages are not shared with other TDs, and the sharing of TD shared pages is explicitly controlled by the TD. Currently, the guiding principle for TDX against cache side-channel attacks is that mitigation is by software, i.e., if side channels are a concern, software should follow constant-time coding principles to mitigate traditional side-channel attacks (including cache side channels). Writing constant-time code is difficult to get right, and usually only code that processes high-value assets such as cryptographic code follows constant-time coding principles. Therefore, software running inside a TD is generally not protected against cache side-channel attacks, and the data it processes may still be attacked by untrusted host VMMs and other TDs on the same platform.

[0123] Embodiments of the present invention provide protection against cache side-channel attacks for any software (including legacy software) running inside a TD. Specifically, these embodiments extend TDX with minimal hardware / architecture support, enabling software to protect itself from cache side-channel attacks without the need to refactor the software into constant-time code.

[0124] Some implementations of the present invention include architectural extensions for enhancing Cache Allocation Technology (CAT) so that cache partitions can be safely reserved for exclusive use by TDX. In these implementations, cache partitioning is performed based on cache paths and class-of-service (CLOS). Reserved partitions can only be assigned to reserved CLOS, and reserved partitions can only be assigned by reserved CLOS for TD private access.

[0125] CAT provides software programmable control over the amount of cache space a given thread, application, VM, or container can consume by using CLOS as a resource control label that can group threads / applications / VMs / containers. Since many heterogeneous types of applications run on the same machine, they share the same resources (e.g., last-level cache and memory bandwidth), ensuring consistent performance and prioritizing important interactive applications is challenging. CLOS, in turn, has an associated resource capacity bitmask (CBM) that indicates how much cache a given CLOS can use.

[0126] A way mask is a special type of CBM where each bit indicates whether the corresponding cache way is allocated. Fig.13 A set of example way masks 1300A-D for four different service classes (CLOS0-CLOS3) are illustrated. Ways are reserved for each CLOS by setting the corresponding bit 1301 in the way mask (as indicated by the dark shading). Each way mask 1300A-D is stored in a separate MSR associated with the CLOS (e.g., IA32_L3_MASK_n MSR, where n represents CLOSn). For example, each of the four way masks 1300A-D can be stored in a separate MSR associated with a given CLOS. The MSR for each logical processor (e.g., IA32_PQR_ASSOC MSR) associates the software running on that logical processor with a particular CLOS. Software can associate applications with CLOS as needed to support various usage models. For a side channel mitigation usage model, the CLOS can be configured to partition the cache using non-overlapping CBMs, and a portion of the cache can be reserved for a particular CLOS value (e.g., CLOS0 1300A via reserved way bits 1301).

[0127] Embodiments of the present invention use CAT to implement coarse-grained partitioning between TDX and non-TD software. In some embodiments, TDX can then implement software-based mitigation measures to achieve finer-grained partitioning between TDs (e.g., partitioning by cache set using page coloring), or use a partition to pin pages in the cache.

[0128] Existing CAT implementations allow any privileged software (including untrusted host VMM) to configure resource assignments. Therefore, there is no guarantee that the untrusted host VMM can correctly configure the CBM to assign an exclusive cache partition to TDX.

[0129] Embodiments of the present invention ensure that non-overlapping cache partitions are provided for the TDX's exclusive use. The threat model is the same for the TDX, where the host VMM is not trusted. In addition, in some embodiments, cache usage for TD private accesses (including accesses made by the TDX module) is isolated from TD shared accesses and accesses made by traditional VMs and the host VMM. TD private accesses are memory accesses made to TD private pages based on the value of a new shared bit in the Guest Physical Address (GPA). The TDX module can implement finer-grained partitioning (e.g., page coloring) to further isolate TD private accesses made by different TDs. The VMM is not trusted to implement isolation.

[0130] The following description focuses on allocations in the LLC or L3 cache, because the LLC is shared by all cores in a CPU package, while core-private caches (such as the L1 cache and the middle-level cache (MLC)) can only be shared by hyperthreads within a core. Therefore, the LLC is the most common target of attack. However, it should be noted that the underlying principles of the present invention are not limited to LLC cache reservations / allocations. Some embodiments of the present invention use the same techniques to allocate / reserve other types of resources, including other cache levels. Note that the terms "LLC" and "L3" cache are used interchangeably herein. A. Reservation of dedicated resources

[0131] In one implementation, the BIOS firmware or other security program code configures the reserved resources and the corresponding reserved CLOS values. For example, one option for specifying cache resources is to indicate the number of reserved ways and the corresponding reserved CLOS values. A portion of continuous ways / CLOS at the beginning / end of the total available multiple ways / CLOS can be reserved. Alternatively or additionally, a two-bit mask can be configured, one bit mask for ways and one bit mask for CLOS, so that cache resources can be reserved in fine granularity. B. Implementation of Isolation a) Implement the association between reserved resources and reserved CLOS

[0132] As about Fig.13As mentioned, by setting corresponding bits 1301 in corresponding CLOS capacity bit masks 1300A-D (referred to as "way" masks when bits are mapped to cache ways), ways and CLOS can be reserved for TDX, where each bit mask is associated with a different CLOS. The association of reserved ways is constrained so that a reserved way can only be assigned to a reserved CLOS, and each reserved CLOS can only be associated with a reserved way. In some embodiments, this is implemented when the CLOS capacity bit mask is configured and / or when the CLOS capacity bit mask is consumed.

[0133] At CBM configuration time: Since the host VMM cannot be trusted to correctly configure the capacity bit mask of each CLOS, the host VMM is denied access to the capacity bit mask of the reserved CLOS. For example, for IA32_L3_MASK_n, if n is within the reserved CLOS value range, a write to IA32_L3_MASK_n (e.g., via a WRMSR instruction) by an untrusted entity such as the VMM (e.g., in non-secure arbitration (SEAM) mode) will generate a #GP fault. Note that if the number of reserved CLOS is limited to 1, this restriction is not required. If only a coarse-grained partition is required, an untrusted VMM can configure the reserved CLOS, which is implemented at CBM consumption, so that the CBM of the reserved CLOS is restricted to the reserved way. Having multiple reserved CLOS enables TDX to further partition the reserved way, which cannot be implemented only at CBM consumption.

[0134] When CBM is consumed: Each capacity bit mask of each CLOS (e.g., stored in IA32_L3_MASK_n of CLOSn) is consumed by the L3 cache replacement algorithm. Below, CAT_reserved_partition_MASK and CAT_non_reserved_partition_MASK represent the way bit masks for reserved ways and non-reserved ways, respectively. One embodiment of hardware will implement: Bit mask for reserved CLOSn = IA32_L3_MASK_n & CAT_reserved_partition_MASK Bit mask for non-reserved CLOSn = IA32_L3_MASK_n & CAT_non_reserved_partition_MASK

[0135] b) Implement the association between reserved CLOS and TD private access

[0136] To ensure that the reserved CLOS is only used for TD private access, the TD root (TDR) control structure is extended with a field for storing the reserved CLOS of the TD. TDR is the root control structure of the guest TD, and in one embodiment, the reserved CLOS field in the TDR control structure is set when the TD is created.

[0137] Fig.14 An example is shown with two TDs 1441 and 1442, each with a TDR control structure 1447 and 1448, respectively. The two TDs 1441-1442 are executed on logical processors 1461-1462 according to the TDX module 1420 (e.g., based on the current TDX configuration). Also illustrated are two legacy VMs 1411-1412 executed on logical processors 1451-1452 according to the host VMM 1410. The threads of each legacy VM 1411-1412 are associated with corresponding CLOS values ​​1401-1402 stored in each logical processor MSR 1490-1491 (e.g., IA32_PQR_ASSOC), respectively.

[0138] At TD entry, the reserved CLOS fields (CLOS0 in the example) stored in the TDR control structures 1447-1448 of each TD 1441-1442 are loaded into the internal control registers (CR) 1431-1432, which overwrite the IA32_PQR_ASSOC MSRs 1492-1493, respectively, to provide CLOS (CLOS0 in the example) for TD 1441-1442 to access private pages. At the same time, IA32_PQR_ASSOC MSRs 1490-1493 are used to provide CLOS values ​​for traditional VM 1411-1412 accesses to shared pages (CLOS1 and CLOS2 in the example) and TD 1441-1442 accesses (CLOS1 and CLOS3 in the example). The reserved CLOS value (CLOS0) is associated with a capacity bit mask (eg, a path mask) that identifies the reserved region 1471 in the LLC 1470. For example, in Fig.13 , the first four bits 1301 of the CLOS0 way mask 1300A are set, thereby specifying a reserved region 1471 of the LLC 1470. As mentioned, any attempted write to one of the IA32_PQR_ASSOC MSRs 1490-1493 having a reserved CLOS value (eg, CLOS0) will result in a #GP fault.

[0139] In one embodiment, the core / logical processors 1461-1462 associate the correct CLOS value with the request. Thus, the LLC cache management circuit 1475 does not need to determine whether the request from the core is a TD private request when replacing a cache line. Fig.14 In the example, logical processors 1461-1462 associate TD private requests with CLOS0, and cache management circuit 1475 limits cache operations for TD private requests within reserved LLC region 1471 based on the CLOS0 value. In the special case where there is a single reserved CLOS, the reserved CLOS value need not be stored in TDR control structures 1447-1448 (e.g., because its value can be implicit).

[0140] c) Prevent Host Key ID (HKID) aliases

[0141] In some embodiments, TDX 1420 relies on multi-key full memory encryption (MKTME) for isolation. Specifically, each TD 1441-1442 is assigned a unique host key ID (HKID) for encrypting TD private pages. Since each TD private page is not shared with any other TD or traditional VM 1411-1412, and the memory management unit (memory management unit, MMU) can prevent traditional VM / VMM from using TD private HKID to map to TD private pages, TD is generally not subject to reuse-based attacks, such as Flush-Reload attacks. The only exception may occur when an attacker uses a shared HKID to map a TD private page, which is called a keyID (key ID) alias problem. In certain configurations and situations, to prevent the keyID alias problem, older alias data is forced to be expelled, and new side channels similar to Flush-Reload attacks may exist.

[0142] refer to Fig.15, the snoop logic 1501 of one embodiment of the LLC management circuitry 1475 allows duplicate copies of cache lines 1505A-B to exist in both the reserved region 1471 (e.g., stored in the reserved ways) and the non-reserved region of the LLC 1470. In one embodiment, in response to a snoop request from the LPs 1451-1452, 1461-1462 associated with a non-reserved CLOS value (i.e., snooping only in the non-reserved region of the LLC 1470), the snoop logic 1501 ignores the cache line 1505A in the reserved region 1471. Conversely, in response to a snoop request associated with a reserved CLOS value (e.g., CLOS0) (i.e., snooping only in the reserved region 1471), the snoop logic 1501 ignores the cache line 1505B in the non-reserved region of the LLC 1470. Since TD private pages are not shared with the host VMM or legacy VMs, having duplicate cache lines 1505A-B from TD private pages in both reserved ways and non-reserved ways does not cause coherency issues. C. Other resource enhancements

[0143] In some embodiments of the present invention, other types of shared resources are reserved for exclusive use by certain software components (e.g., such as TDs 1441-1442), including other cache levels (e.g., such as mid-level cache (MLC)) and snoop filter 1501. For example, Fig.15 As shown, the reserved area 1502A and the non-reserved area 1502B of the snoop filter 1501 can be indicated via a mask value (or other type of value) stored in one or more control registers (e.g., such as the CLOS MSR described above). In this implementation, snoop requests generated based on the reserved CLOS value will be handled exclusively by the reserved area 1502A, while snoop requests from the non-reserved CLOS value will be handled by the non-reserved area 1502B.

[0144] In one embodiment, the architecture for reserving CLOS values ​​operates as described above, i.e., the reserved portion of the resources shares the same reserved CLOS value, regardless of which additional resource types are divided into reserved and non-reserved areas. In some embodiments, each resource type reserves a portion of its resources separately. At least one CLOS value needs to be reserved to reserve any of these resource types.

[0145] In some embodiments, each CLOS is associated with multiple mask values ​​in order to configure resource allocations for different categories of information. Fig.16The diagram shows an example of configuring two way mask registers for each CLOS. For example, way mask registers 1600A-B are associated with CLOS0, and way mask registers 1600C-D are associated with CLOS1. A different set of reserved mask bits 1601-1602 are set in each register 1600A-B, respectively, to indicate the portion of resources reserved for each of the two different types of information. Similarly, a different set of mask bits 1603-1604 are set in the CLOS1 way mask registers 1600C-D, respectively, to indicate the non-reserved portion of resources allocated for the two different types of information. As an example and not limitation, a code-data prioritization (CDP) scheme can be implemented using separate resource allocations for code and data. The reservation of CDP CLOS corresponds to configuring reserved mask bits 1601 for code in CLOS0 way mask register 1600A, and configuring reserved mask bits 1602 for data in CLOS0 way mask register 1600B. More formally, once CLOSn is reserved for TDX, CLOSn.Data (MASK_2n) and CLOSn.Code (MASK_2n+1) are reserved to control resource usage for data and code, respectively.

[0146] Fig.17 A method according to one embodiment is illustrated in . The method can be implemented on various architectures described herein, but is not limited to any particular processor or system architecture.

[0147] At 1701, a BIOS (e.g., secure BIOS / firmware) reserves resources and one or more CLOS values ​​for a trust domain, and a capacity bit mask (CBM) for each CLOS is initialized to a default value at 1702. For example, a CBM for a reserved CLOS may include an all-0 bit mask for non-reserved resources and an all-1 bit mask for reserved resources (and vice versa for non-reserved CLOS values).

[0148] At 1703, at TD creation time (e.g., when a TD VM is created), the TD is associated with a CLOS value from a reserved CLOS value, and the CLOS value is written to the TD root (TDR) field. The TDX module may additionally configure the CBM for the CLOS. However, note that the TDX module does not necessarily configure the CBM at TD creation time; instead, in some implementations, the CBM is configured before any TD is created.

[0149] At 1704, upon TD entry, the CLOS value for TD private access is loaded from the TDR field into a control register (CR) (e.g., CR 1431 described above). At 1705, a memory access request is received. If the memory access request is for a TD private page, the CLOS value from CR is associated with the request at 1707; otherwise, the CLOS value from IA32_PQR_ASSOC (e.g., IA32_PQR_ASSOC 1492 described above) is associated with the request at 1708.

[0150] Assuming that the memory access request is granted based on the source of the request, the CLOS value and its corresponding CBM are consumed at cache replacement and used, for example, to select a victim cache line for replacement. Therefore, at 1709, the CLOS and corresponding CBM are used to select one or more victim cache lines (e.g., from a reserved area). In these embodiments, the allowed resources are determined by IA32_L3_MASK_n (i.e., CBM) and the way bit masks of the reserved ways and non-reserved ways.

[0151] In some implementations, a Write MSR (WRMSR) is performed on an MSR that contains a capacity bit mask value (e.g., IA32_L3_MASK_n in CBM configuration). In a safe implementation, if the WRMSR is performed in non-SEAM mode and the MSR is associated with a reserved CLOS value, and there is more than one reserved CLOS value, the write request is denied and a fault is generated. Additionally, upon TD entry, a WRMSR operation is attempted on the IA32_PQR_ASSOC MSR. If the CLOS value to be written is a reserved CLOS value, the TD entry fails and a fault is generated.

[0152] The above-described embodiments of the present invention provide many advantages over existing mitigation techniques (such as randomization-based mitigations) that require significant changes to the cache architecture and only provide probabilistic security guarantees. Furthermore, in contrast to the embodiments of the present invention, existing partition-based mitigations are incompatible with the TDX threat model because the partitions need to be configured and managed by system software and therefore cannot provide any guarantees for the partition properties of the TD (i.e., exclusive ownership of the cache partitions). Furthermore, mitigations that minimize victim inclusion cannot completely prevent cache side-channel attacks. The above-described embodiments of the present invention address all of these issues.

[0153] Example

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

[0155] Example 1. A processor comprising: a plurality of cores, each core of the plurality of cores for providing at least one logical processor of a plurality of logical processors; a first plurality of registers, each register of the first plurality of registers for associating a class of service (CLOS) value with a corresponding logical processor of the plurality of logical processors; a second plurality of registers, each register of the second plurality of registers for indicating a portion of a shared resource to be allocated to the corresponding CLOS value; a first control register of a first logical processor of the plurality of logical processors for being configured with a reserved CLOS value associated with a trusted control structure; a resource reservation circuit configurable by secure firmware or software to indicate a reserved portion of a shared resource associated with the reserved CLOS value; and an implementation circuit for limiting access to the reserved portion of the shared resource to a thread or logical processor associated with the reserved CLOS value.

[0156] Example 2. The processor of Example 1, wherein the second plurality of registers includes a plurality of mask registers, each mask register of the plurality of mask registers to store a mask value indicating a corresponding portion of the shared resource to be allocated to a corresponding CLOS value.

[0157] Example 3. The processor of example 1 or 2, wherein a first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

[0158] Example 4. The processor of any of Examples 1-3, wherein a portion of the reserved portion of the shared resource is used to store data shared within the trust domain associated with the reserved CLOS value.

[0159] Example 5. The processor of any of Examples 1-4, wherein the shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

[0160] Example 6. The processor of any of Examples 1-5, further comprising: a cache management circuit to manage allocation and eviction of cache lines within the cache, wherein the cache management circuit is configured to allocate multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with a reserved CLOS value and a second copy of the cache line in one or more non-reserved regions of the cache associated with a non-reserved CLOS value.

[0161] Example 7. The processor of any of Examples 1-6, wherein, in response to a snoop request from a logical processor associated with a non-reserved CLOS value, the cache management circuit is to ignore the first copy of the cache line in the reserved region.

[0162] Example 8. The processor of any of Examples 1-7, wherein, in response to a snoop request from a logical processor associated with a reserved CLOS value, the cache management circuit is to ignore the second copy of the cache line in one or more unreserved regions of the cache.

[0163] Example 9. A method comprising: storing a class of service (CLOS) value associated with a corresponding logical processor of a plurality of logical processors in each of a first plurality of registers; storing an indication of a portion of a shared resource to be allocated to the corresponding CLOS value in each of a second plurality of registers; storing a reserved CLOS value associated with a trusted control structure in a first control register of a first logical processor of one or more logical processors; indicating, by secure firmware or software, a reserved portion of a shared resource associated with the reserved CLOS value; and restricting access to the reserved portion of the shared resource to a thread or logical processor associated with the reserved CLOS value.

[0164] Example 10. The method of Example 9, wherein the second plurality of registers includes a plurality of mask registers, each mask register of the plurality of mask registers for storing a mask value indicating a corresponding portion of the shared resource to be allocated to a corresponding CLOS value.

[0165] Example 11. The method of example 9 or 10, wherein a first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

[0166] Example 12. The method of any of Examples 9-11, wherein a portion of the reserved portion of the shared resource is used to store data shared within the trust domain associated with the reserved CLOS value.

[0167] Example 13. The method of any of Examples 9-11, wherein the shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

[0168] Example 14. The method of any of Examples 9-13, further comprising: managing allocation and eviction of cache lines within the cache, wherein the management comprises allocating multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with a reserved CLOS value and a second copy of the cache line in one or more non-reserved regions of the cache associated with a non-reserved CLOS value.

[0169] Example 15. A machine-readable medium having program code stored thereon, the program code, when executed by a machine, causing the machine to perform operations, the operations comprising: storing a class of service (CLOS) value associated with a corresponding logical processor of a plurality of logical processors in each of a first plurality of registers; storing an indication of a portion of a shared resource to be allocated to the corresponding CLOS value in each of a second plurality of registers; storing a reserved CLOS value associated with a trusted control structure in a first control register of a first logical processor of one or more logical processors; indicating, by secure firmware or software, a reserved portion of a shared resource associated with the reserved CLOS value; and restricting access to the reserved portion of the shared resource to the thread or logical processor associated with the reserved CLOS value.

[0170] Example 16. The machine-readable medium of Example 15, wherein the second plurality of registers comprises a plurality of mask registers, each mask register of the plurality of mask registers to store a mask value indicating a corresponding portion of the shared resource to be allocated to a corresponding CLOS value.

[0171] Example 17. The machine-readable medium of Example 15 or 16, wherein a first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

[0172] Example 18. The machine-readable medium of any of Examples 15-17, wherein a portion of the reserved portion of the shared resource is used to store data shared within the trust domain associated with the reserved CLOS value.

[0173] Example 19. The machine-readable medium of any of Examples 15-18, wherein the shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

[0174] Example 20. The machine-readable medium of any of Examples 15-19, further comprising: managing allocation and eviction of cache lines within the cache, wherein the management comprises allocating multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with a reserved CLOS value and a second copy of the cache line in one or more non-reserved regions of the cache associated with a non-reserved CLOS value.

[0175] Embodiments of the present invention may include the steps described above. These steps may be embodied as machine executable instructions, which may be used to cause a general or special processor to perform these steps. Alternatively, these steps may be performed by specific hardware components containing hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

[0176] As described herein, instructions may refer to a specific configuration of hardware such as an application-specific integrated circuit (ASIC) that is configured to perform certain operations or have predetermined functions or software instructions stored in a memory embodied in a non-transitory computer-readable medium. Thus, the techniques shown in the accompanying drawings can be implemented using code and data stored on and executed on one or more electronic devices (e.g., terminal stations, network elements, etc.). Such electronic devices use computer machine-readable media (internally and / or with other electronic devices through a network) to store and transmit code and data, such as non-transitory computer machine-readable storage media (e.g., disks; optical disks; random access memory; read-only memory; flash memory devices; phase change memory) and transient computer machine-readable communication media (e.g., electrical, optical, acoustic or other forms of propagation signals - such as carrier waves, infrared signals, digital signals, etc.). In addition, such electronic devices typically include a collection of one or more processors coupled to one or more other components (such as, one or more storage devices (non-transitory machine-readable storage media), user input / output devices (e.g., keyboards, touch screens and / or displays), and network connections). The coupling of the set of processors with other components is typically through one or more buses and bridges (also referred to as bus controllers). The storage device and signal carrying network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of the electronic device. Of course, different combinations of software, firmware, and / or hardware can be used to implement one or more parts of an embodiment of the present invention. Throughout this specific embodiment, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention can be implemented without some of these specific details. In some instances, known structures and functions are not described in detail to avoid obscuring the subject matter of the present invention. Therefore, the scope and spirit of the present invention should be determined according to the appended claims.

Claims

1. A processor, comprising: a plurality of cores, each core of the plurality of cores being configured to provide at least one logical processor of the plurality of logical processors; a first plurality of registers, each register of the first plurality of registers for associating a service class CLOS value with a corresponding logical processor of the plurality of logical processors; a second plurality of registers, each register of the second plurality of registers for indicating a portion of a shared resource to be allocated to a corresponding CLOS value; a first control register of a first logical processor of the plurality of logical processors to be configured with a reserved CLOS value associated with a trusted control structure; resource reservation circuitry configurable by secure firmware or software to indicate a reserved portion of said shared resource associated with said reserved CLOS value; as well as Circuitry is implemented for limiting access to the reserved portion of the shared resource to threads or logical processors associated with the reserved CLOS value.

2. The processor of claim 1, wherein: The second plurality of registers includes a plurality of mask registers, each mask register of the plurality of mask registers for storing a mask value indicating a corresponding portion of the shared resource to be allocated to the corresponding CLOS value.

3. The processor of claim 2, wherein: A first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

4. The processor of claim 3, wherein: The portion of the reserved portion of the shared resource is used to store data shared within a trust domain associated with the reserved CLOS value.

5. The processor according to any one of claims 1 to 4, wherein: The shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is configured to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

6. The processor of claim 5, further comprising: and cache management circuitry for managing allocation and eviction of cache lines within the cache, wherein the cache management circuitry is configured to allocate multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with the reserved CLOS value and a second copy of the cache line in one or more unreserved regions of the cache associated with an unreserved CLOS value.

7. The processor of claim 6, wherein: In response to a snoop request from a logical processor associated with a non-reserved CLOS value, the cache management circuit is to ignore the first copy of the cache line in the reserved region.

8. The processor of claim 7, wherein: In response to a snoop request from a logical processor associated with the reserved CLOS value, the cache management circuitry is operable to ignore the second copy of the cache line in the one or more unreserved regions of the cache.

9. A method comprising: storing a service class CLOS value associated with a corresponding logical processor of the plurality of logical processors in each register of the first plurality of registers; storing in each register of the second plurality of registers an indication of a portion of the shared resource to be allocated to the corresponding CLOS value; storing a reserved CLOS value associated with a trusted control structure in a first control register of a first logical processor of the one or more logical processors; indicating, by secure firmware or software, a reserved portion of the shared resource associated with the reserved CLOS value; as well as Access to the reserved portion of the shared resource is restricted to threads or logical processors associated with the reserved CLOS value.

10. The method of claim 9, wherein: The second plurality of registers includes a plurality of mask registers, each mask register of the plurality of mask registers for storing a mask value indicating a corresponding portion of the shared resource to be allocated to the corresponding CLOS value.

11. The method of claim 10, wherein: A first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

12. The method of claim 11, wherein: The portion of the reserved portion of the shared resource is used to store data shared within a trust domain associated with the reserved CLOS value.

13. The method according to any one of claims 9 to 12, wherein: The shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is configured to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

14. The method of claim 13, further comprising: Managing allocation and eviction of cache lines within the cache, wherein management includes allocating multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with the reserved CLOS value and a second copy of the cache line in one or more unreserved regions of the cache associated with an unreserved CLOS value.

15. A machine-readable medium having program code stored thereon, wherein the program code, when executed by a machine, causes the machine to perform operations, the operations comprising: storing a service class CLOS value associated with a corresponding logical processor of the plurality of logical processors in each register of the first plurality of registers; storing in each register of the second plurality of registers an indication of a portion of the shared resource to be allocated to the corresponding CLOS value; storing a reserved CLOS value associated with a trusted control structure in a first control register of a first logical processor of the one or more logical processors; indicating, by secure firmware or software, a reserved portion of the shared resource associated with the reserved CLOS value; as well as Access to the reserved portion of the shared resource is restricted to threads or logical processors associated with the reserved CLOS value.

16. The machine-readable medium of claim 15, wherein: The second plurality of registers includes a plurality of mask registers, each mask register of the plurality of mask registers for storing a mask value indicating a corresponding portion of the shared resource to be allocated to the corresponding CLOS value.

17. The machine-readable medium of claim 16, wherein: A first register of the second plurality of registers associated with the reserved CLOS value is used to store a first mask value indicating a portion of the reserved portion of the shared resource allocated to the reserved CLOS value.

18. The machine-readable medium of claim 17, wherein: The portion of the reserved portion of the shared resource is used to store data shared within a trust domain associated with the reserved CLOS value.

19. The machine-readable medium of any one of claims 15 to 18, wherein: The shared resource comprises a cache, and wherein each mask value comprises a plurality of bits corresponding to a plurality of cache ways, wherein one bit of the plurality of bits is configured to be set to a first value to indicate that the corresponding cache way is assigned to the corresponding CLOS value.

20. The machine-readable medium of claim 19, further comprising: Managing allocation and eviction of cache lines within the cache, wherein management includes allocating multiple copies of some cache lines, including a first copy of the cache line in a reserved region of the cache associated with the reserved CLOS value and a second copy of the cache line in one or more unreserved regions of the cache associated with an unreserved CLOS value.

Images