Mapping virtual processor cores to heterogeneous physical processor cores

Abstract

The virtual processor core is mapped to a heterogeneous physical processor core. A device determines that a processor system has a heterogeneous set of processor cores that includes a first physical core having a first attribute and a second physical core having a second capability different from the first capability. The device associates a plurality of physical cores with a virtual machine (VM). This includes the device associating the first physical core with the first virtual core, including exposing the first virtual core having a first set of features to the VM based on the first physical core having the first capability. This also includes the device associating the second physical core with a second virtual core of the VM, including exposing to the VM, based on the second physical core having a second capability, the second virtual core having a second set of features different from the first set of features.

Description

Background Art

[0001] Hypervisor-based virtualization technology allocates portions of a computer system's physical resources (e.g., processor cores, physical memory areas, storage resources) into separate partitions and executes software within each partition. Thus, hypervisor-based virtualization technology facilitates the creation of virtual machines (VMs), each of which executes guest software, such as an OS and other software executed therein. The computer system that hosts the VMs is typically referred to as a VM host (sometimes referred to as a "VM host node"). Although hypervisor-based virtualization technology can take many forms, many technologies use an architecture that includes: a hypervisor that directly accesses the hardware and operates in an execution environment separate from all other software in the system; a host partition that executes a host OS and a host virtualization stack; and one or more guest partitions corresponding to the VMs. The host virtualization stack within the host partition manages the guest partitions. Therefore, the hypervisor grants the host partition greater access rights to the hypervisor itself and hardware resources than it grants to guest partitions.

[0002] A virtualization service provider operates multiple VM hosts to provide VM hosting services to multiple tenants. In doing so, the virtualization service provider can collocate VMs from multiple tenants on a single VM host. Examples of virtualization service providers include AZURE, operated by Microsoft Corporation of Redmond, Washington; Amazon Web Services (AWS), operated by Amazon.com Inc. of Seattle, Washington; and Google Cloud Platform (GCP), operated by Google LLC of Mountain View, California.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above.Rather, this background is provided merely to illustrate one example technology area where some embodiments described herein may be practiced. Summary of the Invention

[0004] In some aspects, the technology described herein relates to methods, systems, and computer program products for associating physical processor cores of a physical processor system with virtual processor cores of a virtual machine (VM), including: determining that the processor system has a heterogeneous set of physical processor cores, the heterogeneous set of physical processor cores including a first physical processor core having a first capability and a second physical processor core having a second capability different from the first capability; and associating multiple physical processor cores with the VM. Associating the multiple physical processor cores with the VM includes associating the first physical processor core with a first virtual processor core of the VM, including: based on the first physical processor core having the first capability, exposing the first virtual processor core to the VM having a first feature set); and associating the second physical processor core with the second virtual processor core of the VM, including: based on the second physical processor core having the second capability, exposing the second virtual processor core to the VM having a second feature set different from the first feature set.

[0005] 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 as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the accompanying drawings. It should be understood that these drawings depict only typical embodiments of the systems and methods described herein and are, therefore, not to be considered limiting of their scope, and that certain systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0007] Figure 1A An example computer architecture that facilitates mapping virtual processor cores of a virtual machine (VM) to heterogeneous physical processor cores of a processing system is illustrated;

[0008] Figure 1B An example of mapping virtual processor cores of a VM to heterogeneous physical processor cores is illustrated;

[0009] Figure 2 illustrates an example of a processor manager; and

[0010] Figure 3 A flow chart illustrating an example of a method for associating physical processor cores of a physical processor system with virtual processor cores of a VM is illustrated. DETAILED DESCRIPTION

[0011] Multiprocessing refers to the use of two or more central processing units (CPUs) or processors within a single computer system (e.g., using multiple processor cores on a single CPU die, using multiple CPU dies on a single package, or using multiple packages on a single system unit). In conventional multiprocessing computer systems, the multiple processor cores are homogeneous. That is, each processor core in the computer system is identical in capabilities and performance to the other processor cores in the computer system. The hypervisor treats the processor cores in these homogeneous multiprocessing environments as functionally identical. For example, the hypervisor can utilize preference rules to optimize performance, but when associating the virtual processor cores of a virtual machine (VM) with available physical processor cores, the hypervisor treats the available physical processor cores as interchangeable. For example, typically, the hypervisor can associate a given virtual processor core with any physical processor core (e.g., because the supported processor feature set is the same across homogeneous processors). Example preference rules may include associating a VM's virtual processor cores with physical processor cores located in the same L3 cache domain (e.g., rather than using physical processor cores in different L3 cache domains), or associating a VM's virtual processor core(s) with physical processor core(s) that are closest to the device with which the VM interacts (e.g., storage controller, network interface card, graphics processing unit). However, in either of these cases, the processor cores are still considered functionally equivalent.

[0012] Recently, multi-processing computer systems have introduced heterogeneous processor cores. For example, the 12th generation (ALDER LAKE) of the INTEL CORE series of processors introduced a heterogeneous processor architecture in which each of the multiple processor cores on the CPU die can be a "performance" core (P core) or an "efficiency" core (E core). Similarly, the Advanced RISC Machine (ARM) architecture includes a "big.LITTLE" heterogeneous processor architecture that uses a combination of "big" cores and "LITTLE" cores on the CPU die. Typically, P cores (INTEL) and big cores (ARM) provide enhanced computing performance at the expense of reduced energy efficiency; in contrast, E cores (INTEL) and LITTLE cores (ARM) provide enhanced energy efficiency at the expense of reduced computing performance. In this specification and the following claims, a processor core designed to enhance computing performance (e.g., P core, big core) is a "performance core", and a core designed to enhance energy efficiency (e.g., E core, LITTLE core) is an "efficiency core".

[0013] Depending on the architectural design, the processor cores in a heterogeneous processor architecture differ in one or more performance capabilities or instruction set architecture (ISA) capabilities. Processor cores may be heterogeneous in performance capabilities due to differences in base clock frequency, maximum clock frequency, associated cache size, number and / or type of available arithmetic logic units (ALUs), pipeline architecture, etc. Due to differences in the processor instructions supported by the processor cores, they may be heterogeneous in ISA capabilities. For example, a performance core may support a single instruction multiple data (SIMD) instruction ISA extension, while an efficiency core may not. It is worth noting that if the processor cores are heterogeneous only in performance capabilities, then they are interchangeable in the workloads that can be executed. However, if the processor cores are heterogeneous in ISA capabilities, then they may not be interchangeable in the workloads that can be executed.

[0014] Even when executing at heterogeneous processor architectures (where the processor cores have different performance capabilities but comparable ISA capabilities), contemporary hypervisors do not distinguish between available physical processor cores when associating virtual processor cores with physical processor cores. Because contemporary hypervisors treat the physical processor cores in these heterogeneous processor architectures as interchangeable, the guest operating system (OS) lacks knowledge of the differences between the physical processor cores associated with its virtual processor cores. This lack of knowledge can result in inefficiencies in how the guest OS assigns its workload. For example, the guest OS may assign higher priority tasks (e.g., foreground user interface tasks) to virtual processor cores associated with efficiency cores, and may assign lower priority tasks (e.g., background data acquisition tasks) to virtual processor cores associated with performance cores. These assignments mean that higher priority tasks are executed at physical processor cores designed for efficiency, while higher priority tasks are executed at physical processor cores designed for performance. This can result in a reduced user experience (e.g., poor user interface performance), wasted energy, excessive heat generation, etc.

[0015] Additionally, if the hypervisor treats physical processor cores in a heterogeneous processor architecture as interchangeable, where the processor cores differ in ISA capabilities, software failures may result. For example, a guest OS may assign a task that uses SMID instructions to a virtual processor core associated with an efficiency core that lacks SMID execution capability due to a lack of knowledge of the differences between the physical processor cores associated with its virtual processor cores. Consequently, when the task attempts to execute the SMID instruction, it will fail (e.g., generate an exception or crash).

[0016] The described embodiments leverage an understanding of heterogeneous processor architectures when associating physical processor cores with VMs. An embodiment determines that a processor system has a heterogeneous set of physical processor cores. For example, a hypervisor determines that a processor system has performance and efficiency cores. Then, when assigning virtual processor cores of a VM to the physical processor cores of the processor system, an embodiment exposes the underlying heterogeneity of the physical processor cores to the VM. Continuing with the example, the hypervisor assigns an efficiency core to a first virtual processor core of the VM and exposes the first virtual processor core as an efficiency core. Continuing with the example, the hypervisor also assigns a performance core to a second virtual processor core of the VM and exposes the second virtual processor core as a performance core. Because the hypervisor exposes the first virtual processor core as an efficiency core and the second virtual processor core as a performance core, the guest OS executing at the VM can make intelligent scheduling decisions, which can enhance the user experience, use energy efficiently, reduce heat generation, and avoid software failures.

[0017] Figure 1A An example 100a of a computer architecture that facilitates mapping virtual processor cores of a VM to heterogeneous physical processor cores of a processing system is illustrated. In example 100a, the computer architecture includes a computer system 101 that includes hardware 102. The illustrated example of hardware 102 includes a processor system 103. In an embodiment, the processor system 103 is a CPU that includes one or more processor cores or multiple CPUs that each include one or more processor cores. Regardless of the arrangement of the processor system 103, in Figure 1A In FIG, the processor system 103 includes multiple processor cores. Figure 1A These processor cores are illustrated as physical processor cores 107 (e.g., physical core 107a through physical core 107n, where the ellipses indicate that there can be any number of physical processor cores 107). For example, each of physical processor cores 107 is a single-threaded processor core or a thread in a simultaneous multi-threaded (SMT) core.

[0018] The illustrated example of hardware 102 also includes memory 104 (e.g., system or main memory), storage media 105 (e.g., a single computer-readable storage medium or multiple computer-readable storage media), and network interface 106 (e.g., one or more network interface cards). Although not shown, other examples of hardware 102 include a trusted platform module (TPM) for facilitating measured boot features, an input / output (I / O) memory management unit (IOMMU) that connects an I / O bus (and any devices connected thereto) that supports direct memory access (DMA) to memory 104, a graphics processing unit (GPU) for rendering image data, a video display interface for connecting to display hardware, a user input interface for connecting to a user input device, an external bus for connecting to external devices, and the like.

[0019] As shown in example 100a, a hypervisor 109 executes directly on the hardware 102. The hypervisor 109 allocates hardware resources (e.g., processor system 103, memory 104, I / O resources) into multiple partitions. In an embodiment, these partitions include a host partition 110 in which a host OS (not shown) executes. In an embodiment, these partitions also include a client partition 111 in which a client OS executes (e.g., client partition 111a in which client OS 112 executes through client partition 111n in which client OS 113 executes, where the ellipsis indicates that the hypervisor 109 can operate any number of client partitions).

[0020] As illustrated, host partition 110 includes a virtualization stack 117 that creates, manages, and destroys each of client partitions 111 using application programming interface (API) calls (e.g., hypercalls) to hypervisor 109. In an embodiment, virtualization stack 117 determines which portion(s) of memory 104 to allocate to each client partition, operates paravirtual drivers that multiplex client partition accesses to physical hardware devices (e.g., storage media 105, network interface 106), and facilitates restricted communication between partitions via a VM bus (not shown), among other things.

[0021] In an embodiment, the hypervisor 109 creates one or more virtual processor cores for each partition. Figure 1A In FIG, host partition 110 includes virtual processor cores 114. Virtual processor cores 114 include virtual cores 114a through 114n, where the ellipsis indicates that host partition 110 can have any number of virtual processor cores 114. Figure 1AIn FIG, client partition 111a further includes virtual processor cores 115. Virtual processor cores 115 include virtual cores 115a through 115n, where the ellipsis indicates that client partition 111a can have any number of virtual processor cores 115. Figure 1A , client partition 111n also includes virtual processor cores 116. Virtual processor cores 116 include virtual cores 116a through 116n, where the ellipses indicate that client partition 111n may have any number of virtual processor cores 116.

[0022] In an embodiment, the hypervisor 109 manages the use of these virtual processor cores by the processor system 103 (e.g., physical processor cores 107) using the processor manager 118. In an embodiment, the hypervisor 109 coordinates with the virtualization stack 117 to manage the use of the virtual processor cores by the processor system 103. Figure 1A , the processor manager 118 is illustrated as being split between the hypervisor 109 (processor manager 118a) and the virtualization stack 117 (processor manager 118b), meaning that either the virtualization stack 117 or the hypervisor 109 can perform any of the functions of the processor manager 118 described herein.

[0023] In an embodiment, the hypervisor 109 also allocates a portion of memory 104 to each partition and intercepts and routes any interrupts generated by each partition, etc. In an embodiment, the hypervisor 109 uses a second level address translation (SLAT) to isolate the memory allocated to each partition created by the hypervisor 109 from other partition(s) created by the hypervisor 109. For example, the hypervisor 109 may use one or more SLAT tables to map system physical addresses (SPAs) in memory 104 to guest physical addresses (GPAs) that make up the memory space of each partition.

[0024] While the physical processor cores of a processor system are conventionally homogeneous (e.g., identical in terms of capabilities and performance), in an embodiment, the physical processor cores 107 are heterogeneous. Figure 1A, physical processor cores 107 are illustrated as having one or more capabilities 108 (e.g., capability 108a of physical core 107a through capability 108n of physical core 107n). In some embodiments, physical processor cores 107 are heterogeneous in terms of performance capabilities; in these embodiments, capabilities 108 represent physical capabilities that affect the performance of each core. Examples of capabilities 108 include base clock frequency, maximum clock frequency, associated cache size, number of ALUs, ALU type, and pipeline architecture. In other embodiments, physical processor cores 107 are heterogeneous in terms of ISA capabilities; in these embodiments, capabilities 108 represent ISA differences (e.g., different subsets of supported instructions). In embodiments, physical processor cores 107 are heterogeneous in terms of performance and ISA capabilities.

[0025] In an embodiment, the heterogeneity of the physical processor cores 107 is exposed to the partition via the partition's virtual processor cores or via an Advanced Configuration and Power Interface (ACPI) table associated with the partition. For example, in example 100a, each virtual processor core has an associated feature set (e.g., feature set 119a for virtual core 114a, feature set 119n for virtual core 114n, feature set 120a for virtual core 115a, feature set 120n for virtual core 115n, feature set 121a for virtual core 116a, and feature set 121n for virtual core 116n).

[0026] In an embodiment, the processor manager 118 determines that the physical processor cores 107 of the processor system 103 are heterogeneous in terms of performance capabilities and / or ISA capabilities. For example, the processor manager 118 determines that one or more of the capabilities 108a of the physical core 107a is different from the capabilities 108n of the physical core 107n. The processor manager 118 then exposes these differences to the VM when associating the VM's virtual processor core with the physical processor core 107. For example, Figure 1B An example 100b of mapping virtual processor cores of a VM to heterogeneous physical processor cores is illustrated. In example 100b, processor manager 118 associates virtual core 115a of client partition 111a with physical core 107a, and processor manager 118 associates virtual core 115n of client partition 111a with physical core 107. As shown in example 100b, feature set 120a of virtual core 115a reflects capabilities 108a of physical core 107a, and feature set 120n of virtual core 115n reflects capabilities 108n of physical core 107n.

[0027] Figure 2 Pictured Figure 1A and Figure 1BExample 200 of the processor manager 118. Figure 2 Each of the internal components of the processor manager 118 depicted in FIGURE 1 represents various functions that the processor manager 118 may implement in accordance with various embodiments described herein. However, it will be appreciated that the depicted components (including their identities and arrangements) are presented merely as an aid in describing example embodiments of the processor manager 118. In particular, it should be noted that in various implementations, the components of the processor manager 118 may be arranged differently between the hypervisor 109 (e.g., processor manager 118a) and the virtualization stack 117 (e.g., processor manager 118b).

[0028] exist Figure 2 , the processor manager 118 includes a topology identification component 201. In an embodiment, the topology identification component 201 identifies the topology of the processor system 103. In an embodiment, the topology identification component 201 identifies the heterogeneous processor architecture of the processor system 103, such as heterogeneous physical processor cores 107. As mentioned, if the processor cores are heterogeneous only in terms of performance capabilities, then the cores are interchangeable in the workloads that can be executed. However, if the processor cores are heterogeneous in terms of ISA capabilities, then the cores may not be interchangeable in the workloads that can be executed. In an embodiment, the topology identification component 201 also determines whether the processor cores of the identified topology are interchangeable in the workloads that can be executed.

[0029] exist Figure 2 , processor manager 118 also includes a processor association component 202. In an embodiment, processor association component 202 manages the association and disassociation of various virtual processor cores (e.g., virtual processor core 114, virtual processor core 115, virtual processor core 116) with various physical processor cores (e.g., physical processor core 107). In some embodiments, processor association component 202 is a scheduler operating at hypervisor 109. In other embodiments, processor association component 202 is a scheduler operating at host partition 110. In the latter embodiment, processor association component 202 is a scheduler of the host OS (e.g., operating at (e.g., part of virtualization stack 117)).

[0030] In an embodiment, if the topology identification component 201 determines that the processor cores of the identified topology are interchangeable in the workloads that can be executed (e.g., all processor cores each support the same processor instruction set), the processor association component 202 maintains a "soft affinity" for associating virtual efficiency cores with physical efficiency cores and virtual performance cores with physical performance cores. In some embodiments, soft affinity is a preference, but not a requirement, that virtual efficiency cores be associated with physical efficiency cores and virtual performance cores be associated with physical performance cores. In an embodiment, if the topology identification component 201 determines that the processor cores of the identified topology are not interchangeable in the workloads that can be executed (e.g., different processor cores support different processor instruction sets), the processor association component 202 maintains a "hard affinity" for associating virtual efficiency cores with physical efficiency cores and virtual performance cores with physical performance cores. In some embodiments, hard affinity requires that virtual efficiency cores be associated with physical efficiency cores and virtual performance cores be associated with physical performance cores.

[0031] exist Figure 2 , the processor manager 118 also includes a topology presentation component 203. In an embodiment, in conjunction with the operation of the processor association component 202, the topology presentation component 203 exposes heterogeneous virtual processor cores to the VM. In one example, the topology presentation component 203 exposes the heterogeneous virtual processor cores via the capabilities of the virtual cores themselves. Some embodiments expose heterogeneity via the CPU identifier (CPUID) of each virtual core. For example, if a first virtual processor core is associated with an efficiency core, the topology presentation component 203 configures the first virtual processor core using the CPUID of the physical processor core model of the efficiency core; if a second virtual processor core is associated with a performance core, the topology presentation component 203 configures the second virtual processor core using the CPUID of the physical processor core model of the performance core. In another example, the topology presentation component 203 exposes the heterogeneous virtual processor cores via ACPI table entries. For example, if the first virtual processor core is associated with an efficiency core, the topology presentation component 203 configures an entry in the ACPI table exposed to the VM to indicate that the first virtual processor core is an efficiency core; if the second virtual processor core is associated with a performance core, the topology presentation component 203 configures an entry in the ACPI table exposed to the VM to indicate that the second virtual processor core is a performance core.

[0032] Figure 3A flow chart of an example method 300 for associating physical processor cores of a physical processor system with virtual processor cores of a VM is illustrated. In an embodiment, instructions for implementing the method 300 are encoded as computer-executable instructions (e.g., representing the processor manager 118) stored on a computer storage medium (e.g., storage medium 105), which are executable by a processor (e.g., processor system 103) to cause a computer system (e.g., computer system 101) to perform the method 300.

[0033] As mentioned, Figure 1A The processor manager 118 is illustrated as being split between the hypervisor 109 (processor manager 118a) and the virtualization stack 117 (processor manager 118b), meaning that either the virtualization stack 117 or the hypervisor 109 can perform any of the functions of the processor manager 118 described herein. Thus, in some embodiments, the scheduler of the host OS (e.g., the virtualization stack 117) implements the method 300; in other embodiments, the hypervisor (e.g., the hypervisor 109) implements the method 300. Combinations are also possible.

[0034] The following discussion now relates to a method and method actions. Although method actions are discussed in a specific order or illustrated in a flowchart as occurring in a specific order, a specific order is not required unless explicitly stated or required because an action depends on another action being completed before the action is performed.

[0035] like Figure 3 As shown, method 300 includes an act 301 of identifying a heterogeneous set of physical processor cores. In an embodiment, act 301 includes determining that a processor system has a heterogeneous set of physical processor cores. For example, topology identification component 201 determines that processor system 103 includes a heterogeneous set of physical processor cores: physical processor core 107. In an embodiment, the heterogeneous set of physical processor cores includes a first physical processor core having a first capability and a second physical processor core having a second capability different from the first capability. For example, physical core 107a has capability 108a, while physical core 107n has capability 108n.

[0036] Although there may be various differences between physical core 107a and physical core 107n, in one example, capability 108a differs from capability 108n in a manner that affects the performance of physical core 107a and physical core 107n. Thus, in an embodiment, the first capability is a first performance capability, and the second capability is a second performance capability that is different from the first performance capability. In one example, the first performance capability is a first available clock frequency (e.g., a base clock frequency, a maximum clock frequency), and the second performance capability is a second available clock frequency that is different from the first available clock frequency. In another example, the first performance capability is a first cache size, and the second performance capability is a second cache size that is different from the first cache size. In another example, the first performance capability is a first number of ALUs, and the second performance capability is a second number of ALUs that is different from the first number of ALUs. In another example, the first performance capability is a first pipeline architecture, and the second performance capability is a second pipeline architecture that is different from the first pipeline architecture.

[0037] In another example, capability 108a differs from capability 108n in a manner that affects the ISAs of physical core 107a and physical core 107n. Thus, in an embodiment, the first capability is a first ISA capability, and the second capability is a second ISA capability that is different from the first ISA capability. For example, the first ISA capability is a first set of available processor instructions, and the second ISA capability is a second set of available processor instructions that includes at least one processor instruction (e.g., a SIMD instruction) that is not present in the first set of available processor instructions.

[0038] Method 300 also includes an act 302 of associating a physical core with a VM while exposing the heterogeneity of the underlying physical core. In an embodiment, act 302 includes associating multiple physical processor cores with the VM and, in doing so, exposing the heterogeneity of the underlying physical processor cores to the VM. For example, processor association component 202 associates multiple physical cores in physical processor cores 107 with client partition 111a, while topology presentation component 203 exposes the heterogeneity of the physical processor cores to client partition 111a.

[0039] As shown, action 302 includes associating a first physical core with a first virtual core of a VM while exposing heterogeneous features of the first physical core 303. Action 302 also includes associating a second physical core with a second virtual core of the VM while exposing heterogeneous features of the second physical core 304. Figure 3 There is no specified order between act 303 and act 304. Thus, in an embodiment, act 303 and act 304 are performed serially (in either order) or at least partially in parallel.

[0040] In an embodiment, action 303 includes associating a first physical processor core with a first virtual processor core of the VM. For example, the processor association component 202 associates the physical core 107a with the virtual core 115a. In an embodiment, action 303 also includes exposing to the VM that the first virtual processor core has a first feature set based on the first physical processor core having a first capability. In some embodiments, the first feature set indicates that the first physical processor core is an efficiency core. In one example, the topology presentation component 203 exposes the virtual core 115a as having a feature set 120a corresponding to the capability 108a (e.g., by associating a first CPUID with the virtual core 115a, the first CPUID corresponding to the physical processor core model as an efficiency core). In another example, the topology presentation component 203 exposes the feature set corresponding to the capability 108a to the VM via a first ACPI table entry.

[0041] In an embodiment, action 304 includes associating a second physical processor core with a second virtual processor core of the VM. For example, processor association component 202 associates physical core 107n with virtual core 115n. In an embodiment, action 303 also includes exposing to the VM that the second virtual processor core has a second feature set that is different from the first feature set based on the second physical processor core having a second capability. In some embodiments, the first feature set indicates that the first physical processor core is a performance core. In one example, topology presentation component 203 exposes virtual core 115n as having feature set 120n corresponding to capability 108n (e.g., by associating a second CPUID with virtual core 115n, the second CPUID corresponding to a physical processor core model as a performance core). In another example, topology presentation component 203 exposes the feature set corresponding to capability 108n to the VM via a second ACPI table entry that is different from the first ACPI table entry.

[0042] In an embodiment, a VM utilizing a heterogeneous processor topology is migrated from one VM host node to another VM host node (e.g., from computer system 101 to another similarly configured computer system). Conventionally, VM migration involves determining whether the target VM host node has at least one physical processor core that supports a superset of features utilized by the virtual processor cores of the migrated VM. Because conventional VMs have homogeneous virtual processor cores, this is a single determination (e.g., a single virtual processor core type). In an embodiment, migration of a VM utilizing a heterogeneous processor topology includes determining, for each virtual processor core type within a set of heterogeneous virtual processor cores, whether the target VM host node includes at least one physical processor that has a superset of features determined by that core type. Thus, in some embodiments, method 300 includes migrating the VM to a target computer system and determining whether the target computer system includes a target processor system that supports a first capability and a second capability.

[0043] Embodiments of the present disclosure may include or utilize a special-purpose or general-purpose computer system (e.g., computer system 101) that includes computer hardware, such as a processor system (e.g., processor system 103) and system memory (e.g., memory 104), as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media accessible by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 105). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Thus, by way of example, embodiments of the present disclosure may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0044] Computer storage media is a physical storage medium that stores computer-executable instructions and / or data structures. Physical storage media includes computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) that can be used to store program code in the form of computer-executable instructions or data structures that can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[0045] Transmission media can include networks and / or data links, which can be used to carry program codes in the form of computer-executable instructions or data structures and can be accessed by general-purpose or special-purpose computer systems. A "network" is defined as one or more data links capable of transmitting electronic data between a computer system and other electronic devices. When information is transmitted or provided to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer system can view the connection as a transmission medium. Combinations are included within the scope of computer-readable media.

[0046] Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., network interface 106) and then ultimately transferred to computer system RAM and / or less volatile computer storage media at the computer system. Thus, computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0047] For example, computer-executable instructions include instructions and data that, when executed at one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a function or group of functions. Computer-executable instructions can be, for example, binary files, intermediate format instructions (such as assembly language), or even source code.

[0048] It will be appreciated that many types of computer system configurations can be utilized to practice disclosed system and method in a network computing environment, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, based on microprocessors or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. Embodiments of the present disclosure can also be put into practice in a distributed system environment, wherein the local and remote computer systems that are linked (by hardwired data link, wireless data link or by the combination of hardwired and wireless data link) by the network all perform tasks. Therefore, in a distributed system environment, the computer system can include the computer systems of multiple compositions. In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0049] It will also be appreciated that embodiments of the present disclosure can be practiced in a cloud computing environment. The cloud computing environment can be distributed, although this is not required. When the cloud computing environment is distributed, the cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the claims that follow, "cloud computing" is a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). The cloud computing model can consist of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model can also appear in the form of various service models, such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). The cloud computing model can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, hybrid clouds, etc.

[0050] Some embodiments, such as cloud computing environments, may include a system that includes one or more hosts capable of running one or more virtual machines. During operation, the virtual machines emulate an operational computing system, in which an OS and possibly one or more other applications are supported. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machine using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only interfacing with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0051] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the aforementioned features or acts or to the order of acts described. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0052] The present disclosure may be implemented in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects as illustrative only and not restrictive. All changes that fall within the equivalent meaning and range of the claims are to be included within their scope.

[0053] When introducing elements in the appended claims, the articles "a," "an," "the," and "said" are intended to mean that there are one or more elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements in addition to the listed elements. Unless otherwise specified, the terms "set," "superset," and "subset" are intended to exclude the empty set, and thus a "set" is defined as a non-empty set, a "superset" is defined as a non-empty superset, and a "subset" is defined as a non-empty subset. Unless otherwise specified, the term "subset" does not include all of its supersets (i.e., the superset includes at least one item not included in the subset). Unless otherwise specified, a "superset" may include at least one additional element, and a "subset" may exclude at least one element.

Claims

1. A method (300) implemented at a computer system (101) including a processor system (103), comprising: It is determined (201) that the processor system has a heterogeneous set of physical processor cores (107), the heterogeneous set of physical processor cores comprising, a first physical processor core (107a) having a first capability (108a), and a second physical processor core (107n) having a second capability (108n) different from the first capability; as well as Associating (202) a plurality of physical processor cores with a virtual machine (VM) (111a) includes: Associating (202) the first physical processor core with a first virtual processor core (115a) of the VM includes: exposing (203) to the VM that the first virtual processor core has a first feature set (120a) based on the first physical processor core having the first capability; and Associating (202) the second physical processor core with a second virtual processor core (115n) of the VM includes exposing (203) to the VM that the second virtual processor core has a second feature set (120n) different from the first feature set based on the second physical processor core having the second capability.

2. The method according to claim 1, wherein The first capability is a first performance capability; and The second capability is a second performance capability different from the first performance capability.

3. The method according to claim 2, wherein: The first performance capability is at least one of: a first available clock frequency, a first cache size, a first number of arithmetic logic units (ALUs), or a first pipeline architecture; and The second performance capability is at least one of: a second available clock frequency different from the first available clock frequency, a second cache size different from the first cache size, a second number of ALUs different from the first number of ALUs, or a second pipeline architecture different from the first pipeline architecture.

4. The method according to claim 2, wherein: The first feature set is indicative of an efficiency core; and The second feature set is indicative of a performance core.

5. The method according to claim 1, wherein The first capability is a first instruction set architecture (ISA) capability; and The second capability is a second ISA capability different from the first ISA capability.

6. The method according to claim 5, wherein: The first ISA capability is a first set of available processor instructions; as well as The second ISA capability is a second set of available processor instructions including at least one processor instruction not present in the first set of available processor instructions.

7. The method according to claim 1 to claim 6, wherein: Exposing the first virtual processor core to the VM with the first feature set includes associating a first central processing unit identifier (CPUID) with the first virtual processor core; as well as Exposing the second virtual processor core to the VM with the second feature set includes associating a second CPUID with the second virtual processor core, the second CPUID being different from the first CPUID.

8. The method according to claim 1 to claim 6, wherein: Exposing the first virtual processor core having the first feature set to the VM includes presenting a first Advanced Configuration and Power Interface (ACPI) table entry to the VM; as well as Exposing the second virtual processor core to the VM as having the second feature set includes presenting a second ACPI table entry to the VM, the second ACPI table entry being different from the first ACPI table entry.

9. The method according to claim 1 to claim 8, wherein the method is implemented by a scheduler of a host operating system.

10. The method according to claim 1 to claim 8, wherein the method is implemented by a hypervisor.

11. The method according to claim 1 to claim 10, further comprising: Migrating the VM to a target computer system; as well as A determination is made as to whether the target computer system includes a target processor system that supports the first capability and the second capability.

12. A computer system comprising: A processor system, the processor system comprising a set of heterogeneous physical processor cores, the heterogeneous physical processor core set comprising, a first physical processor core having a first capability, and a second physical processor core having a second capability different from the first capability; as well as A computer storage medium storing computer-executable instructions executable by the processor system to at least: Associating the first physical processor core with a first virtual processor core of a virtual machine (VM), including: exposing to the VM that the first virtual processor core has a first feature set based on the first physical processor core having the first capability; and Associating the second physical processor core with a second virtual processor core of the VM includes exposing to the VM that the second virtual processor core has a second feature set different from the first feature set based on the second physical processor core having the second capability.

13. The computer system according to claim 12, wherein: The first capability is a first performance capability; and The second capability is a second performance capability different from the first performance capability.

14. The computer system according to claim 12, wherein: The first capability is a first instruction set architecture (ISA) capability; and The second capability is a second ISA capability different from the first ISA capability.

15. The computer system according to claim 14, wherein: Exposing the first virtual processor core to the VM with the first feature set includes associating a first central processing unit identifier (CPUID) with the first virtual processor core; as well as Exposing the second virtual processor core to the VM with the second feature set includes associating a second CPUID with the second virtual processor core, the second CPUID being different from the first CPUID.

16. The computer system according to claim 12, wherein: Exposing the first virtual processor core having the first feature set to the VM includes presenting a first Advanced Configuration and Power Interface (ACPI) table entry to the VM; as well as Exposing the second virtual processor core to the VM as having the second feature set includes presenting a second ACPI table entry to the VM, the second ACPI table entry being different from the first ACPI table entry.

17. A computer system as claimed in claim 12 to claim 16, wherein the computer executable instructions are part of a scheduler or hypervisor of a host operating system.

18. A computer program product comprising a computer storage medium storing computer executable instructions executable by a processor system to at least: identifying a first physical processor core of the processor system having a first capability; Associating the first physical processor core with a first virtual processor core of a virtual machine (VM) includes: exposing to the VM that the first virtual processor core has a first feature set based on the first physical processor core having the first capability; identifying a second physical processor core of the processor system having a second capability different from the first capability; and Associating the second physical processor core with a second virtual processor core of the VM includes exposing to the VM that the second virtual processor core has a second feature set different from the first feature set based on the second physical processor core having the second capability.

19. The computer program product of claim 18, wherein: The first capability is a first performance capability; and The second capability is a second performance capability different from the first performance capability.

20. The computer program product of claim 18, wherein: The first capability is a first instruction set architecture (ISA) capability; and The second capability is a second ISA capability different from the first ISA capability.

Images