Patent Publication Number: US-2023161588-A1

Title: Processor and method for flushing translation lookaside buffer according to designated key identification code

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims priority of China Patent Application No. 202111375304.2, filed on Nov. 19, 2021, the entirety of which is incorporated by reference herein. 
     BACKGROUND 
     Technical Field 
     The present application relates to management for a translation lookaside buffer (abbreviated as TLB) of a processor. 
     Description of the Related Art 
     A translation lookaside buffer (TLB), also known as a page table cache or a transfer bypass cache, is a kind of cache in a central processing unit that speeds up access to the system memory, and improves the conversion speed from a virtual address (VA) to a physical address (PA) for accessing system memory. Each entry in the translation lookaside buffer (TLB) stores mapping data that maps a virtual address (VA) to a physical address (PA). Generally, the virtual address (VA) is used as an input to search the translation lookaside buffer (TLB), and the search result is the mapped physical address (PA). If the mapping data for the input virtual address (VA) exists in the translation lookaside buffer (TLB), the mapped physical address (PA) is read from the translation lookaside buffer (TLB) and used to access the system memory. This improves the access speed to the system memory. If the mapping data for the input virtual address (VA) does not exist in the translation lookaside buffer (TLB), system resources need to be spent in a table walk (a process that involves searching the multi-level page tables that are stored in the system memory and/or the associated cache structure), which can be time-consuming. 
     The concept of translation lookaside buffer (TLB) may be used in various types of system memory accessing technologies, such as an instruction translation lookaside buffer (ITLB) or a data translation lookaside buffer (DTLB). 
     In order to protect confidential and/or sensitive data, a total memory encryption function is used in the prior art, using multiple keys to encrypt system memory. Based on the total memory encryption, the different memory spaces protected by the different keys are managed separately. However, the translation lookaside buffer (TLB) is still not managed in the granularity of keys (not managed according to the keys). The operating System (OS) is incapable of managing the translation lookaside buffer (TLB) in the granularity of keys, and therefore it is also incapable of flushing the translation lookaside buffer (TLB) based on designated keys. 
     BRIEF SUMMARY 
     In order to solve the above problem, this case proposes a technology for managing the translation lookaside buffer (TLB) in the granularity of keys. 
     A processor in accordance with an exemplary embodiment of the present application includes a memory order buffer (MOB), a translation lookaside buffer (TLB), and a decoder. The memory order buffer (MOB) is configured as a communication interface between the processor and a system memory. The translation lookaside buffer (TLB) has a plurality of entries cached therein, which are searched by the processor to access the system memory. In response to an instruction that is in an instruction set architecture (ISA) and provided to flush (e.g., clear) the translation lookaside buffer (TLB) based on a designated key identification code (designated key ID), the decoder decodes the instruction to provide at least one microinstruction. There may be a flushing microinstruction included in the at least one microinstruction. By executing the flushing microinstruction, the designated key ID is provided to a control logic circuit of the translation lookaside buffer (TLB) through the memory order buffer (MOB). The control logic circuit flushes matched entries in the translation lookaside buffer (TLB), wherein the matched entries match the designated key ID. 
     A method for flushing a translation lookaside buffer (TLB) based on a designated key ID is shown in an exemplary embodiment of the present application, which includes the following actions. In response to an instruction that is in an instruction set architecture (ISA) and provided to flush the translation lookaside buffer (TLB) based on the designated key ID, the instruction is decoded to provide at least one microinstruction. There may be a flushing microinstruction included in the at least one microinstruction. By executing the flushing microinstruction, the designated key ID is provided to a control logic circuit of the translation lookaside buffer (TLB) through a memory order buffer (MOB), to operate the control logic circuit to flush matched entries in the translation lookaside buffer (TLB), wherein the matched entries match the designated key ID. 
     A detailed description is given in the following embodiments with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present application can be more fully understood by reading the subsequent detailed description and examples with references made to the accompanying drawings, wherein: 
         FIG.  1 A  shows an instruction structure of the instruction INVL_KEYID in accordance with an exemplary embodiment of the present application; 
         FIG.  1 B  is a block diagram illustrating a processor  100  in accordance with an exemplary embodiment of the present application; 
         FIGS.  2 A to  2 D  illustrate the TLB entry structure in accordance with various exemplary embodiments of the present application; 
         FIGS.  3 A to  3 C  show how to fill the TLB entries (referring to the structure of  FIG.  2 D ) of the TLB table  118  when the mapping table  248  is full; 
         FIG.  4    is a block diagram illustrating a control logic circuit  302  of the TLB  117  in accordance with an exemplary embodiment of the present application; and 
         FIG.  5    is an instruction format of the instruction INVL_KEYID. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is best determined by reference to the appended claims. 
     Nowadays, computer technology often has a virtual machine (VM) design. Multiple virtual machines may be established on a single physical machine. Each virtual machine includes at least one virtual processor (VP), and has its own operating system (OS) and applications. The different virtual machines are separated from each other and do not interfere with each other. Each virtual machine has a corresponding system memory space for use. In an exemplary embodiment, when a total memory encryption function is enabled, the different system memory spaces assigned to (or read/write by) the different virtual processors of a virtual machine are protected by the different keys. The security among the virtual processors is improved. Each key may be represented by a key identification code (key ID). A computer system may include a key table that lists the relationship between the keys and the key IDs. During encryption, the key corresponding to each key ID may be obtained by querying the key table. In another exemplary embodiment, the different system memory spaces are separately encrypted to correspond to the different threads (corresponding to the different services or applications operated by the operating system) running on a single virtual processor, and thereby the security of the different threads run by the same virtual processor is improved. In an example, a virtual machine VM 0  includes a virtual processor with a virtual processor identifier (VPID) VP0, and the virtual processor VP0 runs two threads with process context identifiers P0 and P1. The thread P0 may be protected by key  1  (with a key ID KeyID0), and the thread P1 may be protected by key  2  (with a key ID KeyID1). The security between the threads P0 and P1 run by the virtual processor VP0 is improved by the two different keys KeyID0 and KeyID1. 
     Based on the full memory encryption of the system memory (using the different keys to encrypt the different system memory spaces), the translation lookaside buffer (TLB) of the processor is managed according to the key IDs in the present application. Specifically, the translation lookaside buffer (TLB) may be flushed (e.g., cleared) according a designated key ID (Key_ID_S), which is different from the other flushing techniques for the translation lookaside buffer (TLB). The other flushing techniques may be: flush the whole entire translation lookaside buffer (TLB); or, flush the translation lookaside buffer (TLB) according to a process context identifier (PCID, for identification of a thread), a virtual processor identifier (VPID, for identification of a virtual processor), or an extended page table pointer (EPTP). In the proposed solution, if the total memory encryption function is enabled, the translation lookaside buffer (TLB) is managed in granularity of key IDs. Only the TLB entries that match a designated key ID are flushed. The TLB entries irrelevant to the designated key ID are not flushed. 
     In an exemplary embodiment, a processor that manages a translation lookaside buffer (TLB) in granularity of key IDs is proposed, wherein an instruction set architecture (ISA) instruction INVL_KEYID is required. The instruction INVL_KEYID has an operand that indicates a designated key ID Key_ID_S. By executing the instruction INVL_KEYID, the translation lookaside buffer (TLB) is flushed based on the designated key ID Key_ID_S. The instruction set architecture (ISA) supported by the processor is not limited, it may be an x86 ISA, an advanced RISC machine (abbreviated as ARM) ISA, a microprocessor without interlocked pipeline stages (abbreviated as MIPS) ISA, a RISC-V ISA, a scalable processor architecture (abbreviated as SPARC) ISA, an IBM power ISA, or the others. 
       FIG.  1 A  shows an instruction structure of the instruction INVL_KEYID in accordance with an exemplary embodiment of the present application. In addition to an opcode  192  for recognizing the instruction INVL_KEYID, the instruction INVL_KEYID includes an operand  194  that indicates a single designated key ID (Key_ID_S). The operand  194  may have various implementations. The operand  194  may carry a register number (reg), for obtaining the designated key ID (Key_ID_S) from a register. The operand  194  may carry either a register number or a system memory address (r/m), for obtaining the designated key ID (Key_ID_S) from a register or the system memory. The operand  194  may carry an immediate value (imm16), which is interpreted as the designated key ID (Key_ID_S). In programming, some instructions may be programmed prior to the instruction INVL_KEYID to prepare the designated key ID (Key_ID_S) in the register/system memory. In another exemplary embodiment, the designated key ID (Key_ID_S) is coded as an immediate value carried in the operand  194  of the instruction INVL_KEYID. 
     In an exemplary embodiment, the microcode (UCODE) of the processor includes some design for executing the instruction INVL_KEYID, and hardware of the processor may be modified accordingly. 
       FIG.  1 B  is a block diagram illustrating a processor  100  in accordance with an exemplary embodiment of the present application. As shown, a system memory  102  is coupled to the processor  100 . A batch of instructions is loaded into an instruction cache  104  from the system memory  102  to be decoded by a decoder  106 . The decoder  106  includes an instruction buffer (XIB for short)  108  and an instruction translator (XLATE for short)  110 . The XIB  108  recognizes the instruction INVL_KEYID, and the XLATE  110  translates the instruction INVL_KEYID into at least one microinstruction that may be recognized by the pipeline hardware. Accordingly, the hardware is driven to flush the translation lookaside buffer (TLB)  117  according to the designated key ID (Key_ID_S). In an exemplary embodiment, the XLATE  110  translates the instruction INVL_KEYID into the at least one microinstruction based on a microcode (UCODE, stored in a microcode memory). The at least one microinstruction is stored in its corresponding reservation station (RS)  114  as indicated by information obtained from a register alias table (RAT)  112 , waiting to be executed. One of the at least one microinstruction is a flushing microinstruction, which triggers a memory order buffer (MOB for short)  116  and, accordingly, drives the translation lookaside buffer (TLB)  117  to flush the TLB entries matching the designated keyID (Key_ID_S). In an exemplary embodiment, microinstructions for functions such as exception checking (e.g., privilege level checking), memory address jumping (i.e., jumping to an instruction following the instruction INVL_KEYID) are also decoded from the instruction INVL_KEYID. 
     The memory order buffer (MOB)  116  is generally used as a communication interface between the processor  100  and the system memory  102 , which involves looking up of the translation lookaside buffer (TLB)  117  to convert a virtual address (VA) into a physical address (PA). The translation lookaside buffer table (TLB table)  118  stored in the translation lookaside buffer (TLB)  117  contains multiple TLB entries, and each TLB entry shows the mapping between one virtual address (VA) and one physical address (PA). However, the TLB table  118  is limited in size. When the space is insufficient, some TLB entries need to be flushed. In another example, when a system memory space protected by a designated key ID is flushed, the related TLB entries in the TLB table  118  should be flushed correspondingly. A flushing technology is proposed in the present application.  FIG.  1 B  illustrates that according to the micro code design of the present application a flushing unit  120  operates to flush the TLB table  118  according to the designated key ID (Key_ID_S). 
     As shown in  FIG.  1 B , through a reservation station (RS)  114 , the opcode  122  and the operands  124  of the flushing microinstruction decoded from the instruction INVL_KEYID are provided to the MOB  116 . According to the recognized value of the opcode  122 , the designated key ID (Key_ID_S) is acquired as indicated by the operand  124 . In an exemplary embodiment, the designated key ID (Key_ID_S) is stored in a register  126  that is indicated by the operand  124 . In another exemplary embodiment, the designated key ID (Key_ID_S) is stored in the system memory  102  as indicated by the operand  124 . In another exemplary embodiment, the designated key ID (Key_ID_S) is an immediate value interpreted from the operand  124 . Through the MOB  116 , a flushing request  128  and the designated key ID (Key_ID_S)  130  is supplied to the flushing unit  120  of the translation lookaside buffer  117 . According to the flushing request  128 , the flushing unit  120  outputs a flushing command  132  and the designated key ID (Key_ID_S)  134  to flush the TLB entries (in the TLB table  118 ) matching the designated key ID (Key_ID_S)  134 . 
     How to check the designated key ID (Key_ID_S)  134  is further discussed in the following paragraphs. 
     In an exemplary embodiment, the most-significant bits of a physical address (PA) are used to set a designated key ID (Key_ID_S)  134  to check the TLB table  118  for the matched entries, and the related TLB structure is shown in  FIG.  2 A . In another exemplary embodiment, a process context identifier PCID and/or a virtual processor identifier VPID are used to set a designated key ID (Key_ID_S)  134  to check the TLB table  118  for the matched entries, and the related TLB structure is shown in  FIG.  2 B . In another exemplary embodiment, the key IDs are defined independently from the physical address or any identifiers, and the related TLB structures are shown in  FIG.  2 C . A designated key ID (Key_ID_S) set independently from the physical address and any identifiers is applied to check the TLB table for the matched TLB entries. Another TLB structure is presented in  FIG.  2 D . Instead of using a designated key ID (Key_ID_S), a representative code (e.g., a code with the shorter bit length, or a one-hot code, which will be described in detail later) representing the designated key ID (Key_ID_S) is used to check the TLB entries in a more efficient manner. The matched TLC entries determined based on a representative code require less logic gates. A designated representative code  140  corresponding to the designated key ID (Key_ID_S)  134  is used to check the TLB table  118  for the matched TLB entries. In some exemplary embodiments, the extension of the virtual machine also affects the determination of the matched TLB entries. Not only the designated key ID (Key_ID_S)  134 , a process context identifier (PCID)  136  and a virtual processor identifier (VPID)  138  may also be considered in checking the TLB table  118  for the matched TLB entries. The flushed TLB entries may need to match the designated key ID (Key_ID_S)  134 , the PCID  136 , as well as the VPID  138 . 
     The designated key ID (Key_ID_S)  134  or the designated representative code  140  that the flushing unit  120  provides to check the TLB table  118  may be regarded as designated matching information. The matched TLB entries in the TLB table  118  are determined according to the designated matching information, and then are flushed. The designated representative code  140  is obtained based on the designated key ID (Key_ID_S)  134 . 
     In order to realize the technology of the present application, the structure of each TLB entry needs some special designs. For example, each TLB entry needs to contain matching information for checking the key ID. The key ID matching information may have various forms. 
       FIGS.  2 A to  2 D  illustrate the TLB entry structure in accordance with various exemplary embodiments of the present application. 
       FIG.  2 A  illustrates a TLB entry structure  200 , including: a valid bit (V)  202  for identifying whether the TLB entry is valid (e.g., ‘0’ means that the TLB entry is invalid, and ‘1’ means that the TLB entry is valid); a field  204 , storing a process context identifier PCID and/or a virtual processor identifier VPID; a field  206 , storing a virtual address (VA); and a field  212 , storing a physical address (PA) which includes high-order bits  208  and low-order bits  210 . In another exemplary embodiment, the process context identifier PCID and the virtual processor identifier VPID in a TLB entry structure each occupy one field. The high-order bits  208  of the physical address (PA) may be interpreted as a key ID of the related system memory space. The high-order bits  208  of the physical address (PA) recorded in a TLB entry structure  200  may be compared with the designated key ID (Key_ID_S)  134  to determine whether the TLB entry matches the designated key ID (Key_ID_S)  134 . An example is shown here. In a virtual machine VM 0 , a virtual processor with a VPID value VP0 executes a process whose PCID value is P0, and the process P0 uses a system memory space with a virtual address VA0. The virtual address VA0 is mapped to a physical address that is combined from a high-bit part PAH0 and a low-bit part PAL0. Referring to table 1, a related TLB entry is shown. The valid bit  202  is ‘1’, the field  204  (PCID/VPID) is P0/VP0, the field  206  (virtual address) is VA0, the field  208  (high-order bits of PA, which is used as a key ID) is PAH0, and the field  210  (low-order bits of PA) is PAL0. The designated key ID (Key_ID_S)  134  is compared with the high-order bits PAH0 recorded in the field  208 . If they are the same, the TLB entry matches the designated key ID (Key_ID_S)  134 . Otherwise, it does not match. 
     
       
         
           
               
               
               
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                   
                   
                   
                 High-bit 
                 Low-bit 
               
               
                 Valid bit 
                 PCID/VPID 
                 VA 
                 part of PA 
                 part of PA 
               
               
                 202 
                 204 
                 206 
                 208 
                 210 
               
               
                   
               
             
            
               
                 1 
                 P0/VP0 
                 VA0 
                 PAH0 
                 PAL0 
               
               
                   
               
            
           
         
       
     
       FIG.  2 B  illustrates a TLB entry structure  214 , including: a valid bit (V)  216  for identifying whether the TLB entry is valid (e.g., ‘0’ means that the TLB entry is invalid, and ‘1’ means that the TLB entry is valid); a field  218 , storing a process context identifier PCID and/or a virtual processor identifier VPID; a field  220 , storing a virtual address (VA); and a field  222 , storing a physical address (PA). In another exemplary embodiment, the process context identifier PCID and the virtual processor identifier VPID in a TLB entry structure each occupy one field. For a TLB entry, the process context identifier PCID and/or the virtual processor identifier VPID recorded in the TLB entry structure may be used as the key ID corresponding to the physical address recorded in the field  222 . The flushing unit  120  may use the PCID  136  and/or the VPID  138  as a designated matching information to flush the TLB table  118 . When the process context identifier PCID and/or the virtual processor identifier VPID recorded in the field  218  of a TLB entry is the same as the PCID  136  and/or the VPID  138 , it means that the TLB entry matches the designated key ID (Key_ID_S)  134 . An example is shown here. In a virtual machine VM 0 , a virtual processor with a VPID value VP0 executes a process whose PCID value is P0. The process P0 may use a system memory space with a virtual address VA0, and the virtual address VA0 is mapped to a physical address PA0. Referring to table 2, a related TLB entry is shown. The valid bit  216  is ‘1’, the field  218  (PCID/VPID) is P0/VP0, the field  220  (virtual address) is VA0, the field  222  (physical address) is PA0. The designated key ID (Key_ID_S)  134  is compared with the VP0 and/or P0 recorded in the field  218 . If they are the same, the TLB entry matches the designated key ID (Key_ID_S)  134 . Otherwise, it does not match. 
     
       
         
           
               
               
               
               
               
             
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 Valid bit 
                 PCID/VPID 
                 VA 
                 PA 
               
               
                   
                 216 
                 218 
                 220 
                 222 
               
               
                   
                   
               
             
            
               
                   
                 1 
                 P0/VP0 
                 VA0 
                 PA0 
               
               
                   
                   
               
            
           
         
       
     
       FIG.  2 C  illustrates a TLB entry structure  224 , including: a valid bit (V)  226  for identifying whether the TLB entry is valid (e.g., ‘0’ means that the TLB entry is invalid, and ‘1’ means that the TLB entry is valid); a field  228 , storing a process context identifier PCID and/or a virtual processor identifier VPID; a field  230 , storing a key ID; a field  232 , storing a virtual address (VA); and a field  234 , storing a physical address (PA). In another exemplary embodiment, the process context identifier PCID and the virtual processor identifier VPID in a TLB entry structure each occupy one field. For a TLB entry, the key ID of the corresponding system memory space is directly recorded in the field  224  to be compared with the designated key ID (Key_ID_S)  134  to determine whether the TLB entry matches the designated key ID (Key_ID_S)  134 . The key ID is independent of the other information such as those recorded in the other fields. Thus, the space of the system memory  102  may be divided in a more flexible manner for individual encryption. An example is shown here. In a virtual machine VM 0 , a virtual processor with a VPID value VP0 executes a process whose PCID value is P0. The process P0 may use the system memory space with a virtual address VA0, and the virtual address VA0 is mapped to a key ID KEYID0. Referring to table 3, a related TLB entry is shown. The valid bit  226  is ‘1’, the field  228  (PCID/VPID) is P0/VP0, the field  230  (key ID) is KEYID0, the field  232  (virtual address) is VA0, and the field  234  (physical address) is PA0. The designated key ID (Key_ID_S)  134  is compared with the key ID KEYID0. If they are the same, the TLB entry matches the designated key ID (Key_ID_S)  134 . Otherwise, it does not match. 
     
       
         
           
               
               
               
               
               
             
               
                 TABLE 3 
               
               
                   
               
               
                 Valid bit 
                 PCID/VPID 
                 Key ID 
                 VA 
                 PA 
               
               
                 226 
                 228 
                 230 
                 232 
                 234 
               
               
                   
               
             
            
               
                 1 
                 P0/VP0 
                 KEYID0 
                 VA0 
                 PA0 
               
               
                   
               
            
           
         
       
     
       FIG.  2 D  illustrates a TLB entry structure  236 , including: a valid bit (V)  238  for identifying whether the TLB entry is valid (e.g., ‘0’ means that the TLB entry is invalid, and ‘1’ means that the TLB entry is valid); a field  240 , storing a process context identifier PCID and/or a virtual processor identifier VPID; a field  242 , storing a representative code KID; a field  244 , storing a virtual address (VA); and a field  246 , storing a physical address (PA). The bit length of the representative code (KID) is shorter than the bit length of the designated key ID (Key_ID_S), so the size of each TLB entry may be reduced, the storage space of the whole TLB table  118  can be saved, and the complexity of hardware matching logic may be reduced. In an exemplary embodiment, the representative code (KID) is a one-hot code (only one bit is 1). For example, 0001, or 0010, or 0100, or 1000 represent four different key IDs. Using one-hot codes makes hardware implementation simpler and may improve the efficiency of hardware matching logic. In another exemplary embodiment, the process context identifier PCID and the virtual processor identifier VPID in a TLB entry structure each occupy one field. The representative code KID stored in the field  242  of the TLB entry structure  234  is compared with a representative code that representing the designated key ID (Key_ID_S)  134 , to determine whether the TLB entry matches the designated key ID (Key_ID_S)  134 . Instead of recording a key ID, the TLB entry storing a representative code KID requires less storage space. In addition, the efficiency of the hardware matching logic in the TLB  117  is improved. 
       FIG.  2 D  further shows a mapping table  248 , that includes a plurality of entries, and each entry includes a valid bit field  2482 , a representative code field  2484 , and a key ID field  2486 , storing a valid flag (V), a representative code KID, and a key ID, respectively. The valid bit field  2482  storing a valid flag (V) shows that whether the corresponding entry is valid. If the valid flag (V) is 0, it means that the corresponding entry is free (that is, invalid). If the valid flag (V) is 1, it means that the corresponding entry is in use (that is, valid). The representative code field  2484  stores a representative code. In an exemplary embodiment, the processor  100  only maintains a fixed amount of representative codes. Each entry in the mapping table  248  corresponds to one representative code (KID). For example, the entry 1 in the mapping table  248  is related to a representative code KID1, the entry 2 in the mapping table  248  is related to a representative code KID2, and so on. In an exemplary embodiment, the processor  100  maintains only eight representative codes. In each entry, the key ID field stores the key ID mapped to the representative code of the corresponding entry. A newly appeared key ID is mapped to one free representative code (KID), and is recorded into an entry in mapping table  248  that is related to the mapped representative code (KID). For example, as shown in  FIG.  2 D , the newly filled two entries in the mapping table  248  show the mapping relationship between a key ID Key_IDa and a representative code KID1, and the mapping relationship between a key ID Key_IDb and a representative code KID2. The valid flags of the two entries storing the representative codes KID1 and KID2 both are asserted to 1. A designated representative code  140  is obtained by looking it up in the mapping table  248  based on the designated key ID (Key_ID_S). Then, the TLB table  118  is checked to find and flush a TLB entry that matches the designated representative code  140 . The management (including filling, updating, flushing, and matching search) of the mapping table  248  may be implemented by a control logic circuit of the TLB  117 . 
     Corresponding to the TLB entry structure  236 , an example about checking the matched TLB entries is discussed in this paragraph. In a virtual machine VM 0 , a virtual processor with a VPID value VP0 executes a process whose PCID value is P0. The process P0 may use the system memory space with a virtual address VA0, the virtual address VA0 is mapped to a physical address PA0, and the key ID corresponding to the process P0 is KEY_IDa. Referring to table 4, a related TLB entry is shown. The valid bit  238  is ‘1’, the field  240  (PCID/VPID) is P0/VP0, the field  242  (KID) is KID1, the field  244  (virtual address) is VA0, and the field  246  (physical address) is PA0. The control logic circuit of the TLB  117  first looks up the designated key ID (Key_ID_S)  134  in the mapping table  248  to get the designated representative code  140  (e.g., KID1 or KID2), and then compares the designated representative code  140  with the representative code KID1 recorded in the field  242 . If they are the same, the TLB entry matches the designated key ID (Key_ID_S)  134 . Otherwise, it does not match. If the control logic circuit of the TLB  117  determines that no representative code  140  in the mapping table  248  matches the designated key ID (Key_ID_S), it means that the TLB table  118  does not have any TLB entry matching the designated key ID (Key_ID_S). 
     
       
         
           
               
               
               
               
               
             
               
                 TABLE 4 
               
               
                   
               
               
                 Valid bit 
                 PCID/VPID 
                 KID 
                 VA 
                 PA 
               
               
                 238 
                 240 
                 242 
                 244 
                 246 
               
               
                   
               
             
            
               
                 1 
                 P0/VP0 
                 KID1 
                 VA0 
                 PA0 
               
               
                   
               
            
           
         
       
     
     With an example shown in  FIGS.  3 A to  3 C , the following describes how to fill a TLB entry in the TLB table  118  according to the TLB entry structure shown in  FIG.  2 D  when the mapping table  248  is full. Referring to  FIG.  3 A , a mapping table  248  the same as that presented in  FIG.  2 D  is shown.  FIG.  3 A  further shows a TLB table  118  that includes several TLB entries ENTRY1, ENTRY2, ENTRY3, ENTRY4, and so on. The TLB entries ENTRY2 and ENTRY4 match a representative code KID2, and correspond to an entry in the mapping table  248  as indicated by the arrow  252 . When new data  250  (including an key ID Key_IDc and TLB entry information NEW_INFO) has to be loaded to the TLB  118 , but the mapping table  248  is full (all valid flags are asserted to 1), the following steps are required. 
     First, the control logic circuit of the TLB  117  selects the least frequently used (LFU) entry in the mapping table  248  (which is the entry indicated by the arrow  251  and corresponds to the representative code KID2) to pair the key ID Key_IDc with the representative code KID2. In another exemplary, the control logic circuit of the TLB  117  selects the least recently used (LRU) entry in the mapping table  248  rather than the least frequently used (LFU) entry in the mapping table  248 . 
     Then, please refer to  FIG.  3 B , the control logic circuit of the TLB  117  invalidates the entries ENTRY2 and ENTRY4 in the TLB table  118 , wherein, as indicated by an arrow  253 , the entries ENTRY2 and ENTRY4 match the representative code KID2. The control logic circuit of the TLB  117  further invalidates the entry, related to the representative code KID2, in the mapping table  248 . Specifically, the control logic circuit of the TLB  117  deasserts the valid bits  238  of the entries ENTRY2 and ENTRY4 (which match the representative code KID2) to 0, and deasserts the valid bit  2482  of the entry (matching the representative code KID2) in the mapping table  248  to 0. 
     Finally, please refer to  FIG.  3 C , the control logic circuit of the TLB  117  writes the key ID Key_IDc into the key ID field  2486  of the entry that is related to the representative code KID2 in the mapping table  248 . The control logic circuit of the TLB  117  further writes the new TLB entry information NEW_INFO into the TLB entry ENTRY2, asserts the valid bit  238  of the entry ENTRY2 to 1, and programs the representative code KID2 to the field  242  of the entry ENTRY2 (as indicated by the arrow  254 ), and asserts the valid bit  2482  of the entry related to the representative code KID2 in the mapping table  248  to 1. 
       FIG.  4    is a block diagram illustrating a control logic circuit  302  of the TLB  117  in accordance with an exemplary embodiment of the present application. The control logic circuit  302  includes a replacing unit  304 , a flushing unit  306 , and an address translation unit  308 . The replacing unit  304  is responsible for filling in the TLB entries. Specifically, the MOB  116  (shown in  FIG.  1 B ) provides a replacing request, an index number of the target TLB entry, and the filling content to the replacing unit  304 . Accordingly, the replacing unit  304  outputs a replacing command, the index number  310  of the target TLB entry, and the filling content  312  to the TLB table  118 . The replacing unit  304  may update the mapping table  248  and the TLB table  118  as previously described. The flushing unit  306  may execute the functions of the flushing unit  120  shown in  FIG.  1 B , which is used for flushing the TLB table  118  based on the designated matching information, and may also be compatible with the other conventional flushing techniques of the other granularities. According to the flushing microinstruction translated from the instruction INVL_KEYID, the MOB  116  operates to drive the flushing unit  306 . The signals that the flushing unit  306  provides to the TLB table  118  include mapping information  314 , and the flushing command  316 . According to the flushing command  316 , the TLB flushing is not limited to full TLB flushing, and may be performed in granularity of key ID, PCID, VPID, or EPTP. The matching information  314  indicates the designated flushing range that is defined based on the applied flushing granularity. 
     The address translation unit  308  is driven by the MOB  116  use the TLB table  118  to convert a virtual address (VA)  318  into a physical address (PA)  322 . Specifically, according to the virtual address (VA)  318  provided from the translation unit  308 , the TLB table  118  returns a flag  320  to the address translation unit  308  that indicates whether there are any TLB-entry hits. If yes, the TLB table  118  provides the hit physical address (PA)  322  to the address translation unit  308 . In an exemplary embodiment, the MOB  116  provides both the key ID (not shown) and the virtual address (VA)  318  to the address translation unit  308  to convert the virtual address (VA)  318  that matches the key ID to the physical address (PA)  322 . 
     In summary, the control logic circuit  302  implements the filling, replacing, and multi-granularity flushing of the TLB table  118 . 
     The present application is not limited to using a single operand to get the designated key ID (Key_ID_S). The instruction INVL_KEYID may be performed based on more parameters (entered through multiple operands), which will be described in detail below with reference to  FIG.  5   . 
       FIG.  5    is an instruction format of the instruction INVL_KEYID. In addition to the opcode  402  for recognizing the instruction INVL_KEYID, there are two operands  404  and  406  for getting two parameters. The two operands  404  and  406  may be entered through two registers. In another exemplary embodiment, the two operands  404  and  406  are separately stored in a register and a memory. In programming, there are other instructions executed prior to the instruction INVL_KEYID to prepare these operands  404  and  406 . 
     In an exemplary embodiment, the operand  404  is a type indicator that indicates how to interpret the operand  406 . The processor  100  shown in  FIG.  1 B  may use a prefetch instruction (PREFETCH) to load the required data into the cache. The prefetch instruction carries information about the type indicator, the value of which may be T0 (indicating the first type) or T1 (indicating the second type). The operand  404  refers to the type indicator carried in the prefetch instruction. When the operand  404  is a first value (such as TO), the operand  406  is interpreted as a virtual address (VA), and the control logic circuit  302  shown in  FIG.  4    uses the key ID corresponding to the VA as the designated key ID (Key_ID_S). In an exemplary embodiment, the control logic circuit  302  further includes an ID code query unit  309 . The microinstructions translated from the instruction INVL_KEYID include a query microinstruction. According to the query microinstruction, the MOB  116  operates to drive the ID code query unit  309  to consult the TLB table  118  for a key ID of the virtual address (VA) indicated in an operand of the query microinstruction. For example, if the TLB entry in  FIG.  4    is in the structure depicted in  FIG.  2 A , the queried key ID is the value in the field  208  of the TLB entry that matches the virtual address (VA). If the TLB entry in  FIG.  4    is in the structure depicted in  FIG.  2 B , the queried key ID is the value in the field  218  of the TLB entry that matches the virtual address (VA). If the TLB entry in  FIG.  4    is in the structure shown in  FIG.  2 C , the queried key ID is the value in the field  230  of the TLB entry that matches the virtual address (VA). If the TLB entry in  FIG.  4    is in the structure shown in  FIG.  0 . 2 D , according to a representative code (KID) in the field  242  of the TLB entry that matches the virtual address (VA), a key ID that is paired with the representative code (KID) in the mapping table  248  is output as the queried key ID. When the operand  404  is a second value (such as T1), the operand  406  is directly interpreted as the designated key ID (Key_ID_S). 
     According to the designated key ID (Key_ID_S), the microinstructions decoded from the instruction INVL_KEYID can provide various flushing schemes considering the system conditions. For example, by executing the microinstructions, it is determined whether a virtual machine extension (VMX) is enabled or disabled, and what state the virtual machine with the enabled virtual machine extension is in. Based on the determination result, the microinstructions are executed to flush the TLB based on the designated key ID (Key_ID_S). If the virtual machine extension is not enabled (VMX off), or the virtual machine with the enabled virtual machine extension is in a host state, the TLB is flushed according to the designated key ID (Key_ID_S) without considering the virtual processor identifier VPID and the process context identifier PCID. If the virtual machine with the enabled virtual machine extension is in a guest state and the virtual processor identifier VPID is off, all TLB entries related to any virtual machine in the TLB are flushed based on the designated key ID (Key_ID_S) without considering the process context identifier PCID. As for the other situations, all TLB entries related to the current virtual processor identifier VPID in the TLB are flushed according to the designated key ID (Key_ID_S). 
     Any technology that flushes a TLB in granularity of key ID is within the scope of protection in this case. 
     According to the technology of the present application, the translation lookaside buffer (TLB) is provided with a management function in granularity of keys. When a full memory encryption function is enabled, the operating system can manage the translation lookaside buffer (TLB) in granularity of keys (or key IDs). 
     While the invention has been described by way of example and in terms of the preferred embodiments, it should be understood that the invention is not limited to the disclosed embodiments. On the contrary, it is intended to cover various modifications and similar arrangements (as would be apparent to those skilled in the art). Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.