Memory-assisted inline encryption / decryption

Abstract

To provide a method, apparatus and system for memory-assisted encryption / decryption.SOLUTION: A computing device includes an encryption data structure engine to provide a key, data and a tweak to an encryption / decryption engine. The encryption data structure engine reads an index value from an encryption data structure lookup data structure entry using an address. The entry includes the index value and a guest page physical address (GPPA), and retrieves, based on the index value, an entry from the encryption data structure. The entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA in a sequence of GPPAs. An LBA is generated using a position of the GPPA from the encryption data structure lookup data structure entry in the sequence of GPPAs, and a key is retrieved based on the key identifier. The encryption engine encrypts data using the key and the LBA.SELECTED DRAWING: Figure 6

Description

Background Art

[0001] Non-Volatile Memory Express (NVMe) devices store data (i.e., persistently) during storage, and this data must be encrypted for security. To perform encryption on a System on Chip (“SOC”), an encryption (referred to interchangeably herein as “crypto”) controller responsible for encryption on the SOC requires multiple information about the NVMe device including the Logical Block Address (LBA) of the NVMe device where the data is stored. Although some embodiments herein are described with reference to NVMe, the embodiments are not limited to NVMe, and other types of non-volatile memory may be used.

Brief Description of the Drawings

[0002] Various embodiments according to the present disclosure are described in connection with the following drawings.

[0003] [Figure 1] An exemplary embodiment of a computing device for implementing the disclosed embodiments is schematically shown.

[0004] [Figure 2] An exemplary system topology according to an example of the present disclosure is schematically shown.

[0005] [Figure 3A] One or more system architectures for memory access at line speed according to embodiments of the present disclosure are shown. [Figure 3B] One or more system architectures for memory access at line speed according to embodiments of the present disclosure are shown.

[0006] [Figure 4A] Exemplary in-line encryption for writing data to an NVMe SSD is shown.

[0007] [Figure 4B] This illustrates an exemplary inline decoding process for writing data to an external memory module of an NVMe device.

[0008] [Figure 5] The key lookup tables shown here are one or more examples of the disclosure in which a single key ID is used.

[0009] [Figure 6] This document illustrates the use of encrypted data structures, lookup data structures, and other encrypted data structures.

[0010] [Figure 7] This document illustrates an embodiment of a method performed by a cryptographic controller or cryptographic data structure engine to perform DRAM-assisted inline encryption or decryption.

[0011] [Figure 8] An exemplary embodiment of the system is shown.

[0012] [Figure 9] A block diagram of an embodiment of a processor that may have multiple cores, an integrated memory controller, and integrated graphics is shown.

[0013] [Figure 10A] This block diagram shows both an exemplary in-order pipeline and an exemplary out-of-order issue / execution pipeline for register renaming, according to embodiments of the present invention.

[0014] [Figure 10B] This block diagram shows both an exemplary embodiment of an in-order architecture core and an exemplary out-of-order issue / execution architecture core for register renaming, which are included in a processor according to embodiments of the present invention.

[0015] [Figure 11] Embodiments of an execution unit circuit, such as the execution unit circuit of FIG. 10B, are shown.

[0016] [Figure 12] It is a block diagram of a register architecture according to some embodiments.

[0017] [Figure 13] Embodiments of an instruction format are shown.

[0018] [Figure 14] Embodiments of an addressing field are shown.

[0019] [Figure 15] Embodiments of a first prefix are shown.

[0020] [Figure 16A] Embodiments showing how the R, X, and B fields of the first prefix 1301(A) are used are shown. [Figure 16B] Embodiments showing how the R, X, and B fields of the first prefix 1301(A) are used are shown. [Figure 16C] Embodiments showing how the R, X, and B fields of the first prefix 1301(A) are used are shown. [Figure 16D] Embodiments showing how the R, X, and B fields of the first prefix 1301(A) are used are shown.

[0021] [Figure 17A] Embodiments of a second prefix are shown. [Figure 17B] Embodiments of a second prefix are shown. ]>

[0022] [Figure 18] Embodiments of a third prefix are shown.

[0023] [Figure 19] A block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set, according to an embodiment of the present invention, is shown. [Modes for carrying out the invention]

[0024] This disclosure relates to methods, apparatus, systems, and non-temporary computer-readable storage media for memory-assisted encryption / decryption.

[0025] The following description includes numerous specific details to provide a complete understanding of the various embodiments. However, various embodiments can be carried out without specific details. In other examples, well-known methods, procedures, components, and circuits are not described in detail so as not to obscure the particular embodiments. Furthermore, various aspects of the embodiments may be carried out using various means such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or any combination of hardware and software. For the purposes of this disclosure, reference to "logic" means any of hardware (logic circuits, or more generally circuits or circuits), software, firmware, or any combination thereof.

[0026] In various embodiments, information about the NVMe device does not need to be communicated to the host (or, as interchangeably referred to herein, the “host driver”) or cryptographic controller in the DMA (Direct Memory Access) path. In other words, the drive does not need to send this information to the host when performing a DMA operation. Most NVMe drives used in personal computers must use PCIe (Peripheral Components Interface Express protocol, as maintained and developed by PCI-SIG (PCI Special Interest Group)), and the PCIe protocol header does not provide an easy mechanism for the drive to send additional information. This makes the issue of inline encryption using NVMe very cumbersome. As described herein, inline encryption means that encryption and decryption occur as data is read from the drive to DRAM or vice versa. This is in contrast to indexed encryption, where the NVMe controller writes the data to memory, and then some other agent reads the plaintext data from memory, encrypts it, and writes it back to memory, or reads the ciphertext from memory, decrypts it, and writes the plaintext back to memory. As a result, the drive does not need to provide information for encryption.

[0027] In some earlier implementations, the software had to maintain a table of transaction and logical block addresses (LBAs) to generate fine-tuning for incoming transactions in real time. To reduce memory latency, the fine-tuning inputs were stored in local SRAM (local to the processing engine inside the silicon). This works for a small number of pending DMA transactions, but quickly becomes difficult as the number of pending DMA transactions increases. SRAM usage is not scalable, and the cost of the solution increases as the amount of SRAM required increases.

[0028] Figure 1 schematically illustrates an exemplary embodiment of a computing device for carrying out the disclosed embodiments. In Figure 1, the computing device 100 comprises a computer platform that hosts an integrated circuit ("IC") such as a SoC that integrates various hardware and / or software components of the computing device 100 onto a single chip. As shown, in one or more examples, the computing device 100 may include (but is not limited to) a graphics processing unit 114 ("GPU" or simply "graphics processor"), a graphics driver 116 (also referred to as "GPU driver," "graphics driver logic," "driver logic," user-mode driver (UMD), UMD, user-mode driver framework (UMDF), UMDF, or simply "driver"), a central processing unit 112 ("CPU" or simply "application processor"), memory 108, network devices, drivers, and any number and types of hardware and / or software components, as well as input / output (I / O) sources 104 such as a touchscreen, touch panel, touchpad, virtual or regular keyboard, virtual or regular mouse, ports, connectors, etc. The computing device 100 may include an operating system (OS) 106 that functions as an interface between the hardware and / or physical resources of the computing device 100 and the user. The SOC 100 may optionally communicate with the NVM 150. The non-volatile memory 150 can be accessed using Non-Volatile Memory Express, a protocol for accessing high-speed storage media. NVMe is used herein to refer to both non-volatile memory (e.g., SSD) and its communication protocol.

[0029] Figure 1 shows an exemplary embodiment, and it should be noted that additional components may be included without departing from the disclosed principles. For example, embodiments may be implemented as one or more microchips or integrated circuits, hardwired logic, software, firmware, application-specific integrated circuits (ASICs), and / or field-programmable gate arrays (FPGAs) interconnected using a motherboard, and executed by a microprocessor. The terms “logic,” “module,” “component,” “engine,” and “mechanism” may include, for example, software or hardware such as firmware and / or combinations thereof. Additional embodiments may be implemented using one or more memory chips, controllers, CPUs (central processing units), microchips, or integrated circuits interconnected using a motherboard, application-specific integrated circuits (ASICs), and / or field-programmable gate arrays (FPGAs). The term “logic” may include, for example, software or hardware and / or combinations of software and hardware.

[0030] Figure 2 schematically shows an exemplary system topology according to an example of the present disclosure. In some examples, the CPU 210 in Figure 2 includes a PCIe controller 212. In some examples, the PCIe controller 212 includes an encryption engine 214, but this is not the case in all embodiments. The PCIe controller 212 conventionally defines an interface standard for connecting high-speed components such as NVMe. As shown, the PCIe controller 212 includes an encryption engine 214 for encrypting / decrypting inbound and outbound communications. The CPU 210 communicates with peripheral components (i.e., NVMe drive 250) via the PCIe controller 212. The NVMe controller 252 acts as a portal to the NVMe driver and may include additional components (not shown) for encrypting / decrypting inbound / outbound communications. Communication between the CPU 210 and the NVMe 250 is considered inline communication.

[0031] Inline encryption of NVMe drives presents challenges specific to NVMe drivers. In the exemplary embodiment shown in Figure 2, the challenge is that the NVMe drive 250 includes the NVMe controller 252 within the driver itself. As a result, the inline encryption engine 214 within the SOC 202 lacks the metadata necessary to determine which packets must be encrypted / decrypted and the keys / tweening materials required for their encryption.

[0032] Conventional memory device encryption methodologies include the AES-XTS standard, which uses fine-tuning. In such methodologies, fine-tuning is generated using logical block addresses (LBAs), and the challenge is that the host does not receive block addresses from the drive directly within the memory access (DMA) path. The LBAs are managed by the internal drive. A second challenge is that commands destined for the drive cannot be encrypted because they must be parsed and executed by the drive. Consequently, inline encryption in the SOC (i.e., the encryption engine 214) requires a mechanism to parse packets and determine which are data packets and which are command packages.

[0033] As will be explained in detail later, memory 201 is for storing the encrypted data structure 232, which is indexed by the encrypted data structure lookup data structure 230. The encrypted data structure 232 is for storing information used to generate the LBA, which is used as a fine-tuning for AES-XTS.

[0034] Data encryption and decryption are performed within the SOC. Figures 3A and 3B show a system architecture for line-speed memory access according to an embodiment of the present disclosure.

[0035] Specifically, Figure 3A shows a system architecture for a line-speed memory read process used for reading from memory 360 and writing to device 302. Referring to Figure 3A, the NVMe drive 302 can correspond to the NVMe drive 150 or 250 in Figures 1 and 2. In one example, the NVMe drive 302 comprises a solid-state drive (SSD) that handles write operations 301 on memory 360, as shown by memory read operation 393. Memory 360 can correspond to memory 108 or 201 in Figures 1 and 2. Memory 360 can include, for example, dynamic random access memory (DRAM).

[0036] Conventional SSDs read and write data to a substrate of interconnected flash memory chips manufactured from silicon. NVMe SSDs are gaining popularity due to their speed. NVMe SSDs use the NVMe Host Controller Interface Specification (NVMHCIS) (not shown) to access non-volatile storage media mounted via a PCIe bus network (not shown).

[0037] Referring again to Figure 3A, the NVMe drive 302 may require direct memory access (DMA) to memory 360 to retrieve data. Therefore, the NVMe drive 302 issues a DMA read request 310 to the SOC 320. The SOC 320 can correspond to the computing device / SOC 100 or SOC 202 in Figures 1 and 2. The DMA read request 310 does not need to be encrypted.

[0038] The SOC320 interposes between the NVMe drive 302 and the memory 360. The memory 360 may include dynamic random access memory (DRAM). The SOC320 is shown together with the encryption controller 322, the hardware key engine 324, and the input / output memory management unit (IOMMU) 328. The hardware key engine receives its key from the CPU ISA 340 (programmed by software) or from the security controller.

[0039] The cryptographic controller 322 may include one or more processor circuits and components. In one or more examples, the cryptographic controller 322 is implemented in the PCIe controller 212 of the SOC320. For example, the cryptographic controller 322 may implement or be part of the cryptographic engine 214 shown in Figure 2. In one or more examples, the cryptographic controller 322 includes an encryption / decryption engine 325 configured to encrypt or decrypt data according to instructions stored in cryptographic memory circuits and / or lookup tables. The cryptographic controller 322 may optionally also include a key lookup table (KLT) 326. The KLT 326 is a memory circuit used to store various lookup tables, as will be further described below.

[0040] The cryptographic controller 322 may optionally include memory that may have one or more static random access memory (SRAM) circuits that communicate with the processor circuits of the cryptographic controller 322. The memory circuit 327 may store one or more instructions for causing one or more processor circuits (not shown) in the cryptographic controller 322 to perform a plurality of desired tasks. Tasks include, for example, receiving and storing cryptographic information necessary to encrypt or decrypt data, forming data and / or key tables, and communicating the encrypted or decrypted data with components outside the SOC 320. Once formed, such tables may be stored in a key lookup table (KLT) 326, an encrypted data structure 232, and / or an encrypted data structure lookup data structure 230.

[0041] For simplicity, the following exemplary embodiments generally refer to the cryptographic controller 322 as including the encryption / decryption engine 325 and memory 327 where applicable.

[0042] The cryptographic controller 322 also includes an input / output memory management unit (IOMMU) 328 that connects a DMA-enabled I / O bus to external memory 360. In one or more examples, the IOMMU is located in the SOC 320 but not in the cryptographic controller 322. The cryptographic controller is located between the IOMMU and memory 360.

[0043] The software 340 interfaces with the SOC 320 via the CPU instruction set architecture (ISA) 342. The ISA 342 acts as an interface between the software 340 and the SOC 320. In one or more examples, the software 340 supports multiple encryption keys. The software 340 can program keys. There may be four types of keys: (1) generated hardware, (2) wrapped hardware, (3) plaintext key, and (4) unencrypted "key". The security controller 341 is shown as part of the software 340 to include one or more processors (circuit or logic) for implementing functions attributed to the software 340.

[0044] In another embodiment, software 340 may utilize a keywrap configuration 344. A keywrap configuration is a class of symmetric encryption algorithms designed to encapsulate (encrypt) encryption key material. Keywrap algorithms are intended to protect keys while they are stored in an untrusted storage device or when they are transmitted over an untrusted communication network. Here, since the communication is outside the SOC 320, a keywrap / handle configuration can be used as desired.

[0045] In an exemplary implementation, the NVMe driver (e.g., SSD) 302 sends a read request 310 to the SOC 320. The read request 310 does not have to be encrypted. In any embodiment, a portion of the read request 310 may be encrypted. The read request 310 includes an encrypted data structure lookup data structure index 230, which enables the cryptographic controller 322 (such as the cryptographic engine 214) to identify one or more encryptions of the requested data using the encrypted data structure 232. When using a PCIe link between the NVMe drive 302 and the SOC 320, the read request 310 may conform to the PCIe Transaction Layer Packet (TLP) format for read requests, and the TLP header can be used when generating LBA fine-tuning using 230 and 232 to facilitate encryption of the requested data by the cryptographic controller 322. If the read request 310 is not encrypted, the cryptographic controller 322 is not involved, and the SOC 320 relays the read request 330 to memory 360 via the IOMMU 328. In response to the request, memory 360 sends a read response 332 to SOC320 via IOMMU328.

[0046] The cryptographic controller 322 receives the data requested in the read response 332 and encrypts the requested data, according to the disclosed embodiments. In certain embodiments, the response includes one or more data packets. A data packet may generally include a header portion and a payload portion. The payload portion of the packet contains data that can be encrypted. The requested data is encrypted using an encryption key. The encryption key may be provided by software 340. As described above, SOC communication with the endpoint may be managed by the PCIe protocol, which allows the PCIe endpoint to add up to four 32-bit headers to the TLP packet, for example, as described according to the example herein. The PCIe endpoint has the option to send any additional data in these headers. The headers may be added by the NVMe controller 304.

[0047] In another embodiment, some of the address bits in the header of the read request 310 (and the write request 370, described below) may be used to indicate an index. In a PCIe context, the address bits may be included in the TLP header. The read request 310 and the write request 370 may be DMA requests that can have 64 bits of address information. The address information may be one of three pieces of information: a physical address, a guest physical address, or an IO virtual address. The number of available address bits may be used to index a table of 4K entries, each having 8 bytes per entry (i.e., a 32K byte table).

[0048] The cryptographic controller 322 parses and removes this header information, uses an index to look up entries in the cryptographic data structure lookup data structure 230, and uses the information from that lookup to compute the actual LBA from the base LBA using the cryptographic data structure 232.

[0049] In one or more examples, the cryptographic controller 322 selects the requested data read from memory 360 for encryption. In exemplary embodiments, this selection is based on a bus device function (BDF) used to identify one or more NVMe drives. Software 340 (which may include one or more of the following: an operating system (OS), software applications, host drivers, etc.) can provide the BDF for the NVMe drive 302 using a software interface to the cryptographic controller 322 (not shown). Data read from memory 360 for storage in the NVMe drive 302 is encrypted by the cryptographic controller 322 before the read data is passed to the NVMe drive. The encrypted data originating from the NVMe drive 302 is decrypted by the cryptographic controller 322 before being passed to another device, for example, memory 360. In some embodiments, data originating from other devices may not be encrypted / decrypted by the cryptographic controller.

[0050] The requested read data refers to the data requested by the host (e.g., software 340) using a command stream. The command stream is configured by software 340 and sent to the NVMe drive 302, which then sends it back in a TLP prefix (during the DMA session) provided in the read response 332. The SOC 320 reads the data from memory, the cryptographic controller encrypts the data, and the encrypted data 312 is communicated to the NVMe drive 302. The NVMe controller 304 receives the encrypted data and stores it in the SSD flash memory 303. The encrypted data 312 is then written to the NVMe drive 302 as indicated by the SSD write operation 301. Because encryption is performed in the SOC 320, the entire encryption operation is performed at inline DMA speeds, and no delays occur due to external components of the SOC 320.

[0051] Figure 3B shows a system architecture for a memory write process at line speed. In Figure 3B, the NVMe drive 302 is intended to write data to memory 360. The process begins with the NVMe drive 302 issuing a write request 370. The write request 370 may contain encrypted data, as indicated by the hatching of arrow 370. Thus, in one or more examples where the data stored in the NVMe 302 is already encrypted, the NVMe controller 304 can encrypt the payload data sent in the write request 370.

[0052] The SOC320 receives an encrypted write request 370 from the NVMe controller 304. The write request 370 contains encrypted data from the SSD flash memory 303 of the NVMe drive 302. To facilitate the decryption of the data by the cryptographic controller 322, the write request 370 further includes a key table index and optionally an offset to the LBA. As previously mentioned in relation to the read request 310, if a PCIe link is used between the NVMe drive 302 and the SOC320, the write request 370 can conform to the PCIe TLP format for write requests, and the TLP header can be used to indicate the key table index and the offset to the LBA. The cryptographic controller 322 decrypts the encrypted data from the write request 370 using one or more of the key information from the software 340, the key lookup table from the KLT326, the encrypted data structure 232, the encrypted data structure lookup data structure 230, and the hardcoded cryptographic key from the hardware key engine 324. Next, the decrypted data of the write request 370 is sent to memory 360 as indicated by arrow 372. Memory 360 then writes the data to the allocated memory slot. In one or more examples, the address indicating the memory location in memory 360 to write the data may be shown in the header of the write request 370. In this example, the key engine 324 is shown in Figures 3A and 3B and is part of the SOC 320. The key engine 324 may be implemented within the cryptographic controller 322.

[0053] Figure 4A shows exemplary inline encryption for writing data to an NVMe SSD. As described in relation to Figure 3A, the NVMe (SSD) issues a read request 310, which is shown as operation 401 in Figure 4A. The read request 310 is a DMA request sent from the NVMe drive 302 (e.g., controller 304) to the SOC 320. In operation 402, the SOC 320 receives the read request 310 and sends a read request 330 to the external memory 360 requesting data to be read from the memory 360. In operation 406, the external memory 360 responds to the read request 330 with a read response 332 containing the requested data. In operation 408, the read response 332 containing the (unencrypted) data is received by the SOC 320. In operation 410, the SOC's cryptographic controller 322 (not shown) encrypts the data using a hardware key, key index, and other encryption key information before sending the encrypted data 312 to the NVMe drive 302. The read request 310 may include encryption information, including a key table index and optionally an LBA offset, to enable the SOC's cryptographic controller 322 to select an encryption key and optionally encryption parameters for encrypting the requested data from memory 360. Note that neither the SOC 320 nor the NVMe drive 302 can decrypt the data to be stored in the flash memory of the NVMe drive 302. Rather, the data is stored as encrypted data.

[0054] Figure 4B shows an exemplary inline decryption process for writing data to an external memory module of an NVMe. As described in relation to Figure 3B, in operation 422, the NVMe (SSD) issues a write request 370 to the SOC. In one or more examples, the write request 370, which may contain encrypted data, is encrypted by the NVMe controller (304, Figure 3B). The write request 370 is sent to the SOC 320. In operation 426, the SOC 320 decrypts the encrypted data in the write request 370 at its cryptographic controller 322. The decrypted data from the write request 370 is then sent to the memory in the write request 372, as shown in operation 428. In operation 430, the memory 360 receives the decrypted data and writes it to the appropriate memory slot.

[0055] Figure 5 shows a key lookup table in one or more examples of this disclosure where a single key ID is used. In Figure 5, the NVMe drive 510 is shown together with the NVMe controller 512. As described with reference to Figures 3A and 3B, the cryptographic controller 530 may correspond to a cryptographic controller 322 that encrypts / decrypts transactional data. The PCIe interface 520 represents the interface between the cryptographic controller 530 and the NVMe drive 510. The cryptographic controller 530 in Figure 5 may, for example, use the encryption standard AES-XTS-256 for data encryption and decryption. Address data 540 indicating the physical address for DMA (64-bit) read or write access to memory 360 is initiated by the NVMe drive 515, as indicated by arrow 515. In one or more examples, the address data 540 includes the key lookup index 542, LBA offset 544, and physical address 546 of the data to be read or written. The address data 540 is included in a read or write request provided to the SOC, which has a cryptographic controller 530, via the PCIe interface 520. The address data 540 is used by the cryptographic controller 530 (also 322, Figures 3A and 3B) to obtain additional information for encrypting / decrypting the data. The KLT 550 may be stored in the SOC 320 (see KLT 326 in Figures 3A and 3B). The key lookup index 542 in the data 540 may be used by the cryptographic controller 530 (also 322, Figures 3A and 3B) to obtain the key ID, LBA, and file information data (used to encrypt the data) from the KLT 550. The key ID of the KLT 550 can provide the key for encrypting / decrypting the data (see key table 560). The file information data can provide additional information for generating fine-tuning for encryption / decryption.

[0056] As described, the exemplary inline cryptographic engine encrypts and decrypts data on the DMA path of an NVMe drive. This encryption and decryption is performed within the SOC. In some embodiments, encryption uses the AES-XTS256 standard. A unique attribute of AES-XTS256 is the use of two 256-bit keys, with a first key used for encryption or decryption using the AES round and a second key used for generating the fine-tuning.

[0057] Fine-tuning protects against known plaintext attacks where two plaintexts encrypted with the same key yield the same ciphertext. Traditionally, fine-tuning has been used to protect against such attacks by encrypting a nonce with a second key. The resulting fine-tuning is then used to XOR the encrypted plaintext and ciphertext, so that two plaintexts encrypted with the same key yield different ciphertexts due to the different fine-tunings.

[0058] As mentioned above, inline encryption means that encryption and decryption occur as data is being read from the drive to DRAM, or vice versa. This is in contrast to index encryption, where the NVMe controller writes the data to memory, and then some other agent reads the plaintext data from memory, encrypts it, and writes it back to memory, or reads the ciphertext from memory, decrypts it, and writes the plaintext back to memory. As a result, the drive does not need to provide any information for encryption.

[0059] To address this problem, a table-based approach can be used, allowing the host software to set up the table, which the cryptographic controller can then look up. While this option is feasible, it is not practical for the cryptographic controller to explore or parse a hierarchical table due to the need for fast lookups. An index to the table is required, and that index needs to be mapped within a transaction. This leads to the problem of sending the index within a transaction. This problem can be solved by using unused address bits. However, there is also a need to solve this problem without using address bits on platforms that require all those address bits, especially in the data centers of cloud service providers where all address bits must be used to address large amounts of data.

[0060] In some embodiments, the PCIe endpoint has the option to send additional data within these headers, for example, as described in relation to Figures 3A and 3B above. The PCIe header can be used to send an index, as detailed below. The cryptographic controller parses and removes this header information and uses the index to look up records / entries to calculate the actual LBA from the base LBA. This allows various embodiments to support, in one or more examples, an index of 64K pending entries (using 16 bits) and 20 bits (i.e., 1M*4K) or 4 gigabytes of pending input / output (I / O or IO) transaction offsets. Depending on the implementation, the table / index size can be larger than in this example.

[0061] Furthermore, such embodiments can provide scalability because address bits do not need to be reused. Also, implementation costs and footprint can be reduced because additional wires / pins are not required in the system to increase the number of address bits. Therefore, some embodiments offer further flexibility by allowing modifications to transmit more bits depending on the implementation.

[0062] Therefore, some embodiments relate to techniques for performing inline encryption on an NVMe drive using one or more PCIe extensions. In one example, an index to a key table is provided from the host (e.g., host software 304) to the NVMe drive, and the NVMe drive then communicates the key table index of the key used for encryption / decryption in DMA (or other memory access such as PCIe) requests, along with an offset value, for example, a PCIe TLP (Transaction Layer Packet) prefix.

[0063] Generally, an NVMe command includes a command code and parameters. Figure 5 shows sample information for an NVMe command related to a read or write operation, which may be used in one or more examples. The opcode or arithmetic code 502 indicates whether the command is a read or write command, and the PRP (Physical Area Page) entry (or page) 504 provides the guest physical address to the actual data. As shown in the figure, an NVMe command may reserve 32 bits for a 32-bit tag (up to in one example) sent by the software along with the command. The software 340 populates the tag 506 with a 32-bit index (and other information as needed), while the rest of the command remains the same. Although some embodiments herein are described with reference to a 32-bit tag, other size tags may also be used depending on system capabilities. In some embodiments, the NVMe command is part of a PCIe Transaction Layer Packet (TLP) as data in a TLP.

[0064] Figure 6 shows embodiments of the use of the encrypted data structure lookup data structure and the encrypted data structure. In particular, it shows the encrypted data structure lookup data structure 232 and the encrypted data structure 230 in some embodiments.

[0065] The encrypted data structure lookup data structure 232 contains one or more entries. Each entry contains a line index 607 (indicated as bits 63:52), a guest page physical address (GPPA) 609 (indicated as bits 51:12), and possibly unused bits (indicated as bit 11:0). The line index 607 provides at least a portion of a pointer to a particular entry in the encrypted data structure 230.

[0066] The encryption data structure 230 stores, for each entry, a base LBA, a key ID, and one or more GPPAs. The key ID points to a key 603 in key storage device 601. Key storage device 601 may be located on the die, in isolated memory, etc. Typically, the encryption data structure 230 resides in isolated memory within memory 201 so that it is readable only by the cryptographic controller 322 and writable by software. This can be configured in this way using either range registers or IOMMU. This memory is allocated by the BIOS and written to by the OS.

[0067] In the cryptographic data structure engine 610, upon receiving a TLP and / or NVMe command with a GPA 605 under the guidance of the orchestrator 616 (e.g., firmware routines, finite state machines, etc.), the TLP handler 611 uses the index bits from the GPA 605 to access the cryptographic data structure lookup data structure 232. For example, the GPA provided by PRP entry 1 in Figure 5. The entry is indexed by the higher bits provided by the GPA 605. These GPA 605 bits are called index bits (INDEX_BITS) because they provide a line (or entry) index to the cryptographic data structure lookup data structure 232. Note that in this diagram, bits 63:52 of the GPA 605 are INDEX_BITS.

[0068] Line index 607 is used to access a specific entry (line) in the encrypted data structure 230 using the access circuit 614. In this example, the second entry is accessed based on the line index value. Note that the line in the encrypted data structure lookup data structure 232 contains the GPPA value of GPPA1. The line is returned and contains the base LBA, key ID, and GPPA.

[0069] The key ID is used to access key 603 in key storage device 601. The position of GPPA1 in the lines of the encrypted data structure 230 and base LBA can be used to generate an LBA which is used as a fine-tuned 615 by the encryption / decryption engine 325 to encrypt data 616 from TLP 600 using the accessed key. The encrypted data is then sent to storage device 620.

[0070] In this diagram, there are 12 bits in the index space, which leads to 4K entries in the encrypted data structure lookup data structure 232. This can be extended to 24 bits (0-11), which leads to 16M entries. Depending on the hardware read granularity, the size of the entries in the encrypted data structure 230 (LINE_SIZE) can be increased or decreased. The size of the encrypted data structure 230 can also be increased by adding additional index bits in the TLP header (in addition to or instead of the index in the address). As a result, the size of the encrypted data structure 230 is architecturally unlimited and is limited only by the amount of memory available in the system. For example, if the architecture supports 128B memory reads, LINE_SIZE can be increased to 128 bytes. 8 bytes are used for the header, which includes KEY_ID to identify the key associated with the line and the remaining points for BASE_LBA.

[0071] In some embodiments, one or more of the following are configurable: LINE_SIZE, index bit count, BLOCK_SIZE, and the size of the encrypted data structure lookup data structure 232. For example, in some embodiments, the PCONFIG instruction is called by software to configure platform functions. PCONFIG supports multiple leaves, and the leaf function is called by setting appropriate leaf values ​​in one or more registers. The leaves allow the host software to configure these parameters. Furthermore, this leaf is accessible only from ring 0 and has VMEXIT control. This allows the VMM to configure all VMs as needed.

[0072] The advantage of this approach is that it does not rely on expensive SRAM, thereby making the solution scalable and reducing implementation costs. Furthermore, this solution can scale to servers with high pending DMA transfer requirements and IoT devices with lower such requirements.

[0073] Figure 7 shows an embodiment of a method performed by the cryptographic controller 322 or the cryptographic data structure engine 610 to perform DRAM-assisted inline encryption or decryption. At 701, a TLP is received. The TLP includes data to be encrypted, such as PRP GPA.

[0074] In 703, the GPA of the TLP is used to read the index value from the encrypted data structure lookup data structure entry. With respect to Figure 6, the encrypted data structure lookup data structure 232 is accessed to retrieve the index value of the encrypted data structure 230.

[0075] In some embodiments, a determination is made in 705 as to whether encryption or decryption should be used. For example, the orchestrator 616 may make this determination. In some embodiments, if all index bits are 0, encryption / decryption is not used. If encryption / decryption is not used, the data from the TLP is not encrypted / decrypted and is sent to storage, a device (e.g., a CPU core), etc.

[0076] When encryption / decryption is used, the index value is used in 707 to retrieve a specific entry in the encrypted data structure (e.g., encrypted data structure 230). The entry is returned and includes the base LBA, key ID, and one or more GPPAs.

[0077] The LBA value is calculated in 709 using the GPPA location within a specific accessed entry of the cryptographic data structure. The GPPA location used is the GPPA value identified in the indexed cryptographic data structure lookup data structure entry.

[0078] In some embodiments, when the block size is 4KB, the GPPA position is multiplied by the block size to generate an intermediate result, and the LBA value is that intermediate result added to the base LBA. Note that 4KB is illustrative and the block size can be configurable in some examples. In some embodiments, when the block size is 512b, the GPPA position is multiplied by the block size * 8 to generate an intermediate result. The offset is calculated by taking the GPA of the TLP, ANDing it with 0xFFFF, and then shifting the result by 7 (e.g., GPA & 0xFFFF) >> 7. The LBA is obtained by multiplying the offset by 512 and adding the intermediate result (e.g., (intermediate result) + (offset * 512)).

[0079] The key ID is used in 713 to retrieve the key, and AES_XTS encryption or decryption is performed on the TLP data in 715 using the key and the calculated LBA value as fine-tuning inputs.

[0080] Encrypted or decrypted data is transferred at 717. [Embodimentary computer architecture]

[0081] Exemplary computer architectures are described in detail below. Other system designs and configurations known in the art are also suitable for laptops, desktops, and handheld PCs, portable information terminals, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices. Generally, a wide variety of systems or electronic devices that can incorporate the processors and / or other execution logic disclosed herein are generally suitable.

[0082] Figure 8 shows an exemplary system embodiment. The multiprocessor system 800 is a point-to-point interconnect system and includes multiple processors, including a first processor 870 and a second processor 880, coupled via a point-to-point interconnect 850. In some embodiments, the first processor 870 and the second processor 880 are homogeneous. In some embodiments, the first processor 870 and the second processor 880 are heterogeneous.

[0083] Processors 870 and 880 are shown to include integrated memory controller (IMC) unit circuits 872 and 882, respectively. Processor 870 also includes point-to-point (PP) interfaces 876 and 878 as part of its interconnect controller unit. Similarly, the second processor 880 includes PP interfaces 886 and 888. Processors 870 and 880 can exchange information via the point-to-point (PP) interconnect 850 using the PP interface circuits 878 and 888. IMCs 872 and 882 connect processors 870 and 880 to their respective memories, namely memory 832 and memory 834, which may be part of the main memory locally attached to each processor.

[0084] Processors 870 and 880 can exchange information with chipset 890 via individual PP interconnects 852 and 854 using point-to-point interface circuits 876, 894, 886, and 898, respectively. Chipset 890 can optionally exchange information with coprocessor 838 via high-performance interface 892. In some embodiments, coprocessor 838 is a dedicated processor, such as a high-throughput MIC processor, network or communications processor, compression engine, graphics processor, GPGPU, or embedded processor.

[0085] When the processors are placed in a low-power mode, the local cache information of either or both processors can be stored in the shared cache. The shared cache (not shown) may be located within or outside of processors 870, 880, or both processors, and may also be connected to multiple processors via a PP interconnect.

[0086] The chipset 890 can be coupled to a first interconnect 816 via interface 896. In some embodiments, the first interconnect 816 may be an interconnect of Peripheral Component Interconnects (PCI), or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some embodiments, one of the interconnects is coupled to a power control unit (PCU) 817, which may include circuitry, software, and / or firmware that performs power management operations related to processors 870, 880, and / or coprocessor 838. The PCU 817 provides control information to a voltage regulator to cause the voltage regulator to generate an appropriate regulated voltage. The PCU 817 also provides control information to control the generated operating voltage. In various embodiments, the PCU 817 may include various power management logic units (circuitry) to perform hardware-based power management. Such power management may be entirely processor-controlled (for example, controlled by various processor hardware and triggered by workload and / or power, heat, or other processor constraints), and / or power management may be performed in response to an external source (such as a platform or power management source or system software).

[0087] The PCU817 is shown as existing as logic separate from the processor 870 and / or processor 880. In other cases, the PCU817 may run on a given one or more cores (not shown) of the processor 870 or 880. In some cases, the PCU817 may be implemented as a microcontroller (dedicated or general-purpose) or other control logic configured to run its own dedicated power management code, referred to as P-code. In yet another embodiment, the power management operations performed by the PCU817 may be implemented externally to the processor by a separate power management integrated circuit (PMIC) or another component located outside the processor. In yet another embodiment, the power management operations performed by the PCU817 may be implemented within the BIOS or other system software.

[0088] Various I / O devices 814 may be coupled to the first interconnect 816, along with an interconnect (bus) bridge 818 that connects the first interconnect 816 to the second interconnect 820. In some embodiments, one or more additional processors 815, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or digital signal processing (DSP) unit), a field-programmable gate array (FPGA), or any other processor, are coupled to the first interconnect 816. In some embodiments, the second interconnect 820 may be a low-pin-count (LPC) interconnect. Various devices, such as a keyboard and / or mouse 822, a communication device 827, and a storage unit circuit 828, may be coupled to the second interconnect 820. In some embodiments, the storage unit circuit 828 may be a disk drive or other mass storage device that can contain instructions / code and data 830. Furthermore, the audio I / O 824 may be coupled to a second interconnect 820. It should be noted that architectures other than the point-to-point architecture described above are possible. For example, instead of a point-to-point architecture, systems such as the multiprocessor system 800 may implement a multidrop interconnect or other such architectures. [Embodimental core architectures, processors, and computer architectures]

[0089] Processor cores may be implemented in different forms and for different purposes in different processors. For example, such core implementations may include 1) general-purpose in-order cores intended for general-purpose computing, 2) high-performance general-purpose out-of-order cores intended for general-purpose computing, and 3) dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include a CPU comprising 1) one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing, and 2) a coprocessor comprising one or more dedicated cores intended primarily for graphics and / or scientific (throughput). Such different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (in this case, such a coprocessor may be referred to as dedicated logic, or dedicated core, such as integrated graphics and / or scientific (throughput) logic); and 4) a system-on-a-chip on the same die as the described CPU (which may be referred to as an application core or application processor), which may include the aforementioned coprocessor and additional functionality. An exemplary core architecture is described below, followed by descriptions of exemplary processors and computer architectures.

[0090] Figure 9 shows a block diagram of an embodiment of a processor 900 that may have multiple cores, an integrated memory controller, and integrated graphics. The solid box shows a processor 900 having a single core 902A, a system agent 910, and a set of one or more interconnect controller unit circuits 916, while the optional addition of a dotted box shows an alternative processor 900 having multiple cores 902(A) to (N), a set of one or more integrated memory controller unit circuits 914 in the system agent unit circuit 910, dedicated logic 908, and a set of one or more interconnect controller unit circuits 916. Note that the processor 900 may be one of the processors 870 or 880, or the coprocessor 838 or 815 in Figure 8.

[0091] Therefore, different implementations of the processor 900 may include: 1) a CPU having dedicated logic 908 (not shown, but may include one or more cores) which is integrated graphics and / or scientific (throughput) logic, and one or more general-purpose cores 902(A) to (N) (e.g., general-purpose in-order cores, general-purpose out-of-order cores, or a combination of the two); 2) a coprocessor having a number of dedicated cores 902(A) to (N) primarily intended for graphics and / or scientific (throughput); and 3) a coprocessor having a number of general-purpose in-order cores 902(A) to (N). Therefore, the processor 900 may be a general-purpose processor, coprocessor, or dedicated processor, such as a network or communications processor, a compression engine, a graphics processor, a GPGPU (General Purpose Graphics Processing Unit Circuit), a high-throughput multi-integrated core (MIC) coprocessor (including 30 or more cores), or an embedded processor. The processor may be implemented on one or more chips. The processor 900 may be part of one or more substrates and / or mounted on one or more substrates, for example, using one of several process technologies such as BiCMOS, CMOS, or NMOS.

[0092] The memory hierarchy includes one or more levels of external memory (not shown) coupled with cache unit circuits 904(A)-(N) within cores 902(A)-(N), a set of one or more shared cache unit circuits 906, and a set of integrated memory controller unit circuits 914. The set of one or more shared cache unit circuits 906 may include one or more intermediate level caches such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of caches such as a last level cache (LLC), and / or combinations thereof. In some embodiments, a ring-based interconnect network circuit 912 interconnects dedicated logic 908 (e.g., integrated graphics logic), the set of shared cache unit circuits 906, and the system agent unit circuit 910, while alternative embodiments use any number of known techniques to interconnect such units. In some embodiments, coherence is maintained between one or more shared cache unit circuits 906 and cores 902(A)-(N).

[0093] In some embodiments, one or more of the cores 902(A) to (N) can be multithreaded. The system agent unit circuit 910 includes components for coordinating and operating these 902(A) to (N). The system agent unit circuit 910 may include, for example, a power control unit (PCU) circuit and / or a display unit circuit (not shown). The PCU may be, or include, the logic and components necessary to regulate the power state of the cores 902(A) to (N) and / or dedicated logic 908 (e.g., integrated graphics logic). The display unit circuit is for driving one or more externally connected displays.

[0094] Cores 902(A) through (N) may be homogeneous or heterogeneous in terms of their architectural instruction sets. That is, two or more of the cores 902(A) through (N) may execute the same instruction set, while other cores may execute only a subset of that instruction set or a different instruction set. [Example Core Architecture] [Block diagrams of in-order and out-of-order cores]

[0095] Figure 10A is a block diagram showing both an exemplary in-order pipeline and an exemplary out-of-order issue / execution pipeline for register renaming according to an embodiment of the present invention. Figure 10B is a block diagram showing both an exemplary embodiment of an in-order architecture core and an exemplary out-of-order issue / execution architecture core for register renaming, included in a processor according to an embodiment of the present invention. In Figures 10A to 10B, solid boxes indicate in-order pipelines and in-order cores, while optional additions of dotted boxes indicate out-of-order issue / execution pipelines and cores for register renaming. Out-of-order embodiments are described assuming that in-order embodiments are a subset of out-of-order embodiments.

[0096] In Figure 10A, the processor pipeline 1000 includes a fetch stage 1002, an optional length decode stage 1004, a decode stage 1006, an optional allocation stage 1008, an optional renaming stage 1010, a scheduling (also known as dispatch or issue) stage 1012, an optional register read / memory read stage 1014, an execution stage 1016, a write-back / memory write stage 1018, an optional exception handling stage 1022, and an optional commit stage 1024. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1002, one or more instructions may be fetched from instruction memory; during the decode stage 1006, one or more fetched instructions may be decoded, an address using a transferred register port (e.g., a load-store unit (LSU) address) may be generated, and a branch transfer (e.g., an immediate offset or link register (LR)) may be performed. In one or more examples, the decode stage 1006 and the register read / memory read stage 1014 may be combined into a single pipeline stage. In one or more examples, during the execution stage 1016, the decoded instruction may be executed, LSU address / data may be pipelined to the Advanced Microcontroller Bus (AHB) interface, multiplication and addition operations may be performed, and arithmetic operations may be performed using branch results, etc.

[0097] As an example, an out-of-order issue / execution core architecture for exemplary register renaming may implement pipeline 1000 as follows: 1) Instruction fetch 1038 executes fetch and length decode stages 1002 and 1004. 2) Decode unit circuit 1040 executes decode stage 1006. 3) Renaming / allocation unit circuit 1052 executes allocation stage 1008 and renaming stage 1010. 4) Scheduler unit circuit 1056 executes scheduling stage 1012. 5) Physical register file unit circuit 1058 and memory unit circuit 1070 execute register read / memory read stage 1014, and execution cluster 1060 executes execution stage 1016. 6) Memory unit circuit 1070 and physical register file unit circuit 1058 execute write-back / memory write stage 1018. 7) Various units (unit circuits) may be involved in the exception handling stage 1022. 8) The retirement unit circuit 1054 and the physical register file unit circuit 1058 execute the commit stage 1024.

[0098] Figure 10B shows a processor core 1090 including a front-end unit circuit 1030 coupled to an execution engine unit circuit 1050, both of which are coupled to a memory unit circuit 1070. Core 1090 may be a reduced instruction set computing (RISC) core, a composite instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Further options include dedicated cores such as a network or communications core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, or a graphics core.

[0099] The front-end unit circuit 1030 may include a branch prediction unit circuit 1032 coupled to the instruction cache unit circuit 1034, the instruction cache unit circuit 1034 is coupled to an instruction translation index buffer (TLB) 1036, the TLB 1036 is coupled to an instruction fetch unit circuit 1038, and the instruction fetch unit circuit 1038 is coupled to a decode unit circuit 1040. In one or more examples, the instruction cache unit circuit 1034 is included in the memory unit circuit 1070 rather than the front-end unit circuit 1030. The decode unit circuit 1040 (or decoder) may decode an instruction and produce as output one or more microoperations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from the original instruction, or otherwise reflect them, or are derived from them. The decode unit circuit 1040 may further include an address generation unit circuit (AGU, not shown). In one or more examples, the AGU may generate an LSU address using a transferred register port and may also perform branch transfers (e.g., immediate offset branch transfer, LR register branch transfer, etc.). The decode unit circuit 1040 may be implemented using a variety of different mechanisms. Examples of preferred mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), and microcode read-on rememory (ROM). In one or more examples, the core 1090 includes a microcode ROM (not shown) or other medium for storing the microcode of a particular macro instruction (e.g., in the decode unit circuit 1040, or otherwise in the front-end unit circuit 1030). In one or more examples, the decode unit circuit 1040 includes a micro-operation (micro-op) or arithmetic cache (not shown) for holding / caching decoded arithms, microtags, or microoperations generated during decoding or other stages of the processor pipeline 1000. The decoding unit circuit 1040 may be coupled with the renaming / assignment unit circuit 1052 in the execution engine unit circuit 1050.

[0100] The execution engine circuit 1050 includes a renaming / allocation unit circuit 1052 coupled with a retirement unit circuit 1054 and a set of one or more scheduler circuits 1056. The scheduler circuits 1056 represent any number of different schedulers, including multiple reservation stations, a central instruction window, etc. In some embodiments, the scheduler circuits 1056 may include arithmetic logic unit (ALU) scheduler / scheduling circuits, ALU queues, arithmetic generation unit (AGU) scheduler / scheduling circuits, AGU queues, etc. The scheduler circuits 1056 are coupled with a physical register file circuit 1058. Each of the physical register file circuits 1058 represents one or more physical register files, which, being different, store one or more different data types, such as scalar integers, scalar floating-point numbers, packed integers, packed floating-point numbers, vector integers, vector floating-point numbers, and status (e.g., an instruction pointer, which is the address of the next instruction to be executed). In one or more examples, the physical register file unit circuit 1058 includes vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units may provide architecture vector registers, vector mask registers, general-purpose registers, etc. The physical register file unit circuit 1058 overlaps with the retirement unit circuit 1054 (also known as the retirement queue or retirement queue) and demonstrates various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer (ROB) and retirement register file, using a future file, history buffer, and retirement register file, using a register map and register pool, etc.). The retirement unit circuit 1054 and the physical register file circuit 1058 are coupled to an execution cluster 1060. The execution cluster 1060 includes one or more sets of execution unit circuits 1062 and one or more sets of memory access circuits 1064.The execution unit circuit 1062 may perform various arithmetic, logic, floating-point, or other types of operations (e.g., shift, addition, subtraction, multiplication) on various types of data (e.g., scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point). Some embodiments may include many execution units or execution unit circuits dedicated to a particular function or set of functions, while other embodiments may include only one execution unit circuit, or multiple execution units / execution unit circuits that perform all functions. Since certain embodiments form separate pipelines for certain types of data / operations (for example, scalar integer pipelines, scalar floating-point / packed integer / packed floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each having its own scheduler circuit, physical register file unit circuit, and / or execution cluster, and in the case of a separate memory access pipeline, certain embodiments are implemented such that only the execution cluster of this pipeline has the memory access unit circuit 1064), the scheduler circuit 1056, physical register file unit circuit 1058, and execution cluster 1060 are shown as possibly being multiple. It should also be understood that when separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest may be in-order.

[0101] In some embodiments, the execution engine unit circuit 1050 may perform pipeline processing of load / store unit (LSU) address / data to an advanced microcontroller bus (AHB) interface (not shown), address phase and write-back, data phase load, store, and branch.

[0102] A set of memory access circuits 1064 are coupled to a memory unit circuit 1070, which includes a data TLB unit circuit 1072 coupled to a data cache circuit 1074 coupled to a level 2 (L2) cache circuit 1076. In one exemplary embodiment, the memory access unit circuit 1064 may include a load unit circuit, a store address unit circuit, and a store data unit circuit, each of which is coupled to a data TLB circuit 1072 within the memory unit circuit 1070. The instruction cache circuit 1034 is further coupled to a level 2 (L2) cache unit circuit 1076 within the memory unit circuit 1070. In one or more examples, the instruction cache 1034 and data cache 1074 are combined with an L2 cache unit circuit 1076, a level 3 (L3) cache unit circuit (not shown), and / or a single instruction and data cache (not shown) in main memory. The L2 cache unit circuit 1076 is coupled to one or more other levels of caches and ultimately to main memory.

[0103] The Core 1090 may support one or more instruction sets, including the instructions described herein (e.g., the x86 instruction set (with newer versions added and several extensions), the MIPS instruction set, and the ARM instruction set (with optional additional extensions such as NEON). In one or more examples, the Core 1090 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby enabling operations used by many multimedia applications to be performed using packed data. [Example execution unit circuit]

[0104] Figure 11 shows an embodiment of an execution unit circuit, such as the execution unit circuit 1062 in Figure 10B. As shown, the execution unit circuit 1062 may include one or more ALU circuits 1101, a vector / SIMD unit circuit 1103, a load / store unit circuit 1105, and / or a branch / jump unit circuit 1107. The ALU circuit 1101 performs arithmetic and / or Boolean operations. The vector / SIMD unit circuit 1103 performs vector / SIMD operations on packed data (such as SIMD / vector registers). The load / store unit circuit 1105 executes load and store instructions to load data from memory into registers or store data from registers into memory. The load / store unit circuit 1105 may also generate addresses. The branch / jump unit circuit 1107, depending on the instruction, causes a branch or jump to a memory address. The floating-point unit (FPU) circuit 1109 performs floating-point operations. The width of the execution unit circuit 1062 varies depending on the embodiment and can range from 16 bits to 1,024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (for example, two 128-bit execution units are logically combined to form a 256-bit execution unit). [Embodimentary register architecture]

[0105] Figure 12 is a block diagram of the register architecture 1200 according to several embodiments. As shown, there are vector / SIMD registers 1210 whose widths vary from 128 bits to 1,024 bits. In some embodiments, the vector / SIMD registers 1210 are physically 512 bits, and depending on the mapping, only some of the lower bits are used. For example, in some embodiments, the vector / SIMD registers 1210 are ZMM registers that are 512 bits, with the lower 256 bits used for the YMM register and the lower 128 bits used for the XMM register. Thus, there is a register overlay. In some embodiments, the vector length field is selected from the maximum length and one or more other shorter lengths, each of which is half the length of the aforementioned length. Scalar operations are operations performed at the lowest data element positions in the ZMM / YMM / XMM registers, and the higher data element positions are, depending on the embodiment, left in the same state as those prior to the instruction or zeroed out.

[0106] In some embodiments, the register architecture 1200 includes write mask / predicate registers 1215. For example, in some embodiments, there are eight write mask / predicate registers (sometimes referred to as k0 through k7) of sizes 16 bits, 32 bits, 64 bits, or 128 bits, respectively. The write mask / predicate registers 1215 may enable merging (e.g., allowing any set of elements in a destination to be protected from updating during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in a destination to be zeroed out during the execution of any operation). In some embodiments, each data element position in a given write mask / predicate register 1215 corresponds to a data element position in a destination. In other embodiments, the write mask / predicate registers 1215 are scalable and consist of a set number of enable bits for a given vector element (e.g., 8 enable bits for every 64-bit vector element).

[0107] The register architecture 1200 includes several general-purpose registers 1225. These registers may be 16-bit, 32-bit, 64-bit, 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 through R15.

[0108] In some embodiments, the register architecture 1200 includes scalar floating-point registers 1245 used for scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions or MMX registers, for performing operations on 64-bit packed integer data and for holding operands for some operations performed between MMX and XMM registers.

[0109] One or more flag registers 1240 (e.g., EFLAGS, RFLAGS, etc.) store status and control information related to arithmetic operations, comparison operations, and system operations. For example, one or more flag registers 1240 may store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some embodiments, one or more flag registers 1240 are called program status and control registers.

[0110] The segment register 1220 contains segment points used for accessing memory. In some embodiments, these registers are referred to as CS, DS, SS, ES, FS, and GS.

[0111] The machine-specific registers (MSRs) 1235 control and report on processor performance. Most MSRs 1235 handle system-related functions but are not accessible to application programs. The machine check registers 1260 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0112] One or more instruction pointer registers 1230 store instruction pointer values. Control registers 1255 (e.g., CR0-CR4) determine the processor's operating mode (e.g., processors 870, 880, 838, 815, and / or 900) and the characteristics of the currently executing task. Debug registers 1250 control and enable monitoring of the debugging operation of the processor or core.

[0113] The memory management register 1265 specifies the location of data structures used for protected mode memory management. These registers may include the GDTR, IDRT, task register, and LDTR register.

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

[0115] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may, among other things, define various fields (e.g., number of bits, bit positions) that specify the operation to be performed (e.g., opcode) and the operand on which that operation should be performed, as well as / or other data fields (e.g., mask). Some instruction formats can be further broken down through the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined to have a different subset of the fields of the instruction format (the included fields are usually in the same order, but have fewer included fields and therefore have at least some different bit positions), and / or to be defined so that the given fields are interpreted differently. Thus, each instruction in an ISA is expressed using a given instruction format (and, if defined, a given one of the instruction templates of that instruction format) and includes fields for specifying the operation and operands. For example, an exemplary ADD instruction has an instruction format that includes a specific opcode, an opcode field that specifies the opcode, and an operand field that selects operands (source 1 / destination and source 2). When this ADD instruction occurs in the instruction stream, the operand field that selects the specific operand has specific content. [Example command format]

[0116] The embodiments of the instructions described herein may be embodied in different formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. The embodiments of the instructions may be executed on, but are not limited to, such systems, architectures, and pipelines.

[0117] Figure 13 shows an embodiment of the instruction format. As shown, the instruction may include, but is not limited to, one or more fields for one or more prefixes 1301, opcodes 1303, addressing information 1305 (e.g., register identifiers, memory addressing information, etc.), displacement values ​​1307, and / or immediate values ​​1309, and may include multiple components. Note that some instructions may utilize some or all of the fields of the format, while others may only use the field for opcode 1303. In some embodiments, the order shown is the order in which those fields should be encoded; however, in other embodiments, it should be understood that those fields may be encoded in a different order, in combination, etc.

[0118] The prefix field 1301 modifies instructions when used. In some examples, one or more prefixes are used to perform bus locking operations to provide section overrides (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.) to iterate over string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), and / or to modify operands (e.g., 0x66) and address sizes (e.g., 0x67). Certain instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Certain of these prefixes may be considered “legacy” prefixes. Other prefixes, one or more of which are detailed herein, exhibit and / or provide further capabilities, such as specifying certain registers. Other prefixes typically follow the “legacy” prefix.

[0119] The opcode field 1303 is used to define, at least partially, the operations to be performed when decoding the instruction. In some embodiments, the primary opcode encoded in the opcode field 1303 is 1, 2, or 3 bytes long. In other embodiments, the primary opcode may be of a different length. An additional 3-bit opcode field may be encoded in another field, if applicable.

[0120] The addressing field 1305 is used to address one or more operands of an instruction, such as locations in memory or one or more registers. Figure 14 shows an embodiment of the addressing field 1305. In this explanatory diagram, the optional ModR / M byte 1402 and the optional Scale, Index, Base (SIB) byte 1404 are shown. The ModR / M byte 1402 and the SIB byte 1404 are used to encode instructions with up to two operands, each of which is a direct register or valid memory address. Note that each of these fields is optional, and not all instructions will contain one or more of these fields. The MOD R / M byte 1402 includes the MOD field 1442, the register field 1444, and the R / M field 1446.

[0121] The content of the MOD field 1442 distinguishes between memory access mode and non-memory access mode. In some embodiments, if the MOD field 1442 has the value of b11, register direct addressing mode is used; otherwise, register indirect addressing is used.

[0122] Register field 1444 may encode either a destination register operand or a source register operand, or an opcode extension, but cannot be used to encode any instruction operand. The contents of register index field 1444 specify the location of the source or destination operand (either in the register or in memory), either directly or via address generation. In some embodiments, register field 1444 is supplemented with additional bits from a prefix (e.g., prefix 1301) to enable larger addressing.

[0123] The R / M field 1446 may be used to encode an instruction operand that references a memory address, or it may be used to encode either a destination register operand or a source register operand. Note that in some embodiments, the R / M field 1446 may be combined with the MOD field 1442 to define the addressing mode.

[0124] SIB byte 1404 contains a scale field 1452, an index field 1454, and a base field 1456, which are used to generate addresses. The scale field 1452 indicates the scaling factor. The index field 1454 specifies the index register to use. In some embodiments, the index field 1454 is supplemented with extra bits from a prefix (e.g., prefix 1301) to enable larger addressing. The base field 1456 specifies the base register to use. In some embodiments, the base field 1456 is supplemented with extra bits from a prefix (e.g., prefix 1301) to enable larger addressing. In practice, the contents of the scale field 1452 allow scaling of the contents of the index field 1454 for memory address generation (e.g., 2 スケール (*Address generation using index + base)

[0125] Some addressing formats use displacement values ​​to generate memory addresses. For example, a memory address can be 2 スケール*The displacement may be generated according to *index + base + displacement, *index * scale + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a value of 1 byte, 2 bytes, 4 bytes, etc. In some embodiments, the displacement field 1307 provides this value. Furthermore, in some embodiments, the use of a displacement coefficient is encoded in the MOD field of the addressing field 1305, which indicates a compressed displacement scheme in which the displacement value is calculated by multiplying disp8 in combination with a scaling coefficient N determined based on the vector length, the value of the b bit, and the size of the instruction's input elements. The displacement field 1307 stores the displacement value.

[0126] In some embodiments, the immediate value field 1309 specifies the immediate value of the instruction. The immediate value may be encoded as a 1-byte, 2-byte, 4-byte, or the like.

[0127] Figure 15 shows an embodiment of the first prefix 1301(A). In some embodiments, the first prefix 1301(A) is an example of a REX prefix. Instructions using this prefix may specify general-purpose registers, 64-bit packed data registers (e.g., single-instruction multiplexed data (SIMD) registers, or vector registers), and / or control and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0128] Instructions using the first prefix 1301(A) may specify up to three registers using 3-bit fields, depending on the following format: 1) using the reg field 1444 and R / M field 1446 of Mod R / M byte 1402; 2) using Mod R / M byte 1402 together with SIB byte 1404, including using the reg field 1444, base field 1456, and index field 1454; or 3) using the register fields of the opcode.

[0129] In the first prefix 1301(A), bit positions 7:4 are set to 0100. Bit position 3(W) may be used to determine the operand size, but not only the operand width. Thus, if W=0, the operand size is determined by the code segment descriptor (CS.D), and if W=1, the operand size is 64 bits.

[0130] MOD R / M reg field 1444 and MOD R / MR / M field 1446 can address only 8 registers each individually, but with the addition of another bit, 16(2 4 Note that this allows the registers of ) to be addressed.

[0131] In the first prefix 1301(A), bit position 2(R) may be an extension of the MOD R / M reg field 1444, which may be used to modify the ModR / M reg field 1444 if that field encodes a general-purpose register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. R is ignored if the Mod R / M byte 1402 specifies another register or defines an extended opcode.

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

[0133] Bit position B(B)B may modify the base of the Mod R / MR / M field 1446 or the SIB byte base field 1456, or it may modify the opcode register field used to access a general-purpose register (e.g., general-purpose register 1225).

[0134] Figures 16A to 16D illustrate embodiments of how the R, X, and B fields of the first prefix 1301(A) are used. Figure 16A shows the R and B from the first prefix 1301(A) used to extend the reg field 1444 and R / M field 1446 of the MOD R / M byte 1402 when the SIB byte 1404 is not used for memory addressing. Figure 16B shows the R and B from the first prefix 1301(A) used to extend the reg field 1444 and R / M field 1446 of the MOD R / M byte 1402 when the SIB byte 1404 is not used (register-to-register addressing). Figure 16C shows the R, X, and B from the first prefix 1301(A) used to extend the reg field 1444, index field 1454, and base field 1456 of the MOD R / M byte 1402 when the SIB byte 1404 is used for memory addressing. Figure 16D shows the B from the first prefix 1301(A) used to extend the reg field 1444 of the MOD R / M byte 1402 when the register is encoded in opcode 1303.

[0135] Figures 17A and 17B illustrate embodiments of the second prefix 1301(B). In some embodiments, the second prefix 1301(B) is an example of a VEX prefix. Encoding the second prefix 1301(B) allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD register 1210) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1301(B) provides a three-operand (or more) syntax. For example, previous two-operand instructions performed operations such as A=A+B, which overwrote the source operand. The use of the second prefix 1301(B) allows operands to perform non-destructive operations such as A=B+C.

[0136] In some embodiments, the second prefix 1301(B) has two forms: a 2-byte form and a 3-byte form. The 2-byte second prefix 1301(B) is mainly used for 128-bit, scalar, and some 256-bit instructions, while the 3-byte second prefix 1301(B) provides a compact alternative to the first prefix 1301(A) and 3-byte opcode instructions.

[0137] Figure 17A shows an embodiment of the second prefix 1301(B) in 2-byte format. In one example, the format field 1701 (byte 0 1703) contains the value C5H. In another example, byte 1 1705 contains the value "R" in bit[7]. This value is the complement of the same value in the first prefix 1301(A). Bit[2] is used to specify the length (L) of the vector (a value of 0 is a scalar or a 128-bit vector, and a value of 1 is a 256-bit vector). Bit[1:0] provides opcodes that are extensional equivalents to several legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bit[6:3], shown as vvvv, can be used as follows: 1) Encodes the first source register operand, specified in inverted (one's complement) form and valid for instructions with two or more source operands. 2) Encodes the destination register operand, specified in one's complement form for a specific vector shift. Or, 3) Does not encode any operands, and the field is reserved and should contain a specific value such as 1111b.

[0138] Instructions using this prefix may use Mod R / MR / M field 1446 to encode an instruction operand that references a memory address, or they may encode either a destination register operand or a source register operand.

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

[0140] For the instruction syntax vvvv, which supports four operands, the Mod R / MR / M field 1446 and Mod R / M reg field 1444 encode three of the four operands. The bits [7:4] of the immediate value 1309 are then used to encode the third source register operand.

[0141] Figure 17B shows an embodiment of the second prefix 1301(B) in 3-byte format. In one example, the format field 1711 (byte 0 1713) contains the value C4H. Byte 1 1715 contains, in bits [7:5], the complements of the same value of the first prefix 1301(A): "R", "X", and "B". Bits [4:0] of Byte 1 1715 (shown as mmmmm) contain content that optionally encodes one or more suggested leading opcode bytes. For example, 00001 suggests the 0FH leading opcode, 00010 suggests the 0F38H leading opcode, 00011 suggests the leading 0F3AH opcode, and so on.

[0142] Bits [7] of byte 2 1717 are used similarly to the W of the first prefix 1301(A), including to help determine the size of the promoteable operand. Bit [2] is used to specify the length (L) of the vector (a value of 0 is a scalar or a 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcodes with extensional equivalents to several legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], indicated as vvvv, may be used as follows: 1) Encodes the first source register operand, specified in inverted (one's complement) form and valid for instructions with two or more source operands. 2) Encodes the destination register operand, specified in one's complement form for a particular vector shift. Alternatively, 3) Do not encode any operands, and the field should be reserved and contain a specific value such as 1111b.

[0143] Instructions using this prefix may use Mod R / MR / M field 1446 to encode an instruction operand that references a memory address, or they may encode either a destination register operand or a source register operand.

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

[0145] For the instruction syntax vvvv, which supports four operands, the Mod R / MR / M field 1446 and Mod R / M reg field 1444 encode three of the four operands. The bits [7:4] of the immediate value 1309 are then used to encode the third source register operand.

[0146] Figure 18 shows an embodiment of the third prefix 1301(C). In some embodiments, the first prefix 1301(A) is an example of an EVEX prefix. The third prefix 1301(C) is a 4-byte prefix.

[0147] The third prefix 1301(C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some embodiments, instructions that utilize write masks / operational masks (see the register descriptions in previous figures such as Figure 12) or predications utilize this prefix. Operational mask registers enable conditional processing or selection control. Operational mask instructions whose source / destination operands are operational mask registers and which treat the contents of operational mask registers as a single value are encoded using the second prefix 1301(B).

[0148] The third prefix 1301(C) can encode features specific to an instruction class (for example, packed instructions with "load + op" semantics may support embedded broadcast functionality, floating-point instructions with rounding semantics may support static rounding functionality, and floating-point instructions with non-rounding arithmetic semantics may support "all exception suppression" functionality).

[0149] The first byte of the third prefix 1301(C) is the format field 1811, which in one example has a value of 62H. Subsequent bytes are referred to as payload bytes 1815-1819 and collectively form 24-bit values ​​of P[23:0] that provide specific functionality in the form of one or more fields (as detailed herein).

[0150] In some embodiments, P[1:0] of payload byte 1819 is identical to the two lower mmmm bits. P[3:2] is reserved in some embodiments. Bit P[4](R') enables access to the upper 16 vector register set when combined with P[7] and ModR / M reg field 1444. P[6] may 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 designation modification bits for vector registers, general-purpose registers, and memory addressing, and when combined with ModR / M register field 1444 and ModR / MR / M field 1446, enables access to the next set of eight registers beyond the lower eight registers. P[9:8] provides several legacy prefixes and extensional equivalent opcodes (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], denoted as vvvv, may be used for: 1) encoding a first source register operand, specified in inverted (one's complement) form and valid for instructions with two or more source operands; 2) encoding a destination register operand, specified in one's complement form for a particular vector shift; or 3) not encoding any operand, with the field reserved and to contain a specific value such as 1111b.

[0151] P

[15] is similar to W in the first prefix 1301(A) and the second prefix 1311(B), and may function as an opcode extension bit or operand size promotion.

[0152] P[18:16] specifies the index of the register in the opmask (write mask) register (e.g., write mask / predicate register 1215). In one or more examples of the present invention, a particular value aaa=000 has special behavior that suggests a non-opmask is used for a particular instruction (this can be implemented in various ways, including the use of a hardwired opmask for all 1s, or the use of hardware that bypasses 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 basic and extended operations), and in one or more other examples, the old value of each element of the destination is preserved 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 out during the execution of any operation (specified by basic and extended operations), and in one or more examples, the elements of the destination are set to 0 if the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the range of elements being modified from the first to the last element), however the elements being modified do not need to be contiguous. Thus, the opmask field enables partial vector operations, including load, store, arithmetic, and logic. Embodiments of the invention have been described in which the contents of the opmask field select one of many opmask registers containing the opmask to be used (and thus the contents of the opmask field indirectly identify the masking to be performed), but alternative embodiments allow the contents of the mask write field to directly specify the masking to be performed, either instead or in addition to this.

[0153] P

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

[19] . P

[20] encodes several functions that vary across different instruction classes and may affect the meaning of the vector length / rounding control specification 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).

[0154] Exemplary embodiments of register encoding in instructions using the third prefix 1301(C) are detailed in the following table. [Table 1] [Table 2] [Table 3]

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

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

[0157] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation methods. Embodiments of the present invention may be implemented as a computer program or program code that runs on a programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0158] At least one or more embodiments of one or more examples may be implemented by representative instructions stored on a machine-readable medium that represent various logics within a processor, and when read by a machine, cause the machine to generate logic for performing the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into manufacturing machines that actually create the logic or processor.

[0159] Such machine-readable storage media may include, but are not limited to, articles of non-temporary, tangible structure manufactured or formed by a machine or device, including storage media such as hard disks, floppy disks, optical disks, compact disk read-only memory (CD-ROM), rewritable compact disks (CD-RW), and other types of disks such as magneto-optical disks; random access memory (RAM) such as read-only memory (ROM), dynamic random access memory (DRAM), static random access memory (SRAM); semiconductor devices such as erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), and phase-change memory (PCM); magnetic or optical cards; or other types of media suitable for storing electronic instructions.

[0160] Accordingly, embodiments of the present invention also include non-temporary tangible machine-readable media containing instructions such as a hardware description language (HDL) that define structures, circuits, devices, processors, and / or system functions described herein, or design data. Such embodiments may also be referred to as program products. [Emulation (including binary conversion, code morphing, etc.)]

[0161] In some cases, instruction converters may be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction converter can translate an instruction to one or more other instructions to be processed by the core (e.g., using static binary translation, dynamic binary translation including dynamic compilation), morph, emulate, or otherwise translate it. Instruction converters may be implemented in software, hardware, firmware, or a combination thereof. Instruction converters may be on-processor, off-processor, or partially on-processor and partially off-processor.

[0162] Figure 19 shows a block diagram illustrating the use of a software instruction converter to translate binary instructions in a source instruction set to binary instructions in a target instruction set, according to an embodiment of the present invention. In the shown 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. Figure 19 shows that a program in a high-level language 1902 can be compiled using a first ISA compiler 1904 to produce a first ISA binary code 1906 that can be executed natively by a processor 1916 having at least one first instruction set core. A processor 1916 having at least one first ISA instruction set core represents any processor capable of performing substantially the same functions as an Intel processor having at least one first ISA instruction set core by (1) a substantial portion of the instruction set of the first ISA instruction set core, or (2) a compatible execution or alternative processing of a version of the object code of an application or other software targeted to run on an Intel® processor having at least one first ISA instruction set core, in order to achieve substantially the same results as a processor having at least one first ISA instruction set core. A first ISA compiler 1904 represents a compiler capable of generating first ISA binary code 1906 (e.g., object code) that can be executed on a processor 1916 having at least one first ISA instruction set core, with or without additional linkage processing. Similarly, Figure 19 shows that a program in high-level language 1902 can be compiled using an alternative instruction set compiler 1908 to produce alternative instruction set binary code 1910 that can be natively executed by a processor 1914 without the first ISA instruction set core. An instruction converter 1912 is used to convert the first ISA binary code 1906 into code that can be natively executed by the processor 1914 without the first ISA instruction set core.This converted code is unlikely to be identical to the alternative instruction set binary code 1910 because it would be difficult to create an instruction converter that would make this possible; however, the converted code implements common operations and is composed of instructions from the alternative instruction set. Thus, instruction converter 1912 represents software, firmware, hardware, or a combination thereof that enables a processor or other electronic device that does not have the first ISA instruction set processor or core to execute the first ISA binary code 1906 through emulation, simulation, or any other process.

[0163] References such as "one or more examples," "an example," or "an exemplary embodiment" indicate that the described embodiment may include certain features, structures, or characteristics, but not all embodiments necessarily include those specific features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, if a particular feature, structure, or characteristic is described in relation to one example, it is considered within the knowledge of those skilled in the art that such features, structures, or characteristics will be affected in relation to other embodiments, whether or not they are explicitly stated.

[0164] Examples include, but are not limited to, the following. 1. An encryption / decryption engine for encrypting or decrypting data, It comprises an encryption data structure engine for providing keys, data, and fine-tuning to the encryption / decryption engine, and the encryption data structure engine is The address is used to read the index value from the encrypted data structure lookup data structure entry, where the entry contains the index value and the guest page physical address (GPPA). Based on the index value, an entry is retrieved from the cryptographic data structure, and the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. A series of encrypted data structure lookup data structure entries in GPPA are used to generate an LBA using the GPPA location. The encryption / decryption engine retrieves a key based on the key identifier and uses the retrieved key and the generated LBA to encrypt or decrypt the data. Device. 2. The address is the guest physical address of the device described in Example 1. 3. The guest physical address is part of the transport layer packet, as described in Example 2 for the device. 4. The apparatus described in any of Examples 1-3 generates an intermediate result by multiplying the GPPA position by the block size, and the LBA value is that intermediate result added to the LBA base. 5. If the block size is 512b, the device described in any of Examples 1-3 generates an intermediate result by multiplying the GPPA position by the block size * 8, takes the address, ANDs it with 0XFFFF, then calculates the offset by shifting by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result. 6. The encryption is AES_XTS, as described in any of the examples 1-5. 7. Decryption is AES_XTS, using one of the devices described in Examples 1-5. 8. Dynamic random access memory for storing encrypted data structures, An encryption engine for encrypting data, It comprises an encryption data structure engine for providing keys, data, and fine-tuning to the encryption / decryption engine, and the encryption data structure engine is The address is used to read the index value from the encrypted data structure lookup data structure entry, where the entry contains the index value and the guest page physical address (GPPA). Based on the index value, an entry is retrieved from the cryptographic data structure, and the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. A series of encrypted data structure lookup data structure entries in GPPA are used to generate an LBA using the GPPA location. The encryption engine retrieves a key based on the key identifier and uses the retrieved key and the generated LBA to encrypt the data. system. 9. The address is the guest physical address, as described in Example 8. 10. The guest physical address is part of the transport layer packet, as described in Example 9. 11. If the block size is 4KB, multiply the GPPA position by the block size to generate an intermediate result, and the LBA value is that intermediate result added to the LBA base, as described in any of the systems in Examples 8-10. 12. If the block size is 512b, the system described in any of Examples 8-10 generates an intermediate result by multiplying the GPPA position by the block size * 8, takes the address, ANDs it with 0XFFFF, then calculates the offset by shifting by 7, and the LBA is the offset multiplied by 512 and the intermediate result added. 13. The encryption is AES_XTS, as described in any of the examples 8-12. 14. Use the address to look up the encrypted data structure. Read the index value from the data structure entry, where the entry contains the index value and the guest page physical address (GPPA). Based on the index value, an entry is retrieved from the cryptographic data structure, and the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. A series of encrypted data structure lookup data structure entries in GPPA are used to generate an LBA using the GPPA location. Based on the key identifier, the encryption / decryption engine retrieves the key and uses the retrieved key and the generated LBA to encrypt or decrypt the data. Encrypting or decrypting data, Methods that include... 15. The address is the guest physical address, as described in Example 14. 16. The guest physical address is part of the transport layer packet, as described in Example 15. 17. Generate an intermediate result by multiplying the GPPA position by the block size, and the LBA value is that intermediate result added to the LBA base, as described in any of Examples 14-16. 18. If the block size is 512b, multiply the GPPA position by the block size * 8 to generate an intermediate result, take the address, AND it with 0XFFFF, then shift by 7 to calculate the offset, and the LBA is the offset multiplied by 512 and the intermediate result added, as in any of Examples 14-16. 19. Encryption is AES_XTS, as described in any of Examples 14-18. 20. Decryption is AES_XTS, using any of the methods in Examples 14-18.

[0165] Furthermore, in the various embodiments described above, unless otherwise specifically stated, disjunctive phrases such as "at least one of A, B, or C" are intended to be understood to mean any one of A, B, or C, or any combination thereof (e.g., A, B, and / or C). Accordingly, disjunctive phrases are not intended, nor should they be understood, to mean that each given embodiment requires at least one of A, at least one of B, or at least one of C to exist.

[0166] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will be clear that various modifications and changes may be made to them without departing from the broader intent and scope of the disclosure as described in the claims. [Other adjacent items] (Item 1) An encryption / decryption engine for encrypting or decrypting data, The encryption / decryption engine comprises an encryption data structure engine for providing keys, data, and fine-tuning, wherein the encryption data structure engine Using the address, read the index value from the encrypted data structure lookup data structure entry, the entry containing the index value and the guest page physical address (GPPA), Based on the aforementioned index value, an entry is retrieved from the cryptographic data structure, the entry comprising a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. Using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, The encryption / decryption engine obtains a key based on the key identifier, and uses the obtained key and the generated LBA to encrypt or decrypt the data. Device. (Item 2) The aforementioned address is the guest physical address of the device described in item 1. (Item 3) The aforementioned guest physical address is part of a transport layer packet, as described in item 2. (Item 4) The apparatus according to item 1, wherein an intermediate result is generated by multiplying the GPPA position by the block size, and the LBA value is the intermediate result added to the LBA base. (Item 5) The apparatus described in item 1, wherein, if the block size is 512b, an intermediate result is generated by multiplying the GPPA position by the block size * 8, the address is taken, ANDed with 0XFFFF, and then the offset is calculated by shifting by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result. (Item 6) The encryption method is AES_XTS, as described in item 1. (Item 7) The aforementioned decoding is AES_XTS, as described in item 1. (Item 8) Dynamic random access memory for storing encrypted data structures, An encryption engine for encrypting data, The encryption / decryption engine comprises an encryption data structure engine for providing keys, data, and fine-tuning, wherein the encryption data structure engine Using the address, read the index value from the encrypted data structure lookup data structure entry, the entry containing the index value and the guest page physical address (GPPA), Based on the aforementioned index value, an entry is obtained from the aforementioned cryptographic data structure, the entry comprising a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs, Using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, The encryption engine obtains a key based on the key identifier, and uses the obtained key and the generated LBA to encrypt the data. system. (Item 9) The aforementioned address is the guest physical address of the system described in item 8. (Item 10) The aforementioned guest physical address is part of a transport layer packet, as described in item 9. (Item 11) The system described in item 8, wherein if the block size is 4KB, the GPPA position is multiplied by the block size to generate an intermediate result, and the LBA value is that intermediate result added to the LBA base. (Item 12) The system described in item 8, wherein if the block size is 512b, the GPPA position is multiplied by the block size * 8 to generate an intermediate result, the address is taken, ANDed with 0XFFFF, and then the offset is calculated by shifting by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result. (Item 13) The encryption is AES_XTS, as described in item 8. (Item 14) Using the address, read the index value from the encrypted data structure lookup data structure entry, the entry containing the index value and the guest page physical address (GPPA), Based on the aforementioned index value, an entry is retrieved from the cryptographic data structure, the entry comprising a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. Using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, Based on the key identifier, the encryption / decryption engine obtains a key, and uses the obtained key and the generated LBA to encrypt or decrypt the data. Encrypting or decrypting the aforementioned data, Methods that include... (Item 15) The aforementioned address is the guest physical address, as described in item 14. (Item 16) The guest physical address is part of the transport layer packet, as described in item 15. (Item 17) The method according to item 14, wherein an intermediate result is generated by multiplying the GPPA position by the block size, and the LBA value is the intermediate result added to the LBA base. (Item 18) The method according to item 14, wherein, if the block size is 512b, the GPPA position is multiplied by the block size * 8 to generate an intermediate result, the address is taken, ANDed with 0XFFFF, and then the offset is calculated by shifting by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result. (Item 19) The encryption method described in item 14 is AES_XTS. (Item 20) The aforementioned decoding is AES_XTS, as described in item 14.

Claims

1. An encryption / decryption engine means for encrypting or decrypting data, An encryption data structure engine means for providing keys, data, and fine-tuning to the encryption / decryption engine, wherein the encryption data structure engine means is Reading an index value from an encrypted data structure lookup data structure entry using an address, wherein the encrypted data structure lookup data structure entry includes an index value and a guest page physical address (GPPA), and The process of obtaining an entry from an encrypted data structure based on the aforementioned index value, wherein the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. To generate an LBA using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, The process involves obtaining a key based on the aforementioned key identifier, wherein the encryption / decryption engine uses the obtained key and the generated LBA to encrypt or decrypt data. This is an encryption data structure engine means for performing the following: A device equipped with the following features.

2. The apparatus according to claim 1, wherein the address is the guest physical address.

3. The apparatus according to claim 2, wherein the guest physical address is part of a transport layer packet.

4. The apparatus according to claim 1 or 2, wherein an intermediate result is generated by multiplying the position of the GPPA by the block size, and the value of the LBA is the intermediate result added to the base of the LBA.

5. The apparatus according to any one of claims 1 to 3, wherein, when the block size is 512b, an intermediate result is generated by multiplying the position of the GPPA by the block size multiplied by 8, the address is taken, and the offset is calculated by ANDing it with 0XFFFF and then shifting it by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result.

6. The apparatus according to any one of claims 1 to 3, wherein the encryption is AES_XTS.

7. The apparatus according to any one of claims 1 to 3, wherein the decoding is AES_XTS.

8. Dynamic random access memory for storing encrypted data structures, An encryption engine means for encrypting data, An encryption data structure engine means for providing keys, data, and fine-tuning to the encryption / decryption engine, wherein the encryption data structure engine means is Reading an index value from an encrypted data structure lookup data structure entry using an address, wherein the encrypted data structure lookup data structure entry includes an index value and a guest page physical address (GPPA), and Obtaining an entry from the cryptographic data structure based on the aforementioned index value, wherein the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. To generate an LBA using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, The process involves obtaining a key based on the key identifier, and the encryption engine means uses the obtained key and the generated LBA to encrypt the data. This is an encryption data structure engine means for performing the following: A system equipped with these features.

9. The system according to claim 8, wherein the aforementioned address is a guest physical address.

10. The system according to claim 9, wherein the guest physical address is part of a transport layer packet.

11. The system according to any one of claims 8 to 10, wherein, if the block size is 4KB, the GPPA position is multiplied by the block size to generate an intermediate result, and the LBA value is the intermediate result added to the base of the LBA.

12. The system according to any one of claims 8 to 10, wherein, when the block size is 512b, an intermediate result is generated by multiplying the position of the GPPA by the block size multiplied by 8, the address is taken, and the offset is calculated by ANDing it with 0XFFFF and then shifting it by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result.

13. The system according to any one of claims 8 to 10, wherein the encryption is AES_XTS.

14. A reading step in which an index value is read from an encrypted data structure lookup data structure entry using an address, wherein the encrypted data structure lookup data structure entry includes an index value and a guest page physical address (GPPA), A step of obtaining an entry from an encrypted data structure based on the aforementioned index value, wherein the entry includes a logical block address (LBA) base, a key identifier, and at least one GPPA from a set of GPPAs. A step of generating an LBA using the location of the GPPA from the encrypted data structure lookup data structure entries in the series of GPPAs, A step of obtaining a key based on the key identifier, wherein the encryption / decryption engine encrypts or decrypts data using the obtained key and the generated LBA, The steps of encrypting or decrypting the aforementioned data, A method for providing this.

15. The method according to claim 14, wherein the address is a guest physical address.

16. The method according to claim 15, wherein the guest physical address is part of a transport layer packet.

17. The method according to any one of claims 14 to 16, wherein an intermediate result is generated by multiplying the position of the GPPA by the block size, and the value of the LBA is the intermediate result added to the base of the LBA.

18. The method according to any one of claims 14 to 16, wherein, when the block size is 512b, an intermediate result is generated by multiplying the position of the GPPA by the block size multiplied by 8, the address is taken, and the offset is calculated by performing an AND operation with 0XFFFF and then shifting by 7, and the LBA is obtained by multiplying the offset by 512 and adding the intermediate result.

19. The method according to any one of claims 14 to 16, wherein the encryption is AES_XTS.

20. The method according to any one of claims 14 to 16, wherein the decoding is AES_XTS.

Images