Processor Feature ID Response for Virtualization

By pre-providing processor feature ID information by supervised partitions in the virtualized system, the problem of frequent visitors exit is solved, and the efficiency and performance of the system are improved.

CN112204521BActive Publication Date: 2025-09-02MICROSOFT TECHNOLOGY LICENSING LLC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN201980035486.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2018-05-25
Filing Date
2019-05-13
Publication Date
2025-09-02
Estimated Expiration
2039-05-13

AI Technical Summary

Technical Problem

In existing virtualization technologies, frequent visitor exits lead to waste of time, power and computing performance, especially when processor feature ID information is requested.

Method used

By pre-providing processor feature ID information to the processor, the frequency of visitor exit is reduced or eliminated, and directly responding to the request of the visitor partition without supervising partition intervention.

Benefits of technology

Reduces the frequency of visitors exit, reduces waste of time, power, and computing performance, and improves system efficiency and performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN112204521B_ABST
    Figure CN112204521B_ABST
Patent Text Reader

Abstract

The disclosed technology generally relates to virtualization technology. The disclosed technology includes providing, by a processor, processor feature ID information requested by or from a virtual machine (VM), a virtualized application, a virtualization-based security (VBS) user-mode process, a VBS kernel-mode process, or other guest partition. Such information can be provided based on information provided a priori to the processor (e.g., by a supervisory partition such as a hypervisor). The disclosed technology also includes, for example, a supervisory partition providing such information to the processor and a guest partition receiving such information.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Virtualization technology is employed in a variety of contexts. For example, virtualization technology may be employed to abstract physical computing resources from guest partitions, to improve utilization of physical computing resources, to support portability of guest partitions across physical devices, to protect physical computing resources from malicious and / or erroneous code running in guest partitions, to protect confidentiality, to enforce security requirements or policies, and the like. In previous virtualization technologies, a guest exit (e.g., the transfer of control of a processor from a guest partition to a supervisory partition such as a hypervisor) may occur in response to certain operations. For example, a guest exit may occur in response to a request for processor feature ID information. Summary of the Invention

[0002] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] Briefly, the disclosed technology generally relates to virtualization technology. The disclosed technology includes providing, by a processor, processor feature ID information requested by or from a virtual machine (VM), a virtualized application, a virtualization-based security (VBS) user mode process, a VBS kernel mode process, or other guest partition. Such information can be provided based on information provided a priori to the processor (e.g., by a supervisory partition such as a hypervisor). The disclosed technology also includes, for example, a supervisory partition that provides such information to the processor, and includes a guest partition that receives such information.

[0004] Other aspects and applications of the disclosed technology will be understood upon reading and understanding the accompanying drawings and description. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive examples of the present disclosure are described with reference to the following drawings. In the drawings, unless otherwise specified, like reference numerals refer to like parts throughout the various figures. These figures are not necessarily drawn to scale.

[0006] For a better understanding of the present disclosure, reference will be made to the following “Detailed Description” which is to be read in conjunction with the accompanying drawings, in which:

[0007] Figure 1 is a block diagram illustrating a physical view of one example of a suitable computing device according to aspects of the disclosed technology;

[0008] Figure 2is a block diagram illustrating a logical view of an example computing device according to aspects of the disclosed technology;

[0009] Figure 3 illustrates an example process according to aspects of the disclosed technology;

[0010] Figure 4 illustrates another example process according to additional aspects of the disclosed technology; and

[0011] Figure 5 Yet another example process according to other aspects of the disclosed technology is illustrated. DETAILED DESCRIPTION

[0012] The following description provides specific details to thoroughly understand and describe various examples of the technology. Those skilled in the art will appreciate that the technology can be practiced without many of these details. In some instances, well-known structures and functions are not shown or described in detail to avoid unnecessarily obscuring the description of the examples of the technology. Although the terms used in this disclosure are used in conjunction with the detailed description of certain examples of the technology, the terms are intended to be interpreted in the broadest reasonable manner. Although certain terms may be emphasized below, any terms interpreted in any restricted manner will be openly and explicitly defined in this "Detailed Description" section. Throughout the specification and claims, unless the context dictates otherwise, the following terms have at least the meanings explicitly associated herein. The meanings identified below do not necessarily limit the terms, but merely provide illustrative examples of the terms. For example, each of the terms "based on" and "based upon" is not exclusive and is equivalent to the term "based at least in part on," and includes options based on additional factors, some of which may not be described herein. As another example, the term "via" is not exclusive and is equivalent to the term "at least in part via" and includes the option of via additional factors, some of which may not be described herein. The meaning of "in" includes "in" and "on". The phrases "in one embodiment" or "in one example" used herein, although they may refer to the same embodiment or example, do not necessarily refer to the same embodiment or example. The use of specific textual numerical designations does not imply the presence of numerical designations of smaller values. For example, the statement "a widget selected from the group consisting of a third 'foo' and a fourth 'bar'" does not by itself mean that there are at least three 'foo' elements, nor does it mean that there are at least four 'bar' elements. Singular references are for clarity of reading only, and unless plural references are specifically excluded, singular references include plural references. Unless otherwise specifically noted, the term "or" is an inclusive "or" operator. For example, the phrase "A or B" means "A, B, or A and B". As used herein, the term "component" or "system" is intended to include various combinations of hardware, software, or hardware and software. Thus, for example, a system or component may be a process, a process executing on a computing device, a computing device, or a portion thereof.

[0013] Briefly, the disclosed technology generally relates to virtualization technology. The disclosed technology includes providing, by a processor, processor feature ID information requested by or from a virtual machine (VM), a virtualized application, a virtualization-based security (VBS) user mode process, a VBS kernel mode process, or other guest partition. For example, such a request can be generated by code executed on a guest virtual processor within a guest partition. Such information can be provided based on information provided a priori to the processor (e.g., by a supervisory partition such as a hypervisor). The disclosed technology also includes, for example, a supervisory partition that provides such information to the processor and a guest partition that receives such information.

[0014] In some examples, the disclosed technology can be employed in a virtualized / virtualized system. For example, the technology can be employed in conjunction with a hypervisor, a virtual machine, a virtualization application, a virtualization-based security (VBS) user mode process, a VBS kernel mode process, and the like. For example, the technology can include pre-calculating or otherwise determining processor feature ID information by a hypervisor or other supervisory partition, and providing the determined processor feature ID information to a processor of a computing device for subsequent use in response to a request for processor feature ID information, such as from a guest partition. For example, a request for such information from a guest partition can then be processed by the processor without intervention by the supervisory partition.

[0015] The disclosed techniques can be used to reduce and / or eliminate the frequency of VM exits or other guest exits in which the system exits from guest code execution to execute supervisor partition code. As an example of a guest exit, in response to a guest query for processor feature ID information, the supervisor partition process can take control of the processor from the guest partition, construct the processor feature ID register of the processor, and then return control of the processor to the guest partition.

[0016] In some existing virtualization systems, guest exit occurs in response to certain operations being executed from a guest partition. For example, a guest exit may occur in response to an operation being executed from a guest partition in which the CPU ID or other processor feature ID information is requested. Such exits are typically "expensive" in terms of time, power, and computing performance. For example, a guest exit may be associated with the use of processing bandwidth for supervisory partition code (e.g., overhead) rather than guest partition code (e.g., expected workload). Guest exits may also be associated with additional context switching costs due to the rewriting of processor data and / or instruction cache locations with supervisory partition code, etc.

[0017] Illustrative physical computing devices

[0018] Figure 1 is a block diagram illustrating one example of a physical view of a computing device 100 in which aspects of the present technology may be practiced. The computing device 100 may be virtually any type of general-purpose or special-purpose computing device. For example, the computing device 100 may be a user device, such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, or a smart phone. Similarly, the computing device 100 may also be a server device, such as an application server computer, a virtual computing host computer, or a file server computer. The computing device 100 may also be an IoT device connected to a network to receive IoT services. Similarly, the computing device 100 may be a server device, such as an application server computer, a virtual computing host computer, or a file server computer, as discussed in more detail below. Figure 2-Figure 5 Examples of any device shown or referred to in the . Figure 1 As shown, computing device 100 includes processing circuitry 110, operating memory 120, memory controller 130, data storage memory 150, input interface 160, output interface 170, and network adapter 180. Each of these aforementioned components of computing device 100 includes at least one hardware element.

[0019] The computing device 100 includes at least one processing circuit 110 configured to execute instructions, such as instructions for implementing the workloads, processes, or techniques described herein. The processing circuit 110 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field programmable gate array, a programmable logic device, a signal processor, or any other circuit suitable for processing data. The processing circuit 110 is an example of a core. During the runtime of the computing device 100, the aforementioned instructions, along with other data (e.g., data sets, metadata, operating system instructions, etc.), may be stored in an operating memory 120. The operating memory 120 may also include any of a variety of data storage devices / components, such as volatile memory, semi-volatile memory, random access memory, static memory, cache, buffer, or other media for storing runtime information. In one example, the operating memory 120 does not retain information when the computing device 100 is powered off. Instead, the computing device 100 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage component 150) to the operating memory 120 as part of a booting or other loading process.

[0020] The operating memory 120 may include fourth-generation double data rate (DDR4) memory, third-generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), high-bandwidth memory (HBM), hybrid memory cube memory, 3D-stacked memory, static random access memory (SRAM), or other memory, and such memory may include one or more memory circuits integrated into a DIMM, SIMM, SODIMM, or other package. Such operating memory modules or devices may be organized according to channels, ranks, and banks. For example, the operating memory devices may be coupled to the processing circuit 110 in a channel via the memory controller 130. One example of the computing device 100 may include one or two DIMMs per channel, with each channel having one or two ranks. The operating memory within a rank may operate using a shared clock and a shared address and command bus. Furthermore, the operating memory devices may be organized into several banks, where a bank can be considered an array addressed by rows and columns. Based on this organization of the operating memory, a physical address within the operating memory may be referred to by a tuple of channel, rank, bank, row, and column.

[0021] Despite the above discussion, the operational memory 120 specifically does not include or contain a communications medium, any communications medium, or any signal per se.

[0022] Memory controller 130 is configured to interface processing circuit 110 with operational memory 120. For example, memory controller 130 may be configured to interface commands, addresses, and data between operational memory 120 and processing circuit 110. Memory controller 130 may also be configured to abstract or otherwise manage certain aspects of memory management from or for processing circuit 110. Although memory controller 130 is illustrated as a single memory controller separate from processing circuit 110, in other examples, multiple memory controllers may be employed, memory controller(s) may be integrated with operational memory 120, and so on. Furthermore, a memory controller may be integrated into processing circuit 110. These and other variations are possible.

[0023] In computing device 100, data storage memory 150, input interface 160, output interface 170, and network adapter 180 are coupled to processing circuitry 110 by bus 140. Figure 1Bus 140 is illustrated as a single passive bus, but other configurations (such as a collection of buses, a collection of point-to-point links, input / output controllers, bridges, other interface circuits, or any collection thereof) may also be suitable for use to couple data storage memory 150, input interface 160, output interface 170, or network adapter 180 to processing circuit 110.

[0024] In computing device 100, data storage memory 150 is used for long-term, non-volatile data storage. Data storage memory 150 may include any of a variety of non-volatile data storage devices / components, such as non-volatile memory, a magnetic disk, a magnetic disk drive, a hard disk drive, a solid-state drive, or any other medium that can be used for non-volatile storage of information. However, data storage memory 150 specifically does not include or contain a communication medium, any communication medium, or any signal itself. In contrast to operating memory 120, data storage memory 150 is employed by computing device 100 for non-volatile, long-term data storage, rather than for runtime data storage.

[0025] Furthermore, the computing device 100 may include or be coupled to any type of processor-readable media, such as processor-readable storage media (e.g., operating memory 120 and data storage memory 150) and communication media (e.g., communication signals and radio waves). Although the term processor-readable storage media includes operating memory 120 and data storage memory 150, throughout the specification and claims, the term "processor-readable storage media," whether used in the singular or plural, is defined herein such that the term "processor-readable storage media" specifically excludes and does not include communication media, any communication media, or any signal itself. However, the term "processor-readable storage media" includes processor cache, random access memory (RAM), register memory, and the like.

[0026] The computing device 100 also includes an input interface 160 that can be configured to support the computing device 100 receiving input from a user or from other devices. In addition, the computing device 100 includes an output interface 170 that can be configured to provide output from the computing device 100. In one example, the output interface 170 includes a frame buffer, a graphics processor, a graphics processor, or an accelerator, and is configured to draw a display for presentation on a separate visual display device (such as a monitor, a projector, a virtual computing client computer, etc.). In another example, the output interface 170 includes a virtual reality device and is configured to draw and present the display for viewing. In yet another example, the input interface 160 and / or the output interface 170 can include a universal asynchronous receiver / transmitter ("UART"), a serial peripheral interface ("SPI"), an inter-integrated circuit ("I1C"), a general-purpose input / output (GPIO), etc. In addition, the input interface 160 and / or the output interface 170 can include or be connected to any number or type of peripheral devices.

[0027] In the illustrated example, computing device 100 is configured to communicate with other computing devices or entities via network adapter 180. Network adapter 180 may include a wired network adapter, such as an Ethernet adapter, a token ring adapter, or a digital subscriber line (DSL) adapter. Network adapter 180 may also include a wireless network adapter, such as a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, or a 5G adapter.

[0028] Although computing device 100 is illustrated as having certain components configured in a particular arrangement, these components and arrangements are merely one example of a computing device in which the technology may be employed. In other examples, data storage memory 150, input interface 160, output interface 170, or network adapter 180 may be coupled directly to processing circuit 110, or via an input / output controller, a bridge, or other interface circuitry. Other variations of the technology are possible.

[0029] Some examples of computing device 100 include at least one memory (e.g., operating memory 120) adapted to store runtime data and at least one processor (e.g., processing unit 110) adapted to execute processor-executable code that, in response to execution of the processor-executable code, enables computing device 100 to perform actions.

[0030] Illustrative logical computing device

[0031] Figure 2is a block diagram illustrating one example of a logical view of a computing device 200 in which aspects of the present technology may be practiced. The computing device 200 may be Figure 1 An example of a computing device 100. Figure 2 In the illustration of , the logical components of computing device 200 include guest partitions 211 - 213 , supervisor partition 230 , physical resources 241 - 243 , and processor feature ID 250 .

[0032] Physical resources 241-243 may include any of a variety of physical components, such as processor components, input / output (I / O) components, and / or other components or devices. For example, physical resources 241-243 may include any suitable combination of physical components, such as a combination of Figure 1 Although the physical resources 241-243 are illustrated as being part of the computing device 200, one or more of the physical resources 241-243 (e.g., one or more data storage memories) may be implemented external to the computing device 200. Various components or modules running on the computing device 200 (including the supervisory partition 230) may access functionality(ies) provided via the physical resources 241-243, directly and / or indirectly via other components or modules.

[0033] Supervisor partition 230 can generate any number of guest partitions, such as guest partitions 211-213. Each of guest partitions 211-213 can be a VM, a virtualized application, a VBS execution environment, a user mode process, etc. For example, guest partition 211 is illustrated as a VM having an operating system (OS) 221 and an application 222, guest partition 212 is illustrated as a virtualized application 223, and guest partition 224 is illustrated as having a process 224 executed therefrom.

[0034] Each of the guest partitions 211-213 is an isolated logical unit from which an operating system and / or other software is executed. Each of the guest partitions 211-213 may also include a guest virtual processor. The software executed in each of the guest partitions 211-213 is isolated from the software executed in each of the other guest partitions. For example, the software executed in each of the guest partitions 211-213 cannot access and does not need to know the software executed in each of the other guest partitions. Physical resources 241-243 are virtualized into guest partitions 211-213, and access to the physical resources 241-243 is managed by the supervisory partition 230.

[0035] As illustrated, computing device 100 includes a supervisory partition 230. Supervisory partition 230 may include a hypervisor, such as a virtual machine monitor, that manages access to functionality provided by physical resources 241-243. In another example, supervisory partition 230 is a kernel or a kernel-mode process of an OS, such as an OS employing VBS.

[0036] The computing device 200 also includes one or more processor feature IDs 250. For example, the processor feature ID 250 may represent a physical hardware ID register (or a set of registers) of a physical processor, such as a register (or a set of registers) containing x86 CPU ID leaf information, an ID register for an Advanced Reduced Instruction Set Computer (ARM) processor, etc. The processor feature ID 250 may also represent features supported by the processor, a feature set supported by the processor, physical characteristics of the processor, etc. For example, the processor feature ID 250 may represent processor frequency, supported physical address width, clock multiplier, power setting, instruction availability, stepping number, serial number, etc.

[0037] Illustrative Process

[0038] For the sake of clarity, the processes described herein are described with respect to the operations performed in a specific order by specific devices or components of the system. However, it should be noted that other processes are not limited to the described order, devices or components. For example, certain actions can be performed in different orders, performed in parallel, omitted, or supplemented by additional actions or features, regardless of whether such order, parallelism, actions or features are described herein. Similarly, any technology described in this disclosure can be incorporated into the described processes or other processes, regardless of whether the technology is specifically described in conjunction with the process. Regardless of whether other devices, components or systems are described herein, the disclosed processes can also be performed on such devices, components or systems or by such devices, components or systems. These processes can also be implemented in a variety of ways. For example, they can be implemented on a product (for example, as a processor-readable instruction stored in a processor-readable storage medium), or performed as a computer-implemented process. As an alternative example, these processes can be encoded as processor-executable instructions and transmitted via a communication medium.

[0039] Figure 3 An example process 300 is illustrated that generates a program from a processor of a computing device (e.g., Figure 1 The processing circuit 110 or Figure 2241, 242, or 243). Process 300 begins at 381, where a request for a processor feature ID is received. For example, this request may be received by a physical processor, and this request may have come from a guest partition. For example, this request may be generated by code executing on a guest virtual processor within the guest partition.

[0040] From 381, the process proceeds to 382, ​​where the processor looks up the processor feature ID, for example. In one example, the processor looks up the processor feature ID from a processor feature ID register, from a memory structure accessible to the processor, from a processor feature ID lookup table, etc. This lookup may also be based on information provided a priori to the processor by a hypervisor or other supervisory partition, for example, as combined with Figure 4 The process 400 is discussed further.

[0041] The process then proceeds to 383, where the processor feature ID is provided, for example, without a guest exit occurring. This may include the processor providing the requested processor feature ID to the guest partition, such as to the requesting process from the guest partition. The provided processor feature ID may be based on information previously provided to the processor. After 383, the process returns to other operations.

[0042] Figure 4 An example process 400 is illustrated that is illustrated from the perspective of a supervisory partition (e.g., a hypervisor). Figure 2 The perspective of the supervisory partition 230 is illustrated.

[0043] Process 400 begins at 481, where a value for a processor feature ID is obtained. This value can be obtained by the supervisory partition in conjunction with or in response to a setup operation for at least one of a guest partition, a guest virtual processor, or a guest virtual processor virtual trust level. For example, such a setup operation can include at least one of generating, instantiating, or starting a guest partition, a guest virtual processor, or a guest virtual processor virtual trust level. For example, the value can be obtained by reading the value of a corresponding hardware register of a physical processor of the computing device. As an example, the obtained processor feature ID value can be a value assigned by the manufacturer of the physical processor (e.g., an on-chip value), and / or a value representing and / or indicating a feature / feature set supported by the processor.

[0044] The process optionally proceeds to 482, where the processor feature ID to be stored is calculated or otherwise determined. For example, 482 may include determining whether the obtained processor feature ID value is to be stored unchanged, or whether a different value is to be stored. For example, if the supervisor partition is to "provide" a different set of processor features to the guest partition than those supported by the processor itself, for example, for enhanced guest partition portability, performance, and / or other reasons, a different value may be stored. At 482, multiple values ​​for the obtained processor feature ID value may also be determined, for example, each value associated with a different guest partition and / or guest virtual processor and / or trust level context, and / or each value being specified for a different guest partition and / or guest virtual processor and / or trust level context. In some examples, a different processor feature ID value may be employed for each virtual processor context or virtual trust level context of a virtual processor. Examples of each virtual processor context or virtual trust level context of a virtual processor are a virtual machine control structure (VMCS), a virtual machine control block (VMCB), a set of system registers containing a guest context, or other virtualized instruction set architecture-specific set of guest contexts.

[0045] The process proceeds to 483, where the processor feature ID of 482 is provided to the processor. For example, the supervisor partition can provide the processor feature ID determined at 482 to the processor for subsequent use by the processor in response to a request for processor feature ID information from guest partition software. At 483, the processor can also receive this processor feature ID information from the supervisor partition.

[0046] The process then proceeds to 484. At 484, the provided processor feature ID is stored. For example, 484 may include an action by the supervisory process causing the processor to store the provided processor feature ID, and / or an action by the processor to perform the storing. For example, the storing may include storing the processor feature ID in a processor feature ID register, in a processor feature ID lookup table in memory, etc. In yet another example, the supervisory partition code may store the processor feature ID via a processor interface instruction such as an ID_REGISTER_WRITE instruction.

[0047] In yet another example, the processor feature ID can be written to a memory structure accessible to the processor, and the location of the memory structure can be programmed into a processor register. In this and other examples, multiple memory structures can be employed, for example, to support the use of different processor feature ID values ​​for different guest partitions, for different VMCSs, virtual processor contexts, trust level contexts, etc. In use, for example, in response to a switch in control of the processor from one guest partition, guest virtual processor, or guest virtual processor virtual trust level to another, a context switch between the different memory structures can be performed by the processor or by the supervisory partition code 230.

[0048] Optionally, 484 may also include storing a conditional expression to the processor that directs the processor to the appropriate value / memory structure of the plurality of values / memory structures for a given request from the guest partition. For example, the expression may be stored via an instruction such as ID_REGISTER_WRITE(VP_CONTEXT, REGISTER_NAME, CONDITIONAL, VALUE).

[0049] As described above, this storage can also enable the processor to subsequently use the processor feature ID to respond to requests from the guest partition without causing the guest to exit. Process 400 can be repeated for additional processor feature IDs, or multiple processor feature IDs can be obtained, determined, provided, and stored in a single iteration of process 400. After 484, the process returns to other operations.

[0050] Figure 5 The diagram shows the Figure 2 Example process 500 is illustrated from the perspective of a guest partition 211, 212, or 213. Process 500 begins at 581, where a determination is made that a processor feature ID is to be obtained. For example, this determination may be made by or on a guest partition in response to a request for a processor feature ID from an application or other process executed from a guest partition. As another example, this determination may represent a request by a virtual machine to obtain a processor feature ID for use by the virtual machine.

[0051] The process then proceeds to 582, where a request for a processor feature ID is sent from the guest partition. This request may be sent to the processor. In response to the request at 582, a processor feature ID may be received from the processor at 583. As discussed above, the received processor feature ID may be based on information provided a priori to the processor by the supervisory partition. From 583, the process may proceed to 584, where the received processor feature ID is provided to the requestor (e.g., an application or other process on the guest partition). After 584, the process returns to other operations.

[0052] in conclusion

[0053] Although the above “Detailed Description” describes certain examples of the technology and describes the best mode contemplated, no matter how detailed the above is presented in the text, the technology can be practiced in many ways. The details can vary in implementation while still being covered by the technology described herein. As mentioned above, specific terms used when describing certain features or aspects of the technology should not be taken to mean that the term is redefined herein to be limited to any specific characteristics, features, or aspects associated with the term. In general, unless the “Detailed Description” expressly defines such terms, the terms used in the following claims should not be interpreted as limiting the technology to the specific examples disclosed herein. Therefore, the actual scope of the technology covers not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology.

Claims

1. A method for supporting virtualization, comprising: Before a request for a processor feature ID value is received by a physical processor from a guest partition: Receiving, by the physical processor, a processor feature ID value from a supervisory partition; as well as storing, by the physical processor, the processor feature ID value in a hardware register accessible to the physical processor; receiving, by the physical processor, the request for the processor feature ID value initiated from the guest partition; as well as In response to the request, the requested processor feature ID value is provided by the physical processor to the guest partition from the hardware register accessible to the physical processor without intervention by the supervisor partition.

2. The method of claim 1 , wherein the processor feature ID value is received from the supervisor partition in conjunction with a set operation for at least one of: the guest partition, a guest virtual processor, or a guest virtual processor virtual trust level; and the received processor feature ID value is stored by the physical processor.

3. The method of claim 2 , wherein the setting operation on at least one of: the guest partition, the guest virtual processor, or the guest virtual processor virtual trust level comprises: At least one of generating, instantiating, or initiating the at least one of the guest partition, the guest virtual processor, or the guest virtual processor virtual trust level.

4. The method of claim 1 , wherein the processor feature ID value indicates support for a first feature that is not supported by the physical processor itself, or indicates lack of support for a second feature that is supported by the physical processor itself. The method of claim 1 , wherein the processor feature ID value is different from a value assigned by a manufacturer of the physical processor. 6 . The method of claim 1 , wherein the processor feature ID value is assigned to a virtual machine control structure (VMCS) or a virtual machine control block (VMCB), and wherein different processor feature ID values ​​are assigned to different VMCSs or VMCBs.

7. The method of claim 1 , wherein the processor feature ID value is assigned to a virtual processor or a virtual trust level context of a virtual processor, and wherein different processor feature ID values ​​are assigned to different virtual processors or virtual trust level contexts of virtual processors.

8. A computing device comprising: a memory and a processor, the memory and the processor being respectively configured to store and execute instructions, the instructions including instructions for causing the computing device to perform operations including: determining, by a supervisor partition, processor characteristic ID information prior to a request for processor characteristic ID information from software executing in a guest partition, wherein the processor characteristic ID information is to be returned by the processor in response to the request for processor characteristic ID information from the software executing in the guest partition; and The determined processor feature ID information is provided by the supervisory partition to the processor for storage by the processor in a hardware register and for subsequent use by the processor without intervention by the supervisory partition, the subsequent use being in response to a request from the software for the processor feature ID information from the hardware register.

9. The computing device of claim 8, wherein the operations further comprise: The provided processor feature ID information is stored by the processor for subsequent use by the processor in response to a request for the processor feature ID information from the software.

10. The computing device of claim 8, wherein the provided processor feature ID information is stored in a processor feature ID register of the processor.

11. The computing device of claim 8, wherein the operations further comprise: receiving, by the processor, a request from the software for the processor feature ID information; as well as In response to the request, the processor provides the requested processor feature ID information based on the processor feature ID information provided by the supervisory partition.

12. The computing device of claim 8, wherein the processor feature ID information comprises a CPUID value.

13. The computing device of claim 8, wherein the processor feature ID information comprises: An indication of support for at least one feature not natively supported by the processor, or an indication of lack of support for at least one other feature natively supported by the processor.

14. A method for operating a virtual machine on a computing device, comprising: determining, by the virtual machine executing on the computing device, that a processor feature ID value is to be obtained for use by the virtual machine; Sending, by the virtual machine, a request for a processor feature ID to a processor of the computing device; as well as In response to the request, receiving the requested processor feature ID from the processor, wherein the received processor feature ID is provided by the processor without intervention of a supervisory partition and is provided from information stored in a hardware register accessible to the processor, and wherein the information stored in the hardware register accessible to the processor was provided to the processor a priori by the supervisory partition.

15. The method of claim 14, wherein the requested processor feature ID is received from the processor without requiring a virtual machine exit.

16. The method of claim 14, wherein the processor feature ID indicates support for a first processor feature that is not natively supported by the processor, or indicates lack of support for a second processor feature that is natively supported by the processor.

17. The method of claim 14, wherein the processor feature ID corresponds to at least one of: the virtual machine, the virtual processor, or a trust level of a virtual processor, and wherein a different processor feature ID corresponds to another virtual machine, another virtual processor, or a trust level of another virtual processor on the computing device.

18. The method of claim 14, wherein the processor feature ID is different from a value assigned by a manufacturer of the processor.

19. The method of claim 14, wherein the processor feature ID comprises a CPU ID value.

20. The method of claim 14, wherein the processor feature ID is received in conjunction with a setting operation for at least one of: the virtual machine, the virtual processor, or the trust level of the virtual processor, and wherein the setting operation for at least one of: the virtual machine, the virtual processor, or the trust level of the virtual processor comprises at least one of generating, instantiating, or initiating the trust level of the virtual machine, the virtual processor, or the virtual processor.

Citation Information

Patent Citations

  • Virtual Machine and / or Multi-Level Scheduling Support on Systems with Asymmetric Processor Cores

    US20120084777A1

  • Virtual secure mode for virtual machines

    US20150082305A1