Instruction set support for services that call VMM configuration without VMM intervention

Abstract

The present application discloses instruction set support for services that call VMM configurations without VMM intervention. A processing core includes instruction execution logic circuitry and a register space. In proportion to a VM entry, information indicating whether a service provided by the processing core on behalf of the VMM is enabled is fetched from a VMCS to load the register space. In response to a guest software call instruction, the instruction execution logic looks at the register space to confirm that the service has been enabled, and looks at a second register space or a memory space to obtain input parameters of the service written by the guest software.

Description

[0001] This application is a divisional application filed again for divisional application 201811075414.5. Divisional application 201811075414.5 is a divisional application of the invention patent application titled "Instruction-Set Support for Invocation of VMM-Configured Services without VMM Intervention", with an international filing date of September 28, 2012, an international application number of PCT / US2012 / 058079, and a Chinese national stage application number of 201280057792.5.

[0002] Priority Claim

[0003] This application relates to and claims the benefit of U.S. Provisional Patent Application No. 61 / 553,108, titled "Instruction-Set Support for Invocation of VMM-Configured Services without VMM Intervention", filed on October 28, 2011, which is incorporated herein by reference in its entirety. Technical Field

[0004] The field of the present invention generally relates to virtualization, and more particularly to CPU support services for VM guest software. Background Art

[0005] Many current computing systems implement "virtualization". A typical implementation is shown in Figure 1 As Figure 1 shown, a software layer 102 is imposed between the operating system 101 software and the CPU 103. This software layer 102 typically includes one or more virtual machines (VMs) 102a_1–102a_N "running on" a virtual machine monitor (VMM) 102b. Although not a strict requirement, Figure 1 shows a common configuration where different software application instances 100_1–100_N each have their own operating system instances 101_1–101_N running on dedicated virtual machines 102a_1–102a_N.

[0006] The VM presents the appearance of a CPU to the software running on it; this software is often referred to as "guest" software. As a result, at least as a first approximation, the software running on the virtual machine can "think" that it has the resources of an entire computer system. The VMM 102b is responsible for supporting multiple VMs on the underlying CPU 103. In this way, the VMM 102b coordinates the concurrent requests / requirements of multiple VMs on the CPU 103. This includes associating the allocation of the actual resources of the underlying computing system (e.g., CPU threads, system memory space, disk drive storage space) with the "virtual" computing system resources referenced by the software running on the VM.

[0007] Although guest software generally "thinks" that it is running in its own computer system and there is no VMM, this software can also be designed to know when it is running in a VM supported by a VMM. This software is sometimes referred to as "paravirtualization" or "enlightened". Software that "knows" that it is running on a VMM (e.g., in one of the VMs 102a_1–102a_N) can be designed to directly call certain "services" provided by the VMM 102b. However, currently, in order to call a VMM service, control of the CPU must first be transferred from the VM in which the application / OS instance making the call is running to the VMM; this transfer of control is sometimes referred to as a "VM exit". A possible result of a VM exit is that the CPU must "switch" its active context or state from the VM process to the VMM process. After the service has been completed, the CPU must again switch its active context / state from the VMM process back to the VM process; this return transfer of control is sometimes referred to as a "VM entry".

[0008] Figure 2 shows a prior art process for calling a VMM service. As shown in Figure 2, the application / OS instance recognizes the need to call a VMM service, 201. Before the call, the application / OS instance can fill registers and / or memory with values identifying the particular service being called and the input parameters of the service, 202. Then, in order to call the VMM service, the application / OS instance executes an instruction for calling the VMM service, 203. For example, in the case of current Intel processors with VT-x technology, the application / OS instance executes a VMCALL instruction, which is designed to explicitly call the VMM from a process running on a VM. (The application / OS instance could alternatively use another instruction that causes a VM exit and for which the VMM has been enabled for this purpose, such as CPUID or WRMSR).

[0009] In response to the execution of a VMCALL instruction, control of the CPU is passed from the VM to the VMM (VM exit), 203. In operation, the microcode within the CPU effects the above background / state switch by moving the background / state information of the VM from the software-visible CPU register space to a virtual machine control structure (VMCS) already configured by the VMM and reloading most of these same software-visible registers with the background / state information of the VMM process from other locations within the VMCS.

[0010] The VMM process refers to the memory or register values established by the calling application / OS instance to understand what service is being requested and accesses the input parameters of the service. The VMM process then executes the service, 204. This is done by executing the VMM program code written to perform the service.

[0011] After the service is completed, control is passed back from the VMM to the VM via VM entry, 205. Here, the CPU microcode loads the VM background / state from the VMCS into the software-visible register space.

[0012] An example of a VMM service is the "guest address space switch" service. This service can be used by guest software running in a virtual machine for which the VMM supports multiple address spaces, as explained below.

[0013] The VMM typically supports a "guest address space" for each of its VMs. This is a mapping from the physical addresses "seen" by the guest (guest-physical addresses) to the actual physical addresses available for accessing memory, and this mapping can also specify access rights (e.g., read / write, read-only, etc.) for each guest-physical address. In the case of current Intel processors with VT-x technology, the guest address space can be implemented using an extended page table (EPT).

[0014] In the absence of para-virtualization, the VMM will typically support a single guest address space per VM. If the guest software is para-virtualized, the VMM can establish multiple guest address spaces for a single VM, although only one is active at a time. In one instance, these address spaces can differ from each other in terms of how different memory regions are protected. There may be different guest address spaces for each application module running in the VM; the guest address space for a module can allow the module to access its own memory but not the memory belonging to other modules.

[0015] For a VM with multiple guest address space support, the VMM will need to change which guest address space is active as appropriate. An effective mechanism is for the guest software to notify the VMM when it wants to change the guest address space (e.g., when the guest OS changes from one application module to another). The guest software can notify the VMM via the "Guest Address Space Switch" service.

[0016] As noted previously, a VMCALL or other instruction can be executed to invoke the VMM for the guest address space switch service. Before the instruction is executed, the guest software can place values in registers (e.g., the EAX register) or memory to identify the "Guest Address Space Switch" service. The identifier of the address space to switch to can be specified in an additional register (e.g., the EBX register) or memory. The instruction causes a VM exit, and the service is performed by the VMM as described above. Brief Description of the Drawings

[0017] The present invention is illustrated by way of example and is not limited to the figures of the various drawings, in which like reference numerals represent like elements, where:

[0018] Figure 1 Shows a virtualization scheme (prior art);

[0019] Figure 2 shows the process for calling a VMM service from guest software (prior art);

[0020] Figure 3 Shows the process for calling a service provided by the CPU from guest software;

[0021] Figure 4 shows the guest address switch service provided by the CPU;

[0022] Figure 5 Shows an embodiment of a processor;

[0023] Figure 6 Shows an embodiment of a computing system. Detailed Description

[0024] The fact that a VM exit occurs every time the guest software calls a VMM service corresponds to a form of inefficiency. Specifically, as noted above, a large amount of register content movement needs to occur between the software-visible register space and the VMCS in order to switch the context / status of the program flow from the VM to the VMM.

[0025] One way to avoid VM exits is to embed service functionality in the CPU rather than in the VMM. Here, since the CPU rather than the VMM is performing the requested service, there is no need for control transfer or context switching within the CPU. In various embodiments, although the VMM no longer executes the service, the service is configured by the VMM. In an embodiment, guest software invokes the service via a specific instruction. This can be one of a number of existing instructions that have been redefined to call the service via the CPU, or it can be one of a number of new instructions that have been specifically defined to support the VMM-configured service. The following Figure 3 discussion discusses embodiments that implement this new approach with a single new instruction, VMFUNC, that is architected into the CPU's instruction set.

[0026] Figure 3 shows the process flow for the configuration and use of the VMFUNC instruction. As Figure 3 shown in the process, during the initial configuration of a particular instance of guest software or VM, the VMM indicates (e.g., by writing to the VM's VMCS) whether VMFUNC is enabled for the guest software / VM, and if so, which services provided by which specific CPUs are enabled for the guest software instance / VM, 301. The next VM entry loads this configuration information from the VMCS into the CPU's private control register space (i.e., the space not visible to the guest software), 302. For simplicity of discussion, the following is given as if the configuration information held in the VMCS is dedicated to a particular instance of guest software, however, the reader should understand that this information may also be dedicated to the VM on which the guest software is running.

[0027] In this embodiment, guest software that wants to invoke a VMM-configured service first loads the EAX register with the value identifying the service it wants to invoke. If appropriate, the guest software can load other registers (e.g., the EBX or ECX registers) with relevant information belonging to the service (e.g., input parameters). After these registers have been loaded, the guest software executes the VMFUNC instruction to invoke the service, 303.

[0028] Although the above discussion describes a process by which the enabling of each service for a VM is specified in the VMCS and guest software identifies the desired service by writing to the processor registers on the die, the reader will understand that any such configuration information and / or guest software service invocations can be done selectively or in combination via memory.

[0029] In response to the execution of the VMFUNC instruction, the instruction execution logic within the CPU examines the information in the EAX register to understand which specific service is being requested, and if appropriate, examines the information in other registers to obtain applicable input information, 304.

[0030] The instruction execution resources of the CPU then look at the 305 private control register, which was previously loaded 302 with VMCS information at the time of VM entry, to see if VMFUNC is enabled for guest software and, if so, whether the particular service requested by the guest software has been enabled. If VMFUNC has not been enabled for guest software, or if VMFUNC has been enabled but the particular requested service has not been enabled, the CPU hardware causes an exception, 307. If VMFUNC and the requested service have been enabled, the instruction execution resources of the CPU execute the service, 306.

[0031] Some embodiments may limit some or all services to a particular privilege level or operating mode. These embodiments may check the privilege level and operating mode before or after checking that VMFUNC and the requested service have been enabled. If the CPU is not operating at the appropriate privilege level and operating mode, the CPU may generate an exception or a VM exit.

[0032] When the service configured by the VMM called by the VMFUNC instruction is executed, all processing occurs without switching context between the VM process and the VMM process; this is different from the prior art solutions that use the VMCALL instruction to cause a VMM exit (or other instructions that cause a VM exit).

[0033] In an embodiment, the private register space (loaded from the VMCS) for an instance of guest software includes an EPT page table pointer address that points to an EPT page table hierarchy for address translation to be performed on the guest software running on the VM (i.e., for the current guest address space). Here, the translations in the EPT page table hierarchy define the (possibly multi-step) translation process from the physical address specified by the guest software ("guest-physical address") to the physical address in system memory where the data / instructions associated with a particular address actually reside, and the access rights by which the guest software can access these physical addresses.

[0034] Different components of guest software (e.g., two different applications or two different software modules of the same application) can access different physical locations of system memory. The VMM can provide protection between these components by associating each such component with its own EPT page table hierarchy. For example, if the guest software corresponds to an OS instance, the OS kernel can be arranged such that different OS modules (including modules inserted into the OS such as drivers) operate from different memory address spaces, thereby protecting each module from other modules within the same OS instance. For example, a driver can be configured to access a portion of physical memory, while other modules of the OS instance such as the OS kernel can be configured to access a second portion of physical memory. By further making the memory space of the OS kernel read-only, the OS kernel can be protected from other less trusted software modules such as drivers.

[0035] Changing the EPT page table pointer - address held in the private register space and the VMCS changes which EPT page table hierarchy and thus which translation scheme is used for the active guest software of the VM. According to one embodiment, the VMFUNC instruction is used to change the EPT page table pointer address without a VM exit. The program flow passes through the various software modules of the guest software, and the VMFUNC is executed at the transition between software modules to set their respective appropriate address spaces. For example, when the program flow passes from the OS kernel to the driver, the VMFUNC is executed as part of the transition to set the address space of the driver. Similarly, when the program flow passes back from the driver to the OS kernel, the VMFUNC is executed again at the transition to switch back to the address space of the OS kernel.

[0036] Recall that in Figure 3 Step 302, the private register space is loaded from the VMCS via a VM entry. In an embodiment, if the guest address space switching service is to be enabled for the guest software, the address in the VMCS that identifies the "pointer table" is also loaded from the VMCS into the private register space. The pointer table corresponds to a set of different page table hierarchies that can be utilized from the guest software. In an embodiment, the pointer table is pre-configured by the VMM.

[0037] Figures 4a and 4b relate to an embodiment of implementing a guest address switching service in CPU hardware. Figure 4a is drawn from the perspective that after a VM entry 430 has occurred, and as part of the VM entry process, the private control register spaces 401, 402, 403 have been loaded by the CPU using information from the VMCS 404, which specifies the following: i) whether the VMFUNC has been enabled 401; ii) whether the guest address switching has been enabled 402; iii) the address 403 of the pointer table 407; iv) a pointer 409 to the initial page table hierarchy A 410.

[0038] Although the guest software is executing, the page table pointer address in the private register space 409 points to the page table hierarchy 410, which includes the appropriate address translation information for the guest software. Subsequently, the guest software decides to execute a VMFUNC instruction to invoke the guest address switch service. When setting the input parameters of the VMFUNC instruction 440, a location in memory or a register (in an embodiment, the EAX register 411) is loaded with a value identifying the guest address switch service, and a second location in memory or a register (in an embodiment, the ECX register 412) is loaded with a value of an entry 413 in the pointer table 407 where the page table pointer address 414 (represented by the page table hierarchy B 415) of the address space to be switched to is located.

[0039] When executing the instruction, the CPU execution unit resource 416 first reads the register / memory space 411 to understand that the guest address switch service is being invoked, and reads the private register spaces 401 and 402 to check whether VMFUNC has been enabled for the guest software and, if so, whether the guest address switch has been enabled for the guest software, 450. After confirming that VMFUNC and the guest address space switch have been enabled, the CPU execution unit resource 416 then reads the register space 403 (the address of the pointer table) and the register / memory space 412 (indicating the selected entry in the pointer table) to obtain the new page table pointer address 414 (at the entry 413 in the pointer table 407), 460, loads it 470 into the register space 409 and stores it 470 into the register or memory space allocated to the VMCS 404. After the new page table pointer address is loaded, the translation of the guest software is now performed using the page table hierarchy 415 instead of the page table hierarchy 410 (i.e., the guest address space has been switched).

[0040] Although the above discussion is devoted to the guest address switch service implemented in the CPU hardware, other services provided by the VMM can also be integrated into the CPU. These include but are not limited to the following: 1) mapping and unmapping specific regions of memory with certain permissions; 2) handling virtual interrupts in a specific manner (e.g., defining the operating characteristics of a virtual interrupt controller); 3) pinning memory to be used as an I / O buffer. Note that items 1) and 3) above and the guest address space switch function all change the memory configuration.

[0041] Figure 5 A general processing core 500 is shown, which is considered to describe many different types of processing core architectures, such as complex instruction set (CISC), reduced instruction set (RISC), and very long instruction word (VLIW). Figure 5The general processing core 500 includes: 1) a fetch unit 503 that fetches instructions (e.g., from a cache or memory); 2) a decode unit 504 that decodes the instructions; 3) a dispatch unit 505 that determines the timing and / or order of instruction issue to the execution units 506 (note that the scheduler is optional); 4) execution units 506 that execute the instructions; 5) a retirement unit 507 that represents the successful completion of the instructions. Note that the processing core may or may not partially or fully include microcode 508 to control the micro-operations of the execution units 506. The instruction execution resources / logic mentioned in the previous discussion may be implemented using one or more of the execution units within the execution unit 506.

[0042] A processing core having the foregoing functions may also be implemented in various computing systems. Figure 6 An embodiment of a computing system (e.g., a computer) is shown. Figure 6 An exemplary computing system includes: 1) one or more processing cores 601 that may be designed to include two and three register scalar integer and vector instruction executions; 2) a memory control hub (MCH) 602; 3) a system memory 603 (which exists in different types, such as DDR RAM, EDO RAM, etc.); 4) a cache 604; 5) an I / O control hub (ICH) 605; 6) a graphics processor 606; 7) a display / screen 607 (which exists in different types, such as a cathode ray tube (CRT), flat panel, thin film transistor (TFT), liquid crystal display (LCD), DPL, etc.) and one or more I / O devices 608.

[0043] One or more processing cores 601 execute instructions to perform any software routines implemented by the computing system. The instructions frequently involve certain kinds of operations performed on data. Both the data and the instructions are stored in the system memory 603 and the cache 604. The cache 604 is typically designed to have a shorter latency than the system memory 603. For example, the cache 604 may be integrated on the same silicon die as the processor and / or constructed with faster SRAM cells, while the system memory 603 may be constructed with slower DRAM cells. By often storing the more frequently used instructions and data in the cache 604 rather than the system memory 603, the overall performance efficiency of the computer system is improved.

[0044] System memory 603 is intentionally made available for use by other components in the computing system. For example, data received from the various interfaces of the computing system (such as a keyboard and mouse, printer port, LAN port, modem port, etc.) or obtained from memory elements of the computing system (such as a hard disk drive) is often temporarily queued into system memory 603 before being operated on by one or more processors 601 during the execution of a software program. Similarly, data determined by a software program to be sent from the computing system to an external entity or stored in a memory element via one of the computing system interfaces is often temporarily queued into system memory 603 before being transmitted or stored.

[0045] The ICH 605 is responsible for ensuring that this data is correctly transferred between system memory 603 and its appropriate corresponding computing system interfaces (and memory devices, if the computing system is so designed). The MCH 602 is responsible for managing the various competing requests for access to system memory 603 among the processors 601, interfaces, and memory elements, which competing requests occur in close temporal proximity to one another.

[0046] One or more I / O devices 608 are also implemented in a typical computing system. I / O devices generally are responsible for transferring data to and / or from the computing system (such as a networking adapter) and / or for large-scale non-volatile storage in the computing system (such as a hard disk drive). The ICH 605 has a bidirectional point-to-point link between itself and the illustrated I / O devices 608.

[0047] The processes taught by the above discussion may be executed using program code, such as machine-executable instructions, which cause a machine to execute the instructions to implement certain functions. In this context, a "machine" can be an electronic circuit (such as a "logic circuit" implemented in transistors) in a semiconductor chip designed to execute instructions, such as a general-purpose processor and / or a special-purpose processor, that converts intermediate form (e.g., abstract) instructions into processor-specific instructions (e.g., an abstract execution environment, such as a "virtual machine" (e.g., Java virtual machine) interpreter, common language runtime, high-level language virtual machine, etc.). The processes taught by the above discussion may also be executed (in lieu of or in combination with a machine) by an electronic circuit designed to execute the process (or a portion thereof) without executing program code.

[0048] It is believed that the processes taught in the above discussion can also be described in source-level program code in various object-oriented or non-object-oriented computer programming languages (such as Java, C#, VB, Python, C, C++, J#, APL, Cobol, Fortran, Pascal, Perl, etc.) supported by various software deployment frameworks (such as.NET, Mono, Java of Microsoft Corporation, Fusion of Oracle Corporation, etc.). The source-level program code can be converted into program code in an intermediate form (such as Java bytecode, Microsoft Intermediate Language, etc.), which can be understood as an abstract execution environment (such as Java Virtual Machine, Common Language Runtime, High-Level Language Virtual Machine, interpreter, etc.), or can be directly compiled into object code.

[0049] According to various methods, through 1) compiling the program code in the intermediate form (such as at runtime (such as JIT compiler)), 2) interpreting the program code in the intermediate form, or 3) a combination of compiling the program code in the intermediate form and interpreting the program code in the intermediate form at runtime, the abstract execution environment can convert the program code in the intermediate form into processor-specific code. The abstract execution environment can run on various operating systems (such as UNIX, LINUX, Microsoft operating systems including the Windows family, Apple computer operating systems including MacOS X, Sun / Solaris, OS / 2, Novell, etc.).

[0050] Articles can be used to store program code. Articles storing program code can be embodied as, but not limited to, one or more memories (such as one or more flash memories, random access memories (static, dynamic or others)), optical discs, CD-ROMs, DVDROMs, EPROMs, EEPROMs, magnetic or optical cards, or other types of machine-readable media suitable for storing electronic instructions. Program code can also be downloaded from a remote computer (such as a server) to a requesting computer (such as a client) as a data signal embodied in a propagation medium (such as via a communication link (such as a network connection)).

[0051] In the foregoing specification, the invention has been described with reference to specific exemplary embodiments of the invention. However, it is apparent that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims.

Claims

1. A processor, comprising: At least one register for storing information on whether the processor is enabled to perform virtual machine monitor (VMM) services for guest software of a virtual machine (VM); A decoding unit for decoding instructions of the guest software of the VM; And An execution unit coupled to the decoding unit and the at least one register, the execution unit being configured to perform operations corresponding to the instructions, including: Determining whether the processor is enabled to perform the VMM services at least in part based on the information in the at least one register; and When the determination is that the processor is enabled to perform the VMM services, performing the VMM services without exiting the VM during the execution of the instructions; or When the determination is that the processor is not enabled to perform the VMM services, causing an exception.

2. The processor according to claim 1, wherein The instructions indicate a value identifying the VMM service as one of a plurality of VMM services.

3. The processor according to claim 1, wherein, The execution unit for performing the VMM services is configured to read a register to obtain parameters for the VMM services.

4. The processor according to claim 1, wherein The execution unit for determining whether the processor is enabled to perform the VMM services is configured to: Determine the privilege level corresponding to the instructions; And Determine whether the processor is enabled to perform the VMM services at the privilege level.

5. The processor according to any one of claims 1 to 4, wherein, The execution unit for performing the VMM services is configured to obtain an address of a page table hierarchy for a guest address space different from the current guest address space.

6. The processor according to claim 5, wherein, The execution unit for obtaining the address of the page table hierarchy is configured to perform an operation including the following steps: Reading the address of a table of values from a register; and Obtaining the address of the page table hierarchy from an entry in the table.

7. The processor according to any one of claims 1 to 4, wherein, The execution unit for performing the VMM services is configured to apply permissions to a memory region.

8. The processor according to any one of claims 1 to 4, wherein, The execution unit for performing the VMM services is configured to configure a memory region to be used as an I / O buffer.

9. The processor according to any one of claims 1 to 4, wherein, When the determination is that the processor is not enabled to perform the VMM services, the processor is configured to cause the VM to exit.

10. A system, comprising: A processor according to any one of claims 1 to 4; And A memory coupled to the processor.

11. A processor, comprising: At least one register for storing information on whether the processor is enabled to perform services for guest software of a virtual machine (VM); A decoding unit for decoding instructions of the guest software of the VM; And An execution unit coupled to the decoding unit and the at least one register, the execution unit being configured to perform operations corresponding to the instructions, including: Determining whether the processor is enabled to perform the services at least in part based on the information in the at least one register; and When the determination is that the processor is enabled to execute the service, execute the service without exiting the VM during the execution of the instruction, and executing the service includes: obtaining an address of a page table hierarchy for a guest address space different from the current guest address space of the guest software for the VM; or When the determination is that the processor is not enabled to execute the service, cause an exit from the VM.

12. The processor according to claim 11, wherein, The execution unit for obtaining the address of the page table hierarchy is configured to perform an operation including the following steps: Read the address of a table of values from a register; and Obtain the address of the page table hierarchy from an entry of the table.

13. The processor according to claim 11, wherein, When the determination is that the processor is not enabled to execute the service, the processor is configured to cause an exit from the VM.

14. The processor according to any one of claims 11 to 13, wherein The instruction indicates a value for identifying the service as one of a plurality of VMM services.

15. The processor according to any one of claims 11 to 13, wherein, The execution unit for executing the service is configured to read a register to obtain a parameter for the service.

16. The processor according to any one of claims 11 to 13, wherein, The execution unit for determining whether the processor is enabled to execute the service is configured to: Determine a privilege level corresponding to the instruction; And Determine whether the processor is enabled to execute the service at the privilege level.

17. A method executed by a processor, the method including: Read information from at least one register regarding whether the processor is enabled to execute a virtual machine monitor (VMM) service for guest software of a virtual machine (VM); Decode an instruction of the guest software of the VM; And Perform an operation corresponding to the instruction, including: Determine whether the processor is enabled to execute the VMM service based at least in part on the information read from the at least one register; and When the determination is that the processor is enabled to execute the VMM service, execute the VMM service without exiting the VM during the execution of the instruction; or When the determination is that the processor is not enabled to execute the VMM service, cause an exception.

18. The method according to claim 17, wherein, The instruction indicates a value for identifying the VMM service as one of a plurality of VMM services.

19. The method according to claim 17, wherein, Executing the VMM service includes: reading a register to obtain a parameter for the VMM service.

20. The method according to claim 17, wherein Determining whether the processor is enabled to execute the VMM service includes: Determine a privilege level corresponding to the instruction; and Determine whether the processor is enabled to execute the VMM service at the privilege level.

21. The method according to any one of claims 17 to 20, wherein Executing the VMM service includes: obtaining an address of a page table hierarchy for a guest address space different from the current guest address space.

22. The method according to claim 21, wherein, Obtaining the address of the page table hierarchy includes: Read the address of a table of values from a register; and Obtain the address of the page table hierarchy from an entry of the table.

23. The method according to any one of claims 17 to 20, wherein Executing the VMM service includes: applying a permission to a memory region.

24. The method according to any one of claims 17 to 20, wherein Executing the VMM service includes: configuring a memory region to be used as an I / O buffer.

25. The method according to any one of claims 17 to 20, further comprising: When the determination is that the processor is not enabled to execute the VMM service, cause an exit from the VM.

26. A processing core, including: Instruction execution logic circuitry; and a register space, which, in proportion to the entry of the VM, is loaded from the VMCS with information indicating whether services provided by the processing core on behalf of the VMM are enabled wherein the instruction execution logic circuit is configured to, in response to the guest software executing an instruction that invokes a service configured by the VMM, examine the register space to confirm that the service configured by the VMM has been enabled, and examine a second register space or a memory space to obtain input parameters of the service configured by the VMM written by the guest software, wherein the second register space or the memory space includes the address of a pointer table 27. A method, comprising: a virtual machine monitor (VMM) writing to a virtual machine control structure (VMCS) to indicate whether an instruction VMFUNC is enabled for guest software or a virtual machine (VM); if VMFUNC is enabled for guest software or the VM, determining which services provided by a particular central processing unit (CPU) are enabled for the guest software or the VM; a next VM entry loading configuration information from the VMCS into a private control register space of the CPU; the guest software executing a VMFUNC instruction to invoke a service; in response to the execution of the VMFUNC instruction, instruction execution logic within the CPU examining information in an EAX register to understand which particular services are being requested and accessing its input parameters; determining whether VMFUNC is enabled for the guest software and the requested service is enabled; if VMFUNC is enabled for the guest software and the requested service is enabled, the instruction execution resources of the CPU executing the service

Images