Virtual machine operation method and device of heterogeneous multi-core processor, equipment and medium

Abstract

The invention discloses a virtual machine operation method and device of a heterogeneous multi-core processor, equipment and a medium, and relates to the field of desktop cloud.The method comprises the steps that the maximum frequency of each CPU core is obtained, and the CPU cores with the same maximum frequency are divided into a CPU core group to obtain a plurality of CPU core groups; when the QEMU process is started, all threads of the QEMU process are bound to the CPU core group with the lowest frequency, and after starting is completed, binding of the KVM threads in the CPU core group with the lowest frequency is removed; sorting the KVM threads according to the virtual CPU serial numbers corresponding to the KVM threads, and binding the sorted KVM threads to the corresponding CPU core groups according to a preset binding logic; and binding the disk thread of the main thread to the CPU core group with the highest frequency. According to the method, the KVM thread is bound to the core groups with different frequencies according to the preset binding logic, so that the blue screen of the Windows virtual machine is prevented.

Description

Technical Field

[0001] This application relates to the field of desktop cloud, specifically to a method, apparatus, device, and medium for running virtual machines on a heterogeneous multi-core processor. Background Technology

[0002] Heterogeneous multi-core architecture in CPUs refers to the simultaneous presence of multiple different types of cores within a single CPU chip. This has been a significant trend in processor design in recent years, aiming to intelligently balance high performance and high energy efficiency. Performance cores (P-Cores / Big Cores) have high frequencies, strong single-core performance, support hyper-threading, and higher power consumption, making them suitable for running demanding games, video editing, 3D rendering, and professional computing. Energy-efficient cores (E-Cores / Small Cores) have low frequencies, low power consumption, small size, high multi-core parallel efficiency, and excellent energy efficiency, making them suitable for background application updates, web browsing, document processing, and audio / video playback. The operating system schedules threads and processes to the appropriate cores in real time based on their type; different operating systems use different scheduling algorithms.

[0003] In the desktop cloud field, Linux systems are typically used as the host machine, and the QEMU process is used to run Windows virtual machines. QEMU creates an equal number of KVM threads as the virtual CPUs of the virtual machine. A remote desktop thread, Spice, handles remote desktop protocols, while the main thread handles network, disk, keyboard, mouse, and other input / output requests from the virtual machine. Linux schedules the KVM threads, Spice threads, and main thread on the host machine's physical CPUs according to its own algorithm, while Windows schedules the applications and kernel processes within the virtual machine on the virtual CPUs of the virtual machine according to its own algorithm.

[0004] The above solution works fine on physical CPUs without a heterogeneous multi-core architecture because all physical CPUs and virtual CPUs have the same frequency. Windows can schedule applications and kernel processes to any virtual CPU without affecting system operation. However, on heterogeneous multi-core physical CPUs, the frequencies of the big and small cores often differ significantly. When Windows schedules a task to a high-frequency virtual CPU, and then the corresponding KVM thread is suddenly scheduled by Linux to a low-frequency physical CPU, it will have a significant performance impact on the task in Windows. If this task is a time-sensitive kernel task and it hasn't completed before its allocated time slice expires, it could cause a Windows blue screen. Furthermore, if the physical CPU where the main thread resides has a higher frequency than the physical CPU where the KVM thread resides during virtual machine startup, it will most likely lead to a Windows blue screen. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for running a virtual machine on a heterogeneous multi-core processor, which can solve the blue screen problem of Windows virtual machines under heterogeneous multi-core processors in the prior art.

[0006] In a first aspect, embodiments of this application provide a method for running a virtual machine on a heterogeneous multi-core processor, wherein the heterogeneous multi-core processor includes multiple CPU cores, and the method for running a virtual machine on a heterogeneous multi-core processor includes: Obtain the maximum frequency of each CPU core, and group CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups. When starting the QEMU process, all threads of the QEMU process are bound to the CPU core group with the lowest frequency. After startup, the binding of the KVM threads in the CPU core group with the lowest frequency is released. The KVM threads are sorted according to their virtual CPU numbers, and then bound to the corresponding CPU core groups according to the preset binding logic. Bind the main thread's disk thread to the CPU core group with the highest frequency.

[0007] In conjunction with the first aspect, in one implementation, obtaining the maximum frequency of each CPU core and dividing CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups includes: Obtain the current operating frequency and maximum frequency of each CPU core in the heterogeneous multi-core processor; Set the current operating frequency of each CPU core to the maximum frequency of each CPU core; CPU cores with the same maximum frequency are grouped into a CPU core group to obtain multiple CPU core groups.

[0008] In conjunction with the first aspect, in one implementation, the step of sorting the KVM threads according to their corresponding virtual CPU serial numbers, and binding the sorted KVM threads to their respective CPU core groups according to preset binding logic, includes: Based on the virtual CPU number corresponding to the KVM thread, sort the KVM threads in ascending order, and based on the frequency corresponding to each CPU core group, sort the CPU core groups in descending order. Retrieve each KVM thread sequentially, bind the retrieved KVM thread to the current CPU core group, and determine whether the maximum number of KVM threads bound to the current CPU core group has been reached. If so, the next KVM thread is bound to the next CPU core group, and then it is determined whether the number of KVM threads already bound in the next CPU core group has reached the maximum number, and so on. If not, the next KVM thread will be bound to the current CPU core group; The maximum number of KVM threads that can be bound in the current CPU core group shall not exceed the number of CPU cores in the current CPU core group.

[0009] In conjunction with the first aspect, in one implementation, binding the main thread's disk thread to the most frequently used CPU core group includes: Create a disk thread to handle disk tasks from the main thread; Bind the disk thread to the CPU core group with the highest frequency.

[0010] In conjunction with the first aspect, in one implementation, the binding operation is carried out through the taskset command of the Linux system.

[0011] In conjunction with the first aspect, in one implementation, the heterogeneous multi-core processor is an ARM architecture processor, and the virtual machine is a Windows operating system virtual machine.

[0012] Secondly, embodiments of this application provide a virtual machine running device for the heterogeneous multi-core processor, comprising: The acquisition module is used to obtain the maximum frequency of each CPU core, and to divide CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups. The first binding module is used to bind all threads of the QEMU process to the lowest frequency CPU core group when the QEMU process starts, and to unbind the KVM threads in the lowest frequency CPU core group after startup. The second binding module is used to sort the KVM threads according to the virtual CPU number corresponding to the KVM threads, and bind the sorted KVM threads to the corresponding CPU core group according to the preset binding logic. The third binding module is used to bind the main thread's disk thread to the most frequently used CPU core group.

[0013] In conjunction with the second aspect, in one implementation, the second binding module includes: The sorting module is used to sort KVM threads in ascending order based on the virtual CPU number corresponding to each KVM thread, and to sort CPU core groups in descending order based on the frequency corresponding to each CPU core group. The judgment module is used to sequentially obtain each KVM thread, bind the obtained current KVM thread to the current CPU core group, and determine whether the maximum number of KVM threads bound in the current CPU core group has been reached. If so, the next KVM thread is bound to the next CPU core group, and then it is determined whether the number of KVM threads already bound in the next CPU core group has reached the maximum number, and so on. If not, the next KVM thread will be bound to the current CPU core group; The maximum number of KVM threads that can be bound in the current CPU core group shall not exceed the number of CPU cores in the current CPU core group.

[0014] Thirdly, embodiments of this application provide a virtual machine running device for a heterogeneous multi-core processor. The virtual machine running device for a heterogeneous multi-core processor includes a processor, a memory, and a virtual machine running program for the heterogeneous multi-core processor stored in the memory and executable by the processor. When the virtual machine running program for the heterogeneous multi-core processor is executed by the processor, it implements the steps of the virtual machine running method for the heterogeneous multi-core processor described in any of the above embodiments.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a virtual machine runtime program for a heterogeneous multi-core processor, wherein when the virtual machine runtime program for the heterogeneous multi-core processor is executed by a processor, it implements the steps of the virtual machine runtime method for a heterogeneous multi-core processor described in any of the above embodiments.

[0016] The beneficial effects of the technical solutions provided in this application include: This embodiment of the application ensures that the main thread will not run on a core with a higher frequency than the KVM thread during virtual machine startup by initially binding all threads of the QEMU process to the lowest frequency core group, thus avoiding startup failure due to scheduling timing differences. According to preset binding logic, KVM threads are bound to core groups of different frequencies based on their corresponding virtual CPU numbers, preventing sudden performance degradation of Windows tasks caused by the Linux system scheduling corresponding KVM threads to physical cores of different frequencies, thereby preventing Windows blue screens caused by time-sensitive kernel task timeouts. This embodiment of the application also compensates for the input or output latency that might result from the main thread being bound to a low-frequency core group by separating the threads handling disk I / O and binding them to the highest frequency core group, thus maintaining the storage access performance of the virtual machine. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the virtual machine operation method for heterogeneous multi-core processors according to this application; Figure 2 This is a schematic diagram of the functional modules of the virtual machine running device for the heterogeneous multi-core processor of this application; Figure 3This is a schematic diagram of the hardware structure of the virtual machine running device with a heterogeneous multi-core processor involved in the embodiments of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] This application provides a method, apparatus, device, and medium for running a virtual machine on a heterogeneous multi-core processor, which can solve the blue screen problem of Windows virtual machines under heterogeneous multi-core processors in the prior art.

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] In a first aspect, embodiments of this application provide a method for running a virtual machine on a heterogeneous multi-core processor.

[0022] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the virtual machine execution method for heterogeneous multi-core processors according to this application. Figure 1 As shown, the virtual machine running method for heterogeneous multi-core processors specifically includes the following steps: Step S1: Obtain the maximum frequency of each CPU core, and divide the CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups.

[0023] In this embodiment of the application, step S1 specifically includes the following steps: Step S11: Obtain the current operating frequency and maximum frequency of each CPU core in the heterogeneous multi-core processor.

[0024] Step S12: Set the current operating frequency of each CPU core to the maximum frequency of each CPU core.

[0025] Specifically, the operating system's performance management interface is invoked to issue instructions to each CPU core, locking the current operating frequency of each CPU to its maximum operating frequency supported by its hardware. This eliminates instantaneous frequency fluctuations caused by dynamic frequency adjustment, allowing all CPU cores to continuously run at their supported peak performance levels, thus eliminating performance fluctuations caused by automatic frequency scaling.

[0026] Step S13: Divide CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups.

[0027] Specifically, CPU cores are categorized based on their uniformly set maximum frequency. All CPU cores with the same maximum frequency are grouped into a single CPU core group, resulting in multiple CPU core groups with different frequencies. The CPU cores within each group have the same maximum performance limit, while there are performance differences between groups.

[0028] Step S2: When starting the QEMU process, bind all threads of the QEMU process to the CPU core group with the lowest frequency. After startup, unbind the KVM threads in the CPU core group with the lowest frequency.

[0029] Specifically, during virtual machine initialization, the creation times of the main thread and KVM threads differ. Therefore, when starting the QEMU process, the `taskset` command is used to set the process-level CPU affinity mask to the bitmask of the lowest-frequency CPU core group. This ensures that all threads of the QEMU process automatically inherit this affinity, guaranteeing that all threads are restricted to running on the lowest-frequency CPU core group before the virtual machine startup sequence is complete. After the virtual machine completes initialization and all KVM threads are created, a new CPU affinity mask is set for each KVM thread individually, while the main thread affinity mask remains unchanged, still residing in the lowest-frequency CPU core group. This embodiment of the application ensures that by initially binding all threads of the QEMU process to the lowest-frequency core group, the main thread will not run on cores with frequencies higher than those of the KVM threads during virtual machine startup, thus avoiding startup failures due to scheduling timing differences.

[0030] Step S3: Sort the KVM threads according to the virtual CPU number corresponding to the KVM threads, and bind the sorted KVM threads to the corresponding CPU core groups according to the preset binding logic.

[0031] In this embodiment of the application, step S3 specifically includes the following steps: Step S31: Sort the KVM threads in ascending order according to the virtual CPU number corresponding to each KVM thread, and sort the CPU core groups in descending order according to the frequency corresponding to each CPU core group.

[0032] Specifically, the virtual CPU number (vcpu_id) associated with each KVM thread is extracted. The virtual CPU number is a non-negative integer, assigned sequentially by the QEMU process when creating virtual CPUs. KVM threads are arranged in ascending order of virtual CPU number to generate a thread processing queue. The frequency of each CPU core group is extracted, and the core groups are arranged in descending order of frequency to generate a target CPU core group queue.

[0033] Step S32: Sequentially obtain each KVM thread, bind the obtained current KVM thread to the current CPU core group, and determine whether the number of KVM threads bound in the current CPU core group has reached the maximum. If yes, proceed to step S33; otherwise, proceed to step S34.

[0034] In the scenario of this application embodiment, the total number of virtual CPUs is set to not exceed the total number of CPU cores. In this application embodiment, the maximum number of KVM threads that can be bound in the current CPU core group does not exceed the number of CPU cores in the current CPU core group. In this application embodiment, the heterogeneous multi-core processor is an ARM (Advanced RISC Machine) architecture processor, and the virtual machine is a Windows operating system virtual machine.

[0035] In this embodiment, the virtual CPU sequence number represents a higher task priority. Therefore, binding the KVM thread hosting the high-priority virtual CPU to the CPU core group with the highest frequency ensures that critical tasks receive sufficient computing resources, mitigating the risk of system instability caused by a sudden drop in the performance of the virtual CPU hosting the critical task. Before and after each binding, it is necessary to check whether the number of KVM threads already bound in the current target core group has reached its limit, thereby preventing multiple KVM threads from competing for time slices on the same CPU core, which could cause the preset binding logic to fail.

[0036] Step S33: Bind the acquired next KVM thread to the next CPU core group, and then determine whether the number of KVM threads already bound in the next CPU core group has reached the maximum, and repeat this process.

[0037] Specifically, if the number of KVM threads already bound in the current target core group has reached its maximum, the current target core group is switched to the next highest frequency CPU core group in the target CPU core group queue, and the next acquired KVM thread is bound to this new CPU core group. This process is repeated until all KVM threads are bound.

[0038] Step S34: Bind the acquired next KVM thread to the current CPU core group.

[0039] Specifically, if the number of KVM threads already bound in the current target core group has not reached the maximum number, the next KVM thread will be bound to the current CPU core group.

[0040] In one specific embodiment, a 4 vCPU Windows virtual machine on an ARM architecture server is configured. This virtual machine has 4 virtual CPUs, corresponding to 4 KVM threads, with the virtual CPU numbers being vCPU0, vCPU1, vCPU2, and vCPU3. The host machine is divided into three core groups in step S1: group C (containing 2 cores at 3.0 GHz), group B (containing 2 cores at 2.5 GHz), and group A (containing 4 cores at 2.0 GHz). In step S31, the KVM threads are sorted as [K0, K1, K2, K3]. The core groups are sorted as [group C, group B, group A].

[0041] For K0, the current CPU core group is group C. Group C currently has 0 bound cores. Group C can be bound to a maximum of 2 cores, but this limit has not been reached. Therefore, K0 is bound to group C. For K1, the current CPU core group is still group C. Group C has 1 bound core. Group C can be bound to a maximum of 2 cores, but this limit has not been reached. Therefore, K1 is bound to group C. For K2, the current CPU core group is still group C. Group C has 2 bound cores. Group C can be bound to a maximum of 2 cores, but this limit has been reached. According to S33, the current CPU core group is switched to group B. K2 is bound to group B. For K3, the current CPU core group is group B. Group B has 1 bound core. Group C can be bound to a maximum of 2 cores, but this limit has not been reached. Therefore, K3 is bound to group B.

[0042] Step S4: Bind the main thread's disk thread to the CPU core group with the highest frequency.

[0043] In this embodiment of the application, step S4 specifically includes the following steps: Step S41: Create a disk thread to handle disk tasks from the main thread.

[0044] Specifically, within the QEMU process, a new thread, independent of the main thread, is created—the disk thread. This disk thread is dedicated to handling all storage access requests from the virtual machine. After creating the disk thread, disk I / O tasks that were originally received and forwarded by the main thread are redirected to the disk thread for processing.

[0045] Step S42: Bind the disk thread to the CPU core group with the highest frequency.

[0046] Specifically, after the disk thread creates and takes over the disk I / O task, the CPU affinity of the disk thread is forcibly set to allow execution only on the CPU core group with the highest running frequency allocated in step S1. This ensures that the performance of the disk I / O task is no longer limited by the low-performance core where the main thread resides, guaranteeing that intensive operations such as disk interrupt handling, data copying, and protocol stack processing can obtain the strongest single-core computing power under the current hardware environment.

[0047] This embodiment of the application ensures that the main thread will not run on a core with a higher frequency than the KVM thread during virtual machine startup by initially binding all threads of the QEMU process to the lowest frequency core group, thus avoiding startup failure due to scheduling timing differences. According to preset binding logic, KVM threads are bound to core groups of different frequencies based on their corresponding virtual CPU numbers, preventing sudden performance degradation of Windows tasks caused by the Linux system scheduling corresponding KVM threads to physical cores of different frequencies, thereby preventing Windows blue screens caused by time-sensitive kernel task timeouts. This embodiment of the application also compensates for the input or output latency that might result from the main thread being bound to a low-frequency core group by separating the threads handling disk I / O and binding them to the highest frequency core group, thus maintaining the storage access performance of the virtual machine.

[0048] Secondly, embodiments of this application also provide a virtual machine running device for a heterogeneous multi-core processor.

[0049] In one embodiment, reference is made to Figure 2 , Figure 2 This is a schematic diagram of the functional modules of the virtual machine running device for the heterogeneous multi-core processor of this application. Figure 2 As shown, the virtual machine runtime device for heterogeneous multi-core processors includes: The acquisition module is used to obtain the maximum frequency of each CPU core, and to divide CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups. The first binding module is used to bind all threads of the QEMU process to the lowest frequency CPU core group when the QEMU process starts, and to unbind the KVM threads in the lowest frequency CPU core group after startup. The second binding module is used to sort the KVM threads according to the virtual CPU number corresponding to the KVM threads, and bind the sorted KVM threads to the corresponding CPU core group according to the preset binding logic. The third binding module is used to bind the main thread's disk thread to the most frequently used CPU core group.

[0050] In this embodiment of the application, the second binding module includes: The sorting module is used to sort KVM threads in ascending order based on the virtual CPU number corresponding to each KVM thread, and to sort CPU core groups in descending order based on the frequency corresponding to each CPU core group. The judgment module is used to sequentially obtain each KVM thread, bind the obtained current KVM thread to the current CPU core group, and determine whether the maximum number of KVM threads bound in the current CPU core group has been reached. If so, the next KVM thread is bound to the next CPU core group, and then it is determined whether the number of KVM threads already bound in the next CPU core group has reached the maximum number, and so on. If not, the next KVM thread will be bound to the current CPU core group; The maximum number of KVM threads that can be bound in the current CPU core group shall not exceed the number of CPU cores in the current CPU core group.

[0051] The functions of each module in the above-mentioned heterogeneous multi-core processor virtual machine running device correspond to the steps in the above-mentioned heterogeneous multi-core processor virtual machine running method embodiment, and their functions and implementation processes will not be described in detail here.

[0052] Thirdly, embodiments of this application provide a virtual machine running device for a heterogeneous multi-core processor. The virtual machine running device for a heterogeneous multi-core processor includes a processor, a memory, and a virtual machine running program for the heterogeneous multi-core processor stored in the memory and executable by the processor. When the virtual machine running program for the heterogeneous multi-core processor is executed by the processor, it implements the steps of the virtual machine running method for the heterogeneous multi-core processor of any of the above embodiments.

[0053] The virtual machine running device for a heterogeneous multi-core processor can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities. Fourthly, embodiments of this application provide a computer-readable storage medium storing a virtual machine running program for a heterogeneous multi-core processor. When the virtual machine running program for the heterogeneous multi-core processor is executed by a processor, it implements the steps of the virtual machine running method for a heterogeneous multi-core processor described in any of the above embodiments.

[0054] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of a virtual machine running device with a heterogeneous multi-core processor involved in the embodiments of this application. In the embodiments of this application, the virtual machine running device with a heterogeneous multi-core processor may include a processor, memory, communication interface, and communication bus.

[0055] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0056] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within a heterogeneous multi-core processor-based virtual machine runtime device, as well as interfaces used for interconnecting the heterogeneous multi-core processor-based virtual machine runtime device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user devices can be displays, keyboards, etc.

[0057] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0058] The processor can be a general-purpose processor, which can call a virtual machine runtime program for a heterogeneous multi-core processor stored in memory and execute the virtual machine runtime method for a heterogeneous multi-core processor provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the virtual machine runtime program for a heterogeneous multi-core processor is called can be referred to in the various embodiments of the virtual machine runtime method for a heterogeneous multi-core processor in this application, and will not be repeated here.

[0059] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0060] Fourthly, embodiments of this application provide a computer-readable storage medium storing a virtual machine runtime program for a heterogeneous multi-core processor, wherein when the virtual machine runtime program for the heterogeneous multi-core processor is executed by a processor, it implements the steps of the virtual machine runtime method for a heterogeneous multi-core processor described in any of the above embodiments.

[0061] The present application provides a computer-readable storage medium storing a virtual machine program for a heterogeneous multi-core processor, wherein when the virtual machine program for the heterogeneous multi-core processor is executed by a processor, it implements the steps of the virtual machine running method for a heterogeneous multi-core processor as described above.

[0062] The method implemented when the virtual machine program of the heterogeneous multi-core processor is executed can be referred to in the various embodiments of the virtual machine running method of the heterogeneous multi-core processor of this application, and will not be repeated here.

[0063] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0064] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0065] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0066] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0067] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0068] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0069] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for running a virtual machine on a heterogeneous multi-core processor, wherein the heterogeneous multi-core processor includes multiple CPU cores, characterized in that, The virtual machine running method for the heterogeneous multi-core processor includes: Obtain the maximum frequency of each CPU core, and group CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups. When starting the QEMU process, all threads of the QEMU process are bound to the CPU core group with the lowest frequency. After startup, the binding of the KVM threads in the CPU core group with the lowest frequency is released. The KVM threads are sorted according to their virtual CPU numbers, and then bound to the corresponding CPU core groups according to the preset binding logic. Bind the main thread's disk thread to the CPU core group with the highest frequency.

2. The virtual machine running method for heterogeneous multi-core processors according to claim 1, characterized in that, The process of obtaining the maximum frequency of each CPU core and grouping CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups includes: Obtain the current operating frequency and maximum frequency of each CPU core in the heterogeneous multi-core processor; Set the current operating frequency of each CPU core to the maximum frequency of each CPU core; CPU cores with the same maximum frequency are grouped into a CPU core group to obtain multiple CPU core groups.

3. The virtual machine running method for heterogeneous multi-core processors according to claim 1, characterized in that, The step of sorting KVM threads according to their corresponding virtual CPU numbers and binding the sorted KVM threads to their respective CPU core groups according to preset binding logic includes: Based on the virtual CPU number corresponding to the KVM thread, sort the KVM threads in ascending order, and based on the frequency corresponding to each CPU core group, sort the CPU core groups in descending order. Retrieve each KVM thread sequentially, bind the retrieved KVM thread to the current CPU core group, and determine whether the maximum number of KVM threads bound to the current CPU core group has been reached. If so, the next KVM thread is bound to the next CPU core group, and then it is determined whether the number of KVM threads already bound in the next CPU core group has reached the maximum number, and so on. If not, the next KVM thread will be bound to the current CPU core group; The maximum number of KVM threads that can be bound in the current CPU core group shall not exceed the number of CPU cores in the current CPU core group.

4. The virtual machine running method for heterogeneous multi-core processors according to claim 1, characterized in that, The method of binding the main thread's disk thread to the CPU core group with the highest frequency includes: Create a disk thread to handle disk tasks from the main thread; Bind the disk thread to the CPU core group with the highest frequency.

5. The virtual machine running method for heterogeneous multi-core processors according to claim 1, characterized in that, Binding operations are performed using the `taskset` command in the Linux system.

6. The virtual machine running method for heterogeneous multi-core processors according to claim 1, characterized in that, The heterogeneous multi-core processor is an ARM architecture processor, and the virtual machine is a Windows operating system virtual machine.

7. A virtual machine runtime device for a heterogeneous multi-core processor, characterized in that, The virtual machine runtime device for the heterogeneous multi-core processor includes: The acquisition module is used to obtain the maximum frequency of each CPU core, and to divide CPU cores with the same maximum frequency into a CPU core group to obtain multiple CPU core groups. The first binding module is used to bind all threads of the QEMU process to the lowest frequency CPU core group when the QEMU process starts, and to unbind the KVM threads in the lowest frequency CPU core group after startup. The second binding module is used to sort the KVM threads according to the virtual CPU number corresponding to the KVM threads, and bind the sorted KVM threads to the corresponding CPU core group according to the preset binding logic. The third binding module is used to bind the main thread's disk thread to the most frequently used CPU core group.

8. The virtual machine running device for a heterogeneous multi-core processor according to claim 7, characterized in that, The second binding module includes: The sorting module is used to sort KVM threads in ascending order based on the virtual CPU number corresponding to each KVM thread, and to sort CPU core groups in descending order based on the frequency corresponding to each CPU core group. The judgment module is used to sequentially obtain each KVM thread, bind the obtained current KVM thread to the current CPU core group, and determine whether the maximum number of KVM threads bound in the current CPU core group has been reached. If so, the next KVM thread is bound to the next CPU core group, and then it is determined whether the number of KVM threads already bound in the next CPU core group has reached the maximum number, and so on. If not, the next KVM thread will be bound to the current CPU core group; The maximum number of KVM threads that can be bound in the current CPU core group shall not exceed the number of CPU cores in the current CPU core group.

9. A virtual machine running device with a heterogeneous multi-core processor, characterized in that, The heterogeneous multi-core processor virtual machine running device includes a processor, a memory, and a heterogeneous multi-core processor virtual machine running program stored in the memory and executable by the processor, wherein when the heterogeneous multi-core processor virtual machine running program is executed by the processor, it implements the steps of the heterogeneous multi-core processor virtual machine running method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a virtual machine program for a heterogeneous multi-core processor, wherein when the virtual machine program for the heterogeneous multi-core processor is executed by the processor, it implements the steps of the virtual machine running method for a heterogeneous multi-core processor as described in any one of claims 1 to 6.

Images