JP2014013615A - Synchronizing translation lookaside buffer to extended paging table - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an approach that enables efficient address translation in a virtual machine.SOLUTION: A processor 318 includes logic 322 to execute an instruction to synchronize a mapping from a physical address of a guest of a virtualization-based system (guest physical address) to a physical address of the host of the virtualization-based system (host physical address), the mapping stored in a translation lookaside buffer (TLB) 323, with a corresponding mapping stored in an extended paging table (EPT) 328 of the virtualization-based system.

Description

  This application is a pending US patent application Ser. No. 11/036 entitled “Virtualized Physical Memory in a Virtual Machine System” assigned to the assignee of the present invention (EPT patent application), attorney case serial number P20462. Related to 736.

  Virtualization is a single piece of hardware and software support for virtualization that represents the host's abstraction so that the hardware under the host machine appears to be one or more independently running virtual machines. Realize the host machine. Thus, each virtual machine may function as a self-contained platform. Virtualization technology allows multiple guest operating systems and / or other guest software to actually run physically on the same hardware platform, while appearing simultaneously and individually in multiple virtual machines. Often used to implement what is done. A virtual machine can mimic the hardware of a host machine or can represent an abstraction of different hardware as a whole.

The virtualization system may include a virtual machine monitor (VMM) that controls the host machine.
The VMM provides a set of resources (eg, processor, memory, IO device) to guest software that operates in a virtual machine. The VMM may map some or all of the components of the physical host machine to the virtual machine and generate a complete virtual component (eg, virtual IO device) that is mimicked in the VMM software that is included in the virtual machine. it can. The VMM can thus be said to provide a “virtual bare machine” interface to guest software. The VMM uses equipment in a hardware virtualization architecture that provides services to virtual machines and protects against / between multiple virtual machines running on a host machine. When guest software is executed in a virtual machine, certain instructions executed by the guest software (eg, instructions to access peripheral devices) are usually those that directly access the hardware, and the guest software is It is executed directly. In a virtualization system directed by a VMM, these instructions can result in a transition to a VMM, referred to herein as a virtual machine exit. The VMM processes the instructions in these software in a manner suitable for host machine hardware and host machine peripheral devices that are consistent with the virtual machine on which the guest software is executed. Similarly, certain interrupts and exceptions generated on the host machine need to be blocked or managed by the VMM or adapted to the guest software by the VMM before being passed to the guest software to provide service. There may be. Then, the VMM transfers management to the guest software, and the virtual machine resumes operation. In this specification, the migration from VMM to Hess and software is called a virtual machine entry.

  As is known in the art, page tables are often used to provide linear memory to physical memory mapping in typical processor-based systems. The page table has a memory resident structure, and accessing the page table to determine a physical address corresponding to a linear address becomes a memory access, which may cause a processing time delay. To alleviate this problem, many processor implementations have a translation lookaside buffer (TLB) in which some subset of the current linear to physical memory mapping in use is cached based on page table values. A high speed memory or bank of registers in the processor called). This allows the processor to access the translation of the linear address to the corresponding physical address faster than would normally be expected when the page table must be accessed. The processor implementation generally provides instructions for managing the TLB, including instructions to invalidate or update all entries in the TLB based on the current translation stored in the page table.

  FIG. 1 illustrates a process performed in a processor-based system incorporating a processor and memory communicatively coupled to the processor by a bus. Referring to FIG. 1, when process 105 refers to memory location 110 within its linear address space 115 (linear memory space), the reference to real address 140 in physical memory 145 (machine physical memory) of machine 125 is Generated by memory management 130 that may be implemented in hardware (sometimes incorporated into processor 120) and software (generally in the machine's operating system). Memory management 130, among other functions, maps locations in the linear address space to locations in the machine's physical memory. As shown in FIG. 1, the process may have a different view than the memory actually available on the physical machine. In the example shown in FIG. 1, the process operates in a linear address space from 0 to 1 MB that is actually mapped by memory management hardware and software to a portion of physical memory that itself has an address space from 10 to 11 MB. Then, an offset 135 may be added to the linear address to calculate the physical address from the process space address. More complex mapping from linear address space to physical memory is possible, for example, physical memory corresponding to linear memory is divided into page-like parts and interleaved by pages from other processes in physical memory May be.

  The memory is customarily divided into pages, each page containing a known amount of data that varies throughout the implementation, for example, one page is 4096 bytes of memory, 1 MB of memory, or as desired for a particular application. Any other amount of memory may be included. When memory locations are referenced by the execution process, they are translated into a page index. In a typical machine, memory management maps a reference to a page in linear memory to a page in machine physical memory. In general, memory management may use a page table that identifies physical page positions corresponding to process space page positions.

One aspect of managing guest software in a virtual machine environment is memory management.
Handling a memory management operation performed by guest software executed in a virtual machine complicates a control system such as a virtual machine monitor. For example, consider a system that is virtualized and executed on a host machine implemented on an x86 platform where two virtual machines may include page tables implemented as part of an x86 processor. Further assume that each virtual machine itself presents an x86 machine abstraction to the guest software running on it. The guest software running on each virtual machine references the guest linear memory address and may then be translated into a guest-physical memory address by the guest machine's memory management system. However, the guest-physical memory itself can also be implemented by further mapping in the host-physical memory via a virtual subsystem in hardware on the VMM and the host processor. Thus, references to guest memory by guest processes or guest operating systems, including references to x86 page table control registers, for example, must be blocked by the VMM. Because they do not correspond directly to the host-physical memory in fact, the host-machine page table without further re-processing, such as further remapping through the host machine's virtual system. It is because it cannot be handed over directly.

  FIG. 2: FIG. 2 illustrates the relationship between one or more virtual machines running on a host machine that is particularly relevant to guest memory mapping in one embodiment. FIG. 2 shows how guest-physical memory is remapped through the host machine virtualization system. Each virtual machine, such as virtual machine A, 242 and virtual machine B, 257, presents virtual processors 245 and 255, respectively, for guest software running on the virtual machine. Each machine provides an abstraction of physical memory to the guest operating system or other guest software, guest-physical memory 240 and 250, respectively. When the guest software is executed in the virtual machines 242 and 257, it is actually executed by the host machine 267 in the host processor 265 using the host-physical memory 260.

  As shown in FIG. 2, in this embodiment, the guest-physical memory 240 represented as a physical memory space starting from address 0 of the virtual machines A and 242 is mapped to a part of the continuous area 270 in the host-physical memory 260. Is done. Similarly, guest-physical memory 250 in virtual machine B, 257 is mapped to a different portion 275 of host-physical memory 260. As shown in FIG. 2, the host machine may have 1024 MB of host-physical memory. If each virtual machine 242 and 257 is assigned 256 MB of memory, one possible mapping is that virtual machines A, 242 are assigned a range of 128-384 MB and virtual machines B, 257 are 512 A range of -768 MB can be allocated. Both virtual machines 242 and 257 reference the 0-256 MB guest-physical address space. Only the VMM knows to map each virtual machine's address space to a different part of the host-physical address space.

  The virtual machine and memory mapping shown in FIG. 2 is only one representation of one embodiment in other embodiments, and the actual number of virtual machines running on the host machine is from one to many. It may be changed, the actual memory size of the host machine and the virtual machine may be changed, and change between virtual machines is also possible. The example shows a simple sequential allocation of memory to virtual machines. In a more general case, the physical-memory pages allocated to the virtual machine may not be contiguous and in host physical memory interleaved with each other and pages belonging to the VMM and other host processors. May be dispersed.

  A processor based system represented as a virtual machine in the system as shown in FIG. 2 can implement any complexity of the virtual machine itself. Thus, for example, a virtual machine presents the entire guest-physical memory to the guest OS and runs on the virtual machine using the memory management provided by the guest OS, and the virtual processor or other virtual hardware of the virtual machine Can perform memory management of guest software. In one exemplary embodiment, the virtual machine may present to the guest OS an x86 platform that includes x86 hardware support, such as a page table for memory management, and then x86 hardware for memory management. May actually run on a host platform that is also an x86 platform, including The virtualization system of this embodiment uses the x86 page table shadowing to remap, partition, and protect physical memory as one possible solution without additional mechanisms. A memory virtualization algorithm must be implemented. Thus, for example, when guest software attempts to access the x86 page table of a virtual machine, the VMM needs to overlay the functions required for virtualization (eg physical address remapping) with the functions required for the guest OS. .

  In order to do so, the VMM must trap various events related to the use of the paging mechanism by the guest software. This has been documented in writes to control registers such as control registers (eg CR0, CR3 and CR4) in x86 memory management systems, access to model specific registers (MSRs) related to paging, and x86 documentation Includes memory accesses (eg, Memory Type Range Register (MTRR)) that handle specific exceptions (eg, page faults). The use of this x86 page table to virtualize physical memory is complex and imposes considerable performance overhead.

  FIG. 3: FIG. 3 illustrates one embodiment of a virtual machine environment 300. In this embodiment, a processor based platform 316 may execute the VMM 312. The VMM is usually implemented in software, but can also be exported to mimic a virtual bare machine interface to higher level software. Such higher-level software may include a standard OS, a real-time OS, or may be an environment that eliminates all of the extra equipment with limited operating system functionality, and some embodiments Then, it is not necessary to include the OS function that is normally available in the standard OS. Alternatively, for example, the VMM 312 can execute in other VMMs or may be executed using services of other VMMs. In some embodiments, the VMM may be implemented in, for example, hardware, software, firmware, or a combination of various technologies. In at least one embodiment, one or more components of the VMM are executed in one or more virtual machines, and one or more components of the VMM are as shown in FIG. It may be implemented in bare platform hardware. A VMM component that runs directly on bare platform hardware is referred to herein as a VMM host component.

  Platform hardware 316 is a personal computer (PC), server, mainframe, personal digital assistant (PDA) or handheld device such as a smart mobile phone, portable computer, set-top box, or other processor-based system. It's okay. Platform hardware 316 includes at least a processor 318 and memory 320. The processor 318 may be any type of processor capable of executing programs such as a microprocessor, digital signal processor, microcontroller, and the like. The processor may include microcode, programmable logic, or hard code logic for execution in embodiments. FIG. 3 shows only such a processor 318, but in one embodiment there may be one or more processors in the system. Further, the processor 318 may include multi-core, multi-thread support, and the like. The memory 320 may be read by the hard disk, floppy disk, random access memory (RAM), read only memory (ROM), flash memory, any combination of the aforementioned devices, or the processor 318 in various embodiments. Any other type of machine readable medium may be included. Memory 320 may also store instructions and / or data for executing program execution and other method embodiments. In some embodiments, some elements of the invention may be implemented in other system components such as, for example, a platform chipset or one or more memory controllers of the system.

  The VMM 312 presents one or more virtual machine abstractions to the guest software, which may provide the same or different abstractions to various guests. FIG. 3 shows two virtual machines 302 and 314. Guest software such as guest software 303 and 313 running on each virtual machine may include a guest OS such as guest OSs 304 and 306 and various guest software applications 308 and 310. Guest software 303 and 313 may access physical resources (eg, processor registers, memory and I / O devices) in the virtual machine on which guest software 303 and 313 operate and perform other functions. For example, guest software 303 and 313 would have access to all of the registers, caches, structures, I / O devices, memory, etc. according to the processor and platform architecture represented in virtual machines 302 and 314. ing.

  In one embodiment, processor 318 controls the operation of virtual machines 302 and 314 according to data stored in virtual machine control structure (VMCS) 324. VMCS 324 provides guest software 303 and 313 status, VMM 312 status, execution control information indicating how VMM 312 wants to control the operation of guest software 303 and 313, and migration between VMM 312 and the virtual machine. It is a structure that can contain information to be controlled. The processor 318 reads information from the VMCS 324 to determine the execution environment of the virtual machine and constrain its behavior. In one embodiment, VMCS 324 is stored in memory 320. In some embodiments, multiple VMCS structures are used to support the CPU in one or more virtual multiple virtual machines.

  The VMM 312 needs to manage physical memory that can be accessed by guest software running on the virtual machines 302 and 314. To support physical memory management in one embodiment, processor 318 provides an extended page table (EPT) mechanism. In an embodiment, VMM 312 includes a physical memory management module 326 that provides values for fields related to physical memory virtualization that may need to be provided prior to transferring control to virtual machines 302 and 314. These fields are collectively referred to as EPT control. EPT controls include, for example, an EPT availability indicator that specifies whether the EPT mechanism should be enabled, and one or more EPT table configuration controls that indicate the type and semantics of the physical memory virtualization mechanism. It's okay. These details are described below. Further, in one embodiment, the EPT table 328 indicates the physical address translation and protection semantics that the VMM 312 may be on the guest software 303 and 313.

  In one embodiment, the EPT control is stored in VMCS 324. Alternatively, EPT control may reside in a combination of processor 318, memory 320 and processor 318, or any other storage location. In one embodiment, separate EPT control is maintained for each of the virtual machines 302 and 314. On the other hand, the same EPT control is maintained for both virtual machines and is updated by the VMM 312 prior to each virtual machine entry.

  In one embodiment, EPT table 328 is stored in memory 320. Alternatively, EPT table 328 may reside in a combination of processor 318, memory 320 and processor 318, or any other storage location. In one embodiment, a separate EPT table 328 is maintained for each of the virtual machines 302 and 314. On the other hand, the same EPT table 328 is maintained for both virtual machines 302 and 314 and is updated by the VMM 312 prior to each virtual machine entry.

  In one embodiment, the processor 318 includes EPT access logic 322 that serves to determine whether an EPT mechanism is available based on an availability indicator. If the EPT mechanism is enabled, the processor translates the guest-physical address to the host-physical address based on EPT control and EPT table 328.

  In the illustrated embodiment, the processor may further include a translation lookaside buffer (TLB) 323 that caches guest-physical linear, guest-physical to host physical address, and host-physical translation linear. . Guest-physical alignment and alignment to host-physical translation are referred to herein as "linear translation". The linearity from guest-physics to host-physics and host-physical translation is referred to herein as “physical translation”.

  In one embodiment where system 300 includes a multiprocessor or multithreaded processor, each logical processor is associated with a separate EPT access logic 322 and VMM 312 configures an EPT table 328 and EPT control for each logical processor. .

  Resources that can be accessed by guest software (eg, 303 including guest OS 304 and application 308) may be classified as “privileged” or “unprivileged”. For privileged resources, VMM 312 promotes the functionality desired for guest software while retaining ultimate control of these entire privileged resources. In addition, each guest software 303 and 313 includes exceptions (eg, page faults, general protection faults, etc.), interrupts (eg, hardware interrupts, software interrupts), and platform events (eg, initialization (INIT) and system management interrupts). (SMI)) and so on. Because some of these platform events ensure the correct operation of virtual machines 302 and 314 and need to be handled by VMM 312 for the purpose of protection from guest software and between guest hostware, “Privileged”. Both the guest operating system and the guest application can attempt to access privileged resources, and both produce or experience privileged events. In this specification, privileged platform events and attempts to access privileged resources are collectively referred to as "privileged events" or "virtualized events".

FIG. 3a: FIG. 3a shows some block level features at a high level of the processor 318 in the embodiment of FIG. In general, a processor as shown at 318 in FIG. 3 may include a processor bus or a bus as shown at 337 in FIG. 3a. Further, as shown in FIG. 3a, the processor may include registers 350 in one or more banks, each register storing 32, 64, 128, or other number of bits of data as is well known. May have capacity. Each register bank may further have a number of registers, for example 8, 32, 64 registers. Some registers may be dedicated to control and status use, for example to store CR bits as in the x86 embodiment. In other embodiments, other control registers and flags may be stored in the processor to allow different modes of operation and status checks as is well known in the art. Generally, a processor such as that shown in the embodiment of FIG. 3 includes a logic or logic circuit 330 that retrieves instructions and data from memory, cache, or other storage device, logic or logic circuits that decode instructions, and instructions An execution unit such as 334 may be included. Various variations of these functional units are possible, for example, execution in an execution unit may be transferred in a pipeline, or includes inference and branch prediction, or is associated with a particular processor or application May have other features. Other function logic 365, such as arithmetic, graphics processing logic, and many other special functions of the processor as is well known, may be present in the processor.
An onboard cache 360 may exist in some embodiments. As is well known, this cache may have various sizes such as 128MB, 1GB. As indicated above with reference to FIG. 3, processor 318 includes EPT access logic 322 and TLB 323. The EPT access logic may include logic to locate, control and manage the EPT in one embodiment. A TLB may also be a buffer that typically contains mappings from page tables that are cached for efficiency and other purposes within the processor.

  FIG. 4: FIG. 4 shows an example of processing using the extended page table introduced earlier to finally calculate the host-physical address when the guest software in the virtual machine refers to the guest virtual address . The example shown shows guest software running on an x86 platform using simple 32-bit virtual addressing and a simple page table format. One skilled in the art will see examples of this in other paging modes (such as 64-bit addressing in guest software), other instruction set architectures (Intel Titanium® architecture, x86 architecture, among others). 64 bits and other variations, PowerPC® architecture), and other configurations could be easily extended to understand.

In FIG. 4, reference to the guest virtual address 410 is performed by guest software executed in the virtual machine. A memory management mechanism active within the guest (ie, a mechanism configured by the guest operation system) is used to translate virtual addresses into guest-physical addresses. Each guest-physical address used during translation, and the resulting guest-physical address, is translated into a host-physical address via EPT before accessing the host-physical memory.
This process is described in detail below.

  In this example, the appropriate bit 402 in the CR3 register 420 indicates the base of the guest's page directory table 460 in guest-physical memory. This value 402, when combined with the bits above the guest virtual address 410 (in this example, each entry in the table is 4 bytes, so it is appropriately adjusted according to x86 semantics by multiplying by 4) The guest-physical address 412 of the page directory entry (PDE) in the PD table 460 is formed. This value 412 is translated via the EPT table 455 to form the host-physical address 404 of the page directory entry. The processor uses this host-physical address 404 to access the page directory entry.

Information from the PDE includes the base address 422 of the guest page table 470. This guest-physical address 422 is combined with bits 21:12 of the guest virtual address 410 appropriately adjusted to form the guest-physical address 432 of the page table entry in the guest page table 470. This guest-physical address 432 is translated via the EPT table 465 to form the host-physical address 414 of the guest page table entry (PTE).
The processor uses this host-physical address 414 to access the PTE.

  Information from the PTE includes the base address 442 of the page in guest-physical memory to be accessed. This value is combined with the lower bits (11: 0) of the guest virtual address 410 to form the guest-physical address 452 of the accessed memory. This value 452 is translated via the EPT table 475 to form the host-physical address 424 of the memory to be accessed.

  Each time an EPT table is used to translate a guest-physical address to a host-physical address, the processor authenticates that access is allowed according to the controls in the EPT table as described below. Thus, although clearly shown in FIG. 4, in one embodiment, EPT tables 455, 465, and 475 are similar sets of EPT tables (ie, a single set of EPT tables is a guest-physical to host -Used to translate all addresses to physics).

  In a typical linear memory support implementation in a processor-based system, the linear to physical address mapping stored in the page table structure is cached in a translation lookaside buffer (TLB) for efficiency. Instructions may be included in the processor instruction set to manage the TLB and ensure that a particular entry in the TLB is synchronized with the page table entry by a program running on a processor-based system. Thus, for example, in the x86 architecture, the MOV CR instruction may result in global invalidation of all TLB entries, so the entry resynchronization as an address is accessed. On the other hand, in the x86 example, the INVLPG instruction is used to invalidate the mapping stored in the TLB for a specific linear address, thereby updating the entry in the TLB and synchronizing it with the mapping in the page table. Good.

  In one embodiment, including a virtualization system that incorporates an extended paging table (EPT) as described above, the TLB is configured with guest alignment to host physical address translation for processes running in guest machine memory, and FIG. The host alignment to host physical mapping for a process such as a VMM running directly on the host machine as described above with reference to H.323 may be cached. In the previous case, the guest alignment to the host physical mapping can be derived from the page table in the guest as well as EPT. In later cases, the mapping may be derived from the host page table. Another type of mapping, that is, a mapping derived directly from guest physical to host physical memory based on the mapping stored in the EPT, can also be stored in the TLB.

  In one embodiment, a new command is added to the processor instruction set. In this embodiment, the new command INVL_EPT provides a program that is executed directly on the host machine of the virtualization system, such as a VMM, in a manner that manages TLB entries derived from guest-physical to host-physical mapping. Specifically, in this embodiment, the INVL_EPT instruction ensures that the linear from guest-physical to host-physical and host physical mapping in the TLB is synchronized with the EPT table residing in the host memory. , The EPT context, and, if applicable, the guest physical memory address to which the mapping is synchronized. A context generally defines a portion of the system's address space. In the guest-physical to host-physical mapping, the EPT context is defined by the currently active EPT table and is then referenced by a register called an EPT pointer or EPTP in this embodiment.

In the present embodiment, the INVL_EPT instruction has three operands. The first operand is an instruction mode or a value with a different specification, the second operand is a value that identifies an EPT pointer equal to the EPT context that is to be executed with the INVL_EPT instruction, and the third operand is This value specifies the guest physical address associated with the TLB entry to be invalidated. In this embodiment, the first operand is provided as an 8-bit immediate value, and the second and third operands are each provided as a block in memory that occupies 64 bits. Other embodiments are possible.
For example, operands may be provided in registers or other memory locations, either explicitly or implicitly.

The first operand in this embodiment is a switch or flag having at least three defined values, so identifying the INVL_EPT instruction performs one of the following three possible modes: It will be. 1. Individual address mode: In this mode, the physical translation in the TLB associated with a single guest physical address is based on the mapping to that address in the EPT referenced by the context provided in the second operand above. Synchronize. 2. Context mode: In this mode, the guest address parameter (the third operand described above) is ignored and those entries in the TLB in the EPT identified in the second operand are synchronized with the EPT.
3. Global mode: In this mode, both guest address parameters and EPT context parameters are ignored, and TLB entries derived from either EPT context are synchronized.

FIG. 5: The flowchart of FIG. 5 illustrates execution of an INVL_EPT instruction in one embodiment.
Execution starts from 500. First, the processor performs a number of tests at 505 to ensure that the current execution environment is valid for EPT related operations. These tests may include, among other things, tests that ensure that the system is in a virtualized mode of operation, paging is enabled, and that there are currently no error conditions. If the execution environment is not valid, the instruction may either go through an undefined state, generate a general protection fault, generate an undefined opcode fault, etc. via 555 and 560 . If the execution environment is valid, then in this embodiment, subsequent execution of the instruction reads an immediate 8-bit operand at 510. This operand, called SYNC_CMD, is said to represent a valid mode for the INVL_EPT instruction as described above. If the operand is not valid at 515, the instruction exits to 555 and 560 as before. If the operand is valid, execution proceeds to read the second and third operands from memory at 520, and as described above, the operand is 128 in the memory labeled INVLEPT_DESC in the figure. It is supposed to be in a bit block. The first 64 bits in this embodiment are an EPT context or an EPT table pointer, and are extracted as EPTP_CTX at 525. The next 64 bits are the guest-physical address parameter for the instruction extracted at 530 as GP_ADDR.

  Execution of the instruction then proceeds to perform the actual synchronization based on the value of the SYNC_CMD operand shown at 535 to 580 of the execution flow. As mentioned above, SYNC_CMD is an indication to perform global synchronization of the TLB based on all EPT contexts, or an indication to perform only synchronization of the EPT context specified by the operand of the instruction, or Finally, it may be either an indication to perform synchronization of only the guest-physical address passed as a parameter in the EPT context provided as a parameter. In this embodiment, as shown in the execution flow of FIG. 5, the presence of a SYNC_CMD value is checked at 535, the second stage 540, and the third stage 545. At 535, if the value of SYNC_CMD indicates global synchronization, the instruction performs to synchronize all physical mappings for all EPT contexts and execution completes at 580. On the other hand, if SYNC_CMD indicates context specific synchronization at 540, execution proceeds to checking whether the provided EPTP_CTX value is valid. For example, if the reserved bit is set to a value or is not valid because the address in the EPTP is invalid, execution of the instruction is terminated with a general protection fault of 555 and 560. If the provided context is valid, execution continues to synchronize all physical mappings for the EPT context referenced by EPTP_CTX at 575 and ends at 580.

  If SYNC_CMD is not global or context-wide synchronization and is a valid mode of operation, the only remaining possibility in this embodiment is in the command to synchronize a specific guest physical address. Execution checks whether the GP_ADDR parameter provided at 545 is valid. If an invalid address is provided, execution exits 555 and 560 due to a general protection fault. On the other hand, all physical mappings associated with the provided guest physical address GP_ADDR synchronize with the EPT referenced by the context provided in EPTP_CTX at 550 and execution ends at 580.

  It will be apparent to those skilled in the art that the embodiments described above can be varied widely. In some embodiments, a command equal to INVL_EPT is available, but may have a different syntax including, among other things, name, number, format, and parameter size. As is well known, there are different instruction set architectures (ISAs), and similar commands are provided to different ISAs along with the format and other characteristics consistent with that ISA. In one embodiment, instructions for disabling and / or synchronizing TLB and EPT for a processor based on the Intel® Titanium architecture are provided by one of ordinary skill in the art of the embodiment provided above. Based on the description, it is immediately virtualized and described. It may be multiple instructions for any other ISA.

  The description of the EPT context in the previously referenced embodiments should not be taken as a limitation. In other embodiments, there may be only one example of EPT, or some examples as described in the x86 example, with reference mechanisms such as reference registers or pointers similar to the aforementioned EPTP. May be operable.

  In other embodiments, the number and format of the parameters can be changed. For example, in the previous embodiment, the INVL_EPT instruction has one immediate and two memory-based operands. In other embodiments, more immediate operands may be used, in other embodiments, all operands may be memory-based, and in yet other embodiments, the operands may be a number of other known Among variations, it may be read from a register in the processor or other storage device.

  The foregoing embodiment has been described with respect to three modes of operation for the INVL_EPT instruction. In other embodiments, some or all of the three modes may be missing. In other embodiments, more modes may be available. For example, in some embodiments there may not be an individual address invalid mode, in which all TLB entries are synchronized. In some embodiments, there may be only one example of an EPT operating in the system, and in such embodiments, context mode may not be necessary. Alternatively, in some embodiments, only individual address synchronization may be valid, or in other embodiments, only global address synchronization may be used and the first operand described for INVL_EPT may be unnecessary.

  While these changes in the instruction and its operation are possible, many other changes are readily apparent to those skilled in the art, including changes where the general effect of the INVL_EPT instruction is obtained by a combination of other instructions. It can be assumed.

  In the preceding description, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments, although many other embodiments can be practiced without the specific details being set forth. Will be apparent to those skilled in the art.

Some portions of the foregoing specific description are presented in terms of algorithms and data symbols in a data bit in a processor-based system. These algorithmic descriptions and representations are used by those skilled in the art as a means to most effectively convey the substance of their action to others. An action is the physical operation that they require of a physical quantity. These quantities may be electrical, magnetic, optical, or other physical signals that can be stored, transferred, combined, compared, or otherwise manipulated.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

  It should be borne in mind, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise stated, terms such as “execution”, “processing”, “calculation”, “calculation”, or “decision” are expressed as physical quantities in a processor-based system or in a storage device of a processor-based system. May be related to the operation and process of a similar electronic computer or other such information storage, transmission or display device that manipulates and converts the transferred data to other similarly represented data .

  In the description of the embodiments, reference may be made to the accompanying drawings. In the drawings, like numerals describe substantially similar components throughout the several views. Other embodiments may be utilized and structural, logical, and electrical changes may be made. Further, it should be understood that differences in many embodiments do not necessarily exclude each other. For example, certain features, structures, or characteristics described in one embodiment may be included in other embodiments.

  Furthermore, the design of one embodiment implemented on a processor may go through various stages from creation to simulation to manufacturing. The data representing the design may represent the design in many ways. First, the hardware may be represented using a hardware description language or other functional description language to aid in simulation. A circuit level model with logic and / or transistor gates may then be generated at some stages of the design process. In addition, most designs may reach a data level that represents the physical placement of various devices in the hardware model at several stages. When conventional semiconductor manufacturing techniques are used, the data representing the hardware model may be data identifying the presence or absence of various features in different mask layers of the mask used to generate the integrated circuit. In any representation of the design, the data may be stored on any form of machine-readable medium. A machine-readable medium may be a light or radio wave that is modulated or otherwise generated to transmit such information, a memory, or a magnetic or optical storage device such as a disk. Any of these media can “have” or “show” design or software information. When an electrical carrier indicating or having a code or design is transmitted, a new copy is made to the extent that copying, buffering, or retransmission of the electrical signal is performed. Accordingly, a communications provider or network provider can make a copy of an article (carrier) that constitutes or represents an embodiment.

  Embodiments may be provided as a program product that may include a machine-readable medium having stored thereon data that, when accessed by a machine, causes the machine to perform a process in accordance with the claimed subject matter. Machine-readable media include, but are not limited to, floppy diskettes, optical disks, DVD-ROM disks, DVD-RAM disks, DVD-RW disks, DVD + RW disks, CD-R disks, CD-RW disks, CD-ROM disks, optical It may include magnetic disks, ROM, RAM, EPROM, EEPROM, magnetic or optical cards, flash memory, or other types of media / machine-readable media suitable for storing electronic instructions. In addition, embodiments may be downloaded as a program product, which is a communication link (modem or modem) from a remote data source to a requesting device by means of data signals contained in a carrier or other propagation medium. For example via a network connection).

Many methods are described in their most basic form, but any method may be added / removed to / from any method without departing from the basic scope of the claimed subject matter. It is also possible to add / extract information to / from any of the described contents. It will be apparent to those skilled in the art that many more modifications and adaptations may be made. The specific embodiments are merely illustrative, not limiting of what is recited in the claims. The scope of the claims is determined by the appended claims only, not by the above detailed description. Examples of the present invention are described below as items.
[Item 1]
A processor of a system based on virtualization,
A processor bus;
A buffer for storing a translation lookaside buffer (TLB) including a mapping from a guest address to a host physical address;
Fetch logic for receiving instructions and receiving operands;
Decode logic to decode instructions;
Respond at least in part to instruction decoding, mapping from guest address to host physical address stored in the buffer, and host physical address corresponding to the guest physical address stored at least in part in the extended paging table (EPT) A logic circuit that performs the synchronization with the corresponding mapping, including the translation;
Including
The synchronization is further based at least in part on an operand of the instruction, the operand further comprising at least one of a context descriptor and an EPT pointer.
Processor.
[Item 2]
The processor of item 1, wherein the logic circuit includes a logic circuit that operates based at least in part on a plurality of microcode instructions.
[Item 3]
Item 3. The processor of item 1 or item 2, wherein the EPT is stored at least in part in memory coupled to the processor by a bus.
[Item 4]
Item 4. The processor of any one of Items 1 through 3, wherein the logic circuit further selects a mapping from the EPT based at least in part on a context descriptor derived from an operand of the instruction.
[Item 5]
Item 5. The processor of item 4, wherein the logic circuit further selects a mapping from the EPT based at least in part on an EPT pointer derived from the context descriptor.
[Item 6]
Item 6. The processor according to any one of Items 1 to 5, wherein the logic circuit further selects a guest address based at least in part on an operand of the instruction.
[Item 7]
Mapping synchronization further includes updating the mapping stored in the TLB based at least in part on the mapping stored in the EPT;
The corresponding mapping further includes a mapping stored in the EPT having the same guest address as the mapping stored in the TLB,
Item 7. The processor according to any one of Items 1 to 6.
[Item 8]
8. The processor of any one of items 1 to 7, wherein synchronizing the mapping further comprises flushing the mapping stored in the TLB.
[Item 9]
Item 9. The processor according to any one of Items 1 to 8, wherein the logic circuit further selects an instruction execution mode based at least in part on an operand of the instruction.
[Item 10]
The fetch logic further receives a first operand of the instruction, a second operand of the instruction, and a third operand of the instruction;
The logic circuit further
Selecting a mapping at least partially stored in the EPT based on the context descriptor derived from the first operand of the instruction;
Selecting a guest address based at least in part on the second operand of the instruction;
Selecting an instruction execution mode based at least in part on the third operand of the instruction;
Instruction execution mode is
A first mode in which only a single mapping associated with a guest address stored in the TLB is synchronized with the corresponding mapping in the EPT;
A second mode in which all mappings associated with the EPT context stored in the TLB and derived from the context descriptor are synchronized with the corresponding mapping in the EPT; and
A third mode in which all mappings stored in the TLB associated with any EPT context are synchronized with the corresponding mapping in the EPT;
10. The processor according to any one of items 1 to 9, which is one of the following.
[Item 11]
Item 11. The processor according to any one of Items 1 to 10, wherein the guest address further includes a guest physical address.
[Item 12]
Item 12. The processor of any one of Items 1 through 11, wherein the guest address further includes a guest linear address.
[Item 13]
In a virtualization-based system that includes hosts and guests,
A mapping that includes the translation of a guest address to a host physical address that is at least partially stored in a translation lookaside buffer (TLB), and a virtualization-based system extended paging table (EPT) that corresponds to the guest physical address Synchronizing the corresponding mapping at least partially stored in the EPT that includes the translation of the physical address;
Selecting a mapping stored at least in part in the EPT based at least in part on operands of the instruction;
And the operand includes at least one of a context descriptor and an EPT pointer.
[Item 14]
14. The method of item 13, further comprising selecting a mapping from the EPT based in part on a context descriptor derived from an operand of the instruction.
[Item 15]
15. The method of item 14, further comprising selecting a mapping that is at least partially stored in the EPT based in part on an EPT pointer derived from the context descriptor.
[Item 16]
16. The method of any one of items 13 to 15, further comprising selecting a guest address based at least in part on an operand of the instruction.
[Item 17]
Synchronizing the mapping further includes updating the mapping stored in the TLB based at least in part on the mapping stored in the EPT;
The corresponding mapping further includes a mapping stored in the EPT having the same guest address as the mapping stored in the TLB,
The method according to any one of items 13 to 16.
[Item 18]
18. The method of any one of items 13 to 17, wherein synchronizing the mapping further comprises flushing a mapping stored from the TLB.
[Item 19]
19. The method of any one of items 13 to 18, further comprising selecting an instruction execution mode based at least in part on an operand of the instruction.
[Item 20]
Selecting a mapping at least partially stored in the EPT based on a context descriptor derived from the first operand of the instruction;
Selecting a guest address based at least in part on the second operand of the instruction;
Selecting an instruction execution mode based at least in part on a third operand of the instruction;
Including
Instruction execution mode is
A first mode in which only a single mapping stored in the TLB and associated with the guest address is synchronized with the corresponding mapping in the EPT;
A second mode in which all mappings associated with the EPT context stored in the TLB and derived from the context descriptor are synchronized with the corresponding mapping in the EPT; and
A third mode in which all mappings stored in the TLB associated with any EPT context are synchronized with the corresponding mapping in the EPT;
One of the
20. The method according to any one of items 13 to 19.
[Item 21]
Item 21. The method according to any one of Items 13 to 20, wherein the guest address further includes a guest physical address.
[Item 22]
The method of any one of items 13 to 21, wherein the guest address further comprises a guest linear address.
[Item 23]
A system based on virtualization,
A processor;
A memory connected to the processor by a bus;
A logic circuit of a processor that executes an instruction, wherein the instruction is
The mapping including the translation of the guest address to the host physical address stored at least in the translation lookaside buffer (TLB) is an extended paging table (EPT) of the system based on virtualization, and the host physical corresponding to the guest physical address Synchronizing with a corresponding mapping stored at least in part in an EPT containing the translation of the address;
Selecting a mapping at least partially stored in an EPT based at least in part on operands of the instruction;
The operand includes at least one of a context descriptor and an EPT pointer.
A system based on virtualization.
[Item 24]
The processor further
Select a mapping from the EPT based in part on the context descriptor derived from the operand of the instruction;
24. The system according to item 23.
[Item 25]
The processor further
Selecting a mapping stored at least in part in the EPT based in part on the EPT pointer derived from the context descriptor;
25. The system according to item 24.
[Item 26]
The processor further
26. A system according to any one of items 23 to 25, wherein a guest address is selected based at least in part on an operand of an instruction.
[Item 27]
The logic circuit further includes a mapping stored in the TLB and a mapping stored in the EPT having the same guest address as the mapping stored in the TLB based at least in part on the mapping stored in the EPT. 27. A system according to any one of items 23 to 26, wherein the system synchronizes with the mapping.
[Item 28]
28. The system of item 27, wherein the logic circuit further flushes the stored mapping from the TLB.
[Item 29]
29. A system according to any one of items 23 to 28, wherein the logic circuit selects an execution mode of the instruction based at least in part on an operand of the instruction.
[Item 30]
The logic circuit further selects a mapping at least partially stored in the EPT based on the context descriptor derived from the first operand of the instruction;
Selecting a guest address based at least in part on the second operand of the instruction;
Selecting an instruction execution mode based at least in part on the third operand of the instruction;
Instruction execution mode is
A first mode in which only a single mapping associated with a guest address stored in the TLB is synchronized with the corresponding mapping in the EPT;
A second mode in which all mappings associated with the EPT context stored in the TLB and derived from the context descriptor are synchronized with the corresponding mapping in the EPT; and
A third mode in which all mappings stored in the TLB associated with any EPT context are synchronized with the corresponding mapping in the EPT;
30. The system according to any one of items 23 to 29, which is one of the following.
[Item 31]
The system according to any one of items 23 to 30, wherein the guest address further includes a guest physical address.
[Item 32]
32. The system of any one of items 23 to 31, wherein the guest address further includes a guest linear address.
[Item 33]
33. A system according to any one of items 23 to 32, wherein the memory further comprises dynamic random access memory (DRAM).

Shows the relationship between processes and physical memory. 3 illustrates abstractly the relationship between a virtual machine and a host machine in one embodiment. 2 illustrates a high-level structure of a virtual machine environment in one embodiment. Fig. 4 represents a processor at a functional level in one embodiment. FIG. 6 illustrates address calculation using an extended paging table in one embodiment. FIG. 6 shows an instruction execution flow in one embodiment.

Claims (34)

Decode logic for decoding an instruction specifying an instruction mode and either a context descriptor or an extended page table pointer (EPT pointer);
Execution logic that synchronizes one or more TLB entries with one or more corresponding mappings from the EPT in response to the decoded instruction. The processor of claim 1, wherein the instructions specify a guest address of a virtualization-based system that is synchronized in a first instruction mode. The instructions are synchronized in the first instruction mode based on one or more corresponding mappings of guest physical addresses from the EPT referenced by either the context descriptor or the EPT pointer. The processor according to claim 2. 4. The processor according to claim 1, wherein the corresponding mapping from the EPT is used to synchronize one or more TLB translations of a guest address with a corresponding host physical address of a virtualization based system. The processor of any one of claims 1-4, wherein the execution logic is responsive to the decoded instruction based at least in part on a microcode instruction. 6. In a second instruction mode, the one or more TLB entries are synchronized based on one or more corresponding mappings from the EPT referenced by either the context descriptor or the EPT pointer. The processor according to any one of the above. 7. In the second instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT referenced by either the context descriptor or the EPT pointer. The processor described. The processor according to any one of claims 1 to 7, wherein in the third instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT. The processor according to any one of claims 1 to 8, wherein the execution logic flushes the one or more TLB entries in response to the decoded instruction. The instruction mode specified by the instruction is:
A first instruction mode for synchronizing individual addresses;
The second instruction mode for synchronizing the TLB entry corresponding to an EPT context, and the third instruction mode for synchronizing the TLB entry derived from any EPT context. The processor according to any one of the above. Decoding an instruction specifying an instruction mode and either a context descriptor and an extended page table pointer (EPT pointer);
Synchronizing one or more TLB entries to one or more corresponding mappings from the EPT in response to the decoded instruction. The command mode specified by the command is
A first instruction mode for synchronizing individual addresses;
A plurality of instruction modes including a second instruction mode for synchronizing the TLB entry corresponding to an EPT context, and a third instruction mode for synchronizing the TLB entry derived from any EPT context. 11. The method according to 11. The method of claim 12, wherein the instruction specifies a guest address of a synchronized virtualization-based system in the first instruction mode. The instruction includes the guest physical address synchronized in the first instruction mode based on one or more corresponding mappings of guest physical addresses from the EPT referenced by either the context descriptor or the EPT pointer. The method according to claim 12 or 13. 15. The one or more TLB entries are synchronized based on one or more corresponding mappings from the EPT referenced by either the context descriptor or the EPT pointer. the method of. 16. In the second instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT referenced by either the context descriptor or the EPT pointer. The method of any one of these. The method according to any one of claims 12 to 16, wherein in the third instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT. The method according to any one of claims 11 to 17, further comprising flushing the one or more TLB entries in response to the decoded instruction. A memory for storing an instruction that specifies an instruction mode and any of a context descriptor and an extended page table pointer (EPT pointer);
A processor that executes the instructions to synchronize one or more TLB entries with one or more corresponding mappings from the EPT. The command mode specified by the command is
A first instruction mode for synchronizing individual addresses;
The method according to claim 19, wherein the second instruction mode for synchronizing the TLB entry corresponding to an EPT context is selected from a group including a third instruction mode for synchronizing the TLB entry derived from any EPT context. system. 21. The system of claim 20, wherein the instructions specify a guest address of a system based on synchronized virtualization in the first instruction mode. The instruction includes the guest physical address synchronized in the first instruction mode based on one or more corresponding mappings of guest physical addresses from the EPT referenced by either the context descriptor or the EPT pointer. The system according to claim 20 or 21, wherein the system is specified. 23. The one or more TLB entries are synchronized based on one or more corresponding mappings from the EPT referenced by either the context descriptor or the EPT pointer. System. 23. In the second instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT referenced by either the context descriptor or the EPT pointer. The system according to any one of the above. 23. A system as claimed in any one of claims 20 to 22, wherein in the third instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT. The system according to any one of claims 19 to 25, wherein the processor flushes the one or more TLB entries in response to the instruction. A program having computer-executable instructions, including synchronization instructions, said instructions on a computer,
Reading the synchronization instruction specifying an instruction mode and either a context descriptor or an extended page table pointer (EPT pointer);
A program that synchronizes one or more TLB entries with one or more corresponding mappings from an EPT in response to the synchronization command. The command mode specified by the synchronous command is
A first instruction mode for synchronizing individual addresses;
5. One of a plurality of instruction modes including a second instruction mode that synchronizes the TLB entry corresponding to an EPT context, and a third instruction mode that synchronizes the TLB entry derived from any EPT context. 27. The program according to 27. The program according to claim 28, wherein the synchronization instruction specifies a guest address of a system based on virtualization to be synchronized in the first instruction mode. The synchronization instruction is the guest physical address synchronized in the first instruction mode based on one or more corresponding mappings of the guest physical address from the EPT referenced by either the context descriptor or the EPT pointer The program according to claim 28 or 29. 31. The one or more TLB entries are synchronized based on one or more corresponding mappings from the EPT referenced by either the context descriptor or the EPT pointer. Program. 31. In the second instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT referenced by either the context descriptor or the EPT pointer. The program according to any one of the above. The program according to any one of claims 28 to 30 and 32, wherein in the third instruction mode, the one or more TLB entries are synchronized based on any corresponding mapping from the EPT. The program according to any one of claims 27 to 33, wherein the one or more TLB entries to be synchronized are flushed.

Images