Mutual simulation method between heterogeneous processors

Abstract

The present invention discloses a method for mutual simulation between heterogeneous processors, including initializing the register VPIDR_EL2 of the reference physical processor in the kernel space, writing the value of the register MIDR_EL1 contained in the physical processor to be simulated, so as to modify the kernel of the physical machine to which the reference physical processor belongs; in the operating system to which the reference physical processor belongs, compiling the kernel of the physical machine to which the modified reference physical processor belongs, updating it to the operating system where the reference physical processor is located, and running the compiled kernel to modify the value of the register VPIDR_EL2 of the reference physical processor; the virtualization management program determines the manufacturer and / or model of the physical processor to be simulated according to the value of the register VPIDR_EL2 of the modified reference physical processor. The present invention realizes the shielding of differentiated hardware information in heterogeneous scenarios, improves user experience and avoids performance loss.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a mutual simulation method between heterogeneous processors. Background Art

[0002] A virtual machine (VM) simulates one or more independent execution environments on a hardware platform that are identical to the actual underlying hardware. Virtualization technology is the practice of abstracting and converting various physical resources of a computer to create a specific virtual object, including virtual computer hardware platforms, storage devices, and computer network resources. Virtualization technology achieves software / hardware separation by introducing a virtualization layer between software and hardware to perform logical abstract conversion on various resources of the host machine. Users can run applications in a virtualized operating system environment without paying attention to the specific implementation of the hardware, which improves resource utilization and security. Hypervisor is an intermediate layer software running between a physical server and an operating system. One of the core elements of Hypervisor is the page mapper, which points physical hardware to the page of a specific operating system (Guest or Hypervisor) through page table mapping to meet various process running and data reading and writing events.

[0003] The full virtualization of physical hardware (especially physical CPU) relies on Trap-and-emulation, i.e., trap mode and simulation. The full virtualization of physical CPU returns the privileged instructions required by GUEST OS to GUEST OS by automatically capturing them through VMM (virtual machine manager, such as Hypervisor). When GUEST OS generates privileged instructions, VMM automatically captures them, intercepts the privileged instructions requested by GUEST OS, and then returns the results to GUEST OS after running them through VMM. VMM will use simulation to execute the privileged instructions once. In the server cluster for building public cloud, private cloud or hybrid cloud, multiple physical machines are usually deployed, and each physical machine includes at least one physical CPU. When virtual machine migration is caused by insufficient physical machine resources or caused by replacement of physical machines, if the physical CPUs deployed by two physical machines belong to the same architecture but different manufacturers (hereinafter referred to as "heterogeneous scenario"), it will be perceived by users when performing migration. For example, Feiteng 2000 manufactured by Feiteng and Kunpeng 920 manufactured by Huawei are both based on the heterogeneous scenario of physical CPUs based on the ARMv8 architecture. Feiteng 2000 is deployed on physical machine 1, and Kunpeng 920 is deployed on physical machine 2. Users can view the architecture, manufacturer, version and other physical hardware information of the physical CPUs configured on different physical machines in the server cluster by typing the command line / proc / cpuinfo.

[0004] However, for cloud platforms, if users expose the underlying physical hardware information, virtual hardware isolation and user experience consistency will be lost. Generally speaking, whether it is starting and deploying a virtual machine on a physical machine or during the migration of a virtual machine, if the user perceives that there is a difference in the underlying hardware, the user experience will be degraded. Summary of the invention

[0005] The purpose of the present invention is to disclose a mutual simulation method between heterogeneous processors, so as to realize mutual simulation between physical CPUs of the same architecture but different manufacturers and / or versions in a heterogeneous scenario, and to avoid users from perceiving the differences between the underlying physical hardware, thereby improving the user experience.

[0006] To achieve the above object, the present invention provides a method for mutual simulation between heterogeneous processors, comprising the following steps:

[0007] S1, initialize the register VPIDR_EL2 of the reference physical processor in the kernel space, write the value of the register MIDR_EL1 included in the physical processor to be simulated, so as to modify the kernel of the physical machine to which the reference physical processor belongs;

[0008] S2. In the operating system to which the reference physical processor belongs, compile the kernel of the physical machine to which the modified reference physical processor belongs, update it to the operating system where the reference physical processor is located, and run the compiled kernel to modify the value of the register VPIDR_EL2 of the reference physical processor;

[0009] S3. The virtualization management program determines the manufacturer and / or model of the physical processor to be simulated according to the value of the register VPIDR_EL2 of the modified benchmark physical processor.

[0010] As a further improvement of the present invention, the value of the register VPIDR_EL2 of the reference physical processor is modified to be the value of the register MIDR_EL1 included in the physical processor to be simulated.

[0011] As a further improvement of the present invention, the step between step S2 and step S3 further includes: pre-configuring the virtualization management software of the physical machine where the reference physical processor is located with the description information of the manufacturer and / or model of the physical processor to be simulated.

[0012] As a further improvement of the present invention, after step S3 is executed, it also includes: starting a virtual machine on the physical machine where the physical processor to be simulated is located through a virtualization management program, and selecting the manufacturer and / or model of the added physical processor to be simulated for the virtual machine.

[0013] As a further improvement of the present invention, in step S2, the user manually types a command line in the UI interface to perform kernel compilation on the physical machine.

[0014] As a further improvement of the present invention, it is used to simulate heterogeneous processors deployed on at least two physical machines in a server cluster, wherein the heterogeneous processors are physical processors with the same logical architecture but from different manufacturers and / or different versions.

[0015] As a further improvement of the present invention, the physical machine includes: a physical computer, a tablet computer or a wearable electronic device based on an ARM architecture.

[0016] As a further improvement of the present invention, the physical processor is a physical processor based on ARM architecture.

[0017] As a further improvement of the present invention, step S3 is executed when the virtualization management program creates a virtual machine in the physical machine, and the virtualization management program directly modifies the value of the register VPIDR_EL2 included in the multiple logical processors included in the virtual processor.

[0018] Compared with the prior art, the present invention has the following beneficial effects:

[0019] Through the present invention, shielding of differentiated hardware information between multiple heterogeneous physical CPUs or physical machines containing heterogeneous physical CPUs is achieved, mutual simulation between heterogeneous processors in heterogeneous scenarios of physical CPUs with the same architecture but different manufacturers and / or versions is achieved, and the technical effect of avoiding users from perceiving differences between underlying physical hardware is achieved and improving user experience, and performance loss caused by some registers in the kernel space being trapped (Trap) in the virtual machine manager of the physical machine during mutual simulation between heterogeneous processors is avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is an overall flow chart of the mutual simulation method between heterogeneous processors of the present invention;

[0021] Figure 2 Based on Figure 1 The overall topology diagram of a mutual simulation method between heterogeneous processors performing mutual migration between two physical machines is shown;

[0022] Figure 3 This is the field description of register VPIDR_EL2 included in the physical processor. DETAILED DESCRIPTION

[0023] The present invention is described in detail below in conjunction with the various embodiments shown in the accompanying drawings, but it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformations or substitutions in functions, methods, or structures made by ordinary technicians in the field based on these embodiments are all within the scope of protection of the present invention.

[0024] The method aims to realize mutual simulation operation between physical CPUs based on ARM architecture (such as ARMv8 architecture), realize simulation of one physical CPU to another physical CPU, and shield the user from the user space (User Space), so as to realize mutual simulation between heterogeneous processors in heterogeneous scenarios, and realize the technical effect of avoiding the difference between the underlying physical hardware perceived by the user. In particular, the method avoids the abnormality caused by the client itself or the inconsistency between the client page table and the shadow page table in the process of performing pure software full virtualization on the physical CPU. Once a page fault abnormal event occurs, a VM-Exit event will be generated and fall into VMM (Virtual Machine Monitor). At the same time, since the shadow page table realizes the mapping relationship of GVA (client virtual address, Guest Virtual Address) to HPA (host physical address, Host Physical Address) based on software, the synchronization of the client page table and the shadow page table is also relatively complicated, so there is a defect of excessive calculation overhead and large performance loss.

[0025] Ginseng Figures 1 to 3 A specific implementation of a method for mutual simulation between heterogeneous processors (hereinafter referred to as "method") of the present invention is shown.

[0026] The method for mutual simulation between heterogeneous processors includes the following steps S1 to S4. The method is used to mutually simulate heterogeneous processors deployed by at least two physical machines (i.e., physical machine 1 and physical machine 2) in a server cluster, wherein the heterogeneous processors are physical processors with the same logical architecture but different manufacturers (Implementer) and / or different versions (Revision). The physical processor is a physical processor based on the ARM architecture. The physical machine includes: a physical computer, a tablet computer or a wearable electronic device based on the ARM architecture. Preferably, the physical processor is a physical processor based on the ARM architecture. For example, one or more Kunpeng 920 physical CPUs, both of which are ARMv8 architectures, are deployed in physical machine 1, and one or more Feiteng 2000 physical CPUs, both of which are ARMv8 architectures, are deployed in physical machine 2. Reference Figure 3 As shown, for a 64-bit ARMv8 architecture physical CPU, register VPIDR_EL2 is a general system control register in the ARMv8 architecture, bits 0 to 3 represent the revision, and bits 24 to 31 represent the implementer. Therefore, as long as two physical CPUs have different versions and / or different manufacturers, they constitute heterogeneous processors for users.

[0027] The Implementer, bits[31:24] field contains the implementer code assigned by ARM to carry the manufacturer's information; the codes assigned by ARM and their typical meanings are shown below.

[0028] 0x00 represents Reserved for software use.

[0029] 0x41 stands for Arm Limited.

[0030] 0x42 represents Broadcom Corporation.

[0031] 0x43 represents Cavium Inc.

[0032] 0x44 represents Digital Equipment Corporation.

[0033] 0x46 represents Fujitsu Ltd.

[0034] 0x49 represents Infineon Technologies AG.

[0035] 0x4D represents Motorola or Freescale SemiconductorInc.

[0036] 0x4E represents NVIDIA Corporation.

[0037] 0x50 represents Applied Micro Circuits Corporation.

[0038] 0x51 stands for Qualcomm Inc.

[0039] 0x56 stands for Marvell International Ltd.

[0040] 0x69 represents Intel Corporation.

[0041] 0xC0 stands for Ampere Computing

[0042] Other manufacturers, such as Huawei and Xiaomi, determine the unique Implementer code based on the ARMv8 architecture based on the authorization from ARM.

[0043] To simplify the description, the method disclosed in this embodiment involves a simulation scenario based on a Kunpeng 920 physical CPU (hereinafter referred to as "Kunpeng 920" or "benchmark physical processor") to simulate a Feiteng 2000 physical CPU (hereinafter referred to as "Feiteng 2000" or "physical processor to be simulated"), so that the user considers the physical processors deployed in physical machine 1 and physical machine 2 to be Kunpeng 920, so as to shield one or more Feiteng 2000s deployed in physical machine 2 objectively, and not shield one or more Kunpeng 920s deployed in physical machine 2. Of course, Kunpeng 920 and Feiteng 2000 can simulate each other, as long as they are based on the same architecture.

[0044] Step S1, initialize the register VPIDR_EL2 of the benchmark physical processor (such as Kunpeng 920) in the kernel space (i.e., Kernel Space), and write the value of the register MIDR_EL1 contained in the physical processor to be simulated (such as Feiteng 2000) to modify the kernel of the physical machine to which the benchmark physical processor belongs. Register VPIDR_EL2 (VirtualizationProcessor ID Register) is a register related to the virtualized physical CPU in the process of implementing virtualization in the physical processor of the ARM architecture, and belongs to a general system control register in the ARMv8 architecture. AArch64 system register VPIDR_EL2 bit [31:0] is mapped to AArch32 system register VPIDR [31:0] in the architecture. If EL2 is not implemented, the read of register VPIDR_EL2 will return the value of MIDR_EL1 and the write to the register will be ignored. If EL2 is not enabled in the current security state, register VPIDR_EL2 is invalid. Specifically, the initialization of the register VPIDR_EL2 of the reference physical processor in step S1 and the subsequent writing operation are all performed by the physical machine kernel software.

[0045] For example, after starting Kunpeng 920 in the kernel software of physical machine 1, write 0x00000000701f6622 (that is, the value of register MIDR_EL1 contained in the physical processor to be simulated, or simply "write value") to register VPIDR_EL2 of Kunpeng 920 and use it to simulate Feiteng 2000. The aforementioned write value is the manufacturer or version of the physical processor based on ARM architecture, such as Kunpeng, Ampere, Marvell, or contains both manufacturer and version information, and can even be the custom values ​​of other registers such as register VPIDR_EL2 contained in the public version of ARM processors by different manufacturers. The core code for writing the write value to register VPIDR_EL2 of Kunpeng 920 in the kernel software of the aforementioned physical machine 1 is as follows:

[0046]

[0047] Step S2: In the operating system to which the reference physical processor belongs, the physical machine (i.e. Figure 2 The kernel of the physical machine 1 in the simulation is compiled, updated to the operating system where the benchmark physical processor is located, and the compiled kernel is run to modify the value of the register VPIDR_EL2 of the benchmark physical processor. After recompiling physical machine 1, restarting physical machine 1 can enter the kernel space (KernelSpace) of the recompiled physical machine 1. Specifically, in step S2, the user performs kernel compilation on the physical machine by manually typing a command line in the UI interface. The value of the register VPIDR_EL2 of the benchmark physical processor is modified to the value of the register MIDR_EL1 contained in the physical processor to be simulated. The method for mutual simulation of heterogeneous processing devices disclosed in this embodiment effectively avoids the performance loss caused by the register VPIDR_EL2 being trapped (Trap) in the virtual machine manager (e.g., Hypervisor) of the physical machine 1 in the kernel space. At the same time, since the kernel of the physical machine to which the benchmark physical processor belongs is directly compiled, and then the physical machine kernel software is used to batch change the value of the register VPIDR_EL2 contained in all the logical processors (Logic CPU) contained in the vCPU, the existing technology for realizing mutual simulation in heterogeneous scenarios avoids the performance loss of the virtual machine and the performance loss of the physical machine 2 caused by the recompilation and update of the kernel of the virtual machine (such as Feiteng 2000) to be simulated after the virtual machine is created and started.

[0048] Preferably, in this embodiment, between step S2 and step S3, it also includes: pre-configuring the description information of the manufacturer and / or model of the physical processor to be simulated for the virtualization management software (QEMU) of the physical machine (e.g., physical machine 1) where the reference physical processor is located. The so-called pre-configuration means: before all physical machines create and start virtual machines through Hypervisor, the user (or administrator) modifies the QEMU in the user space of physical machine 1 through a graphical interface or command line (Console) to write the description information of the manufacturer and / or model of the physical processor to be simulated to the aforementioned QEMU. The aforementioned description information is the type (Model) of the physical processor to be simulated contained in all or part of the physical machines contained in the server cluster (Server Cluster). Through the aforementioned technical solution, after adding or replacing one or more physical machines in the server cluster, the description information pre-configured by QEMU in the user space of physical machine 1 is directly called, so that the virtual machine matching the description information is created and started in the physical machine 1 through the following steps S3 and step S4 according to the aforementioned description information.

[0049] Step S3, the virtualization management program (e.g., QEMU) determines the manufacturer and / or model of the physical processor to be simulated according to the modified value of the register VPIDR_EL2 of the reference physical processor (i.e., the value of the register VPIDR_EL2 of the reference physical processor has been modified). Specifically, in this embodiment, step S3 is executed when the virtualization management program creates a virtual machine in the physical machine, and the virtualization management program directly modifies the value of the register VPIDR_EL2 included in the multiple logical processors included in the virtual processor.

[0050] Step S4: Start a virtual machine on the physical machine where the physical processor to be simulated is located through a virtualization management program (such as a Hypervisor), and select the manufacturer and / or model of the added physical processor to be simulated for the virtual machine.

[0051] The above steps S1 to S4 are performed sequentially. After the virtual machine is started on physical machine 2, the user can check the model of the vCPU in physical machine 2 by typing the command line / proc / cpuinfo in the UI interface of the client (at this time, the user perceives that the physical processor corresponding to the virtualized vCPU in physical machine 2 is Kunpeng 920), and the physical processors objectively viewed as Feiteng 2000 are modified to the physical processors of the same manufacturer and the same version as Kunpeng 920 in physical machine 1. At the same time, since the process of reading the manufacturer information and version information of the physical processors in physical machine 1 and physical machine 2 by this method occurs in the initialization stage of the virtual machine, and after the virtual machine created by physical machine 2 is run, it will not cause any performance loss to the virtual machine created by physical machine 2, and it is beneficial to save the resource overhead of physical machine 2. At the same time, the heterogeneous processors can shield the isolation between the heterogeneous processors deployed in the underlying physical machine and the virtual machines created by virtualization technology through this method to ensure user experience.

[0052] By using this method to simulate multiple physical machines in a server cluster, it can meet the following requirements: Figure 2 Computer events such as migration operations performed between physical machines in heterogeneous scenarios can be reduced, so that users will not be aware of the migration operation performed by a physical machine due to insufficient resources or failure under the guidance of the Hypervisor, thereby preventing the physical hardware information logically located at the bottom layer from being exposed to users.

[0053] The series of detailed descriptions listed above are only specific descriptions of feasible implementation methods of the present invention. They are not intended to limit the scope of protection of the present invention. Any equivalent implementation methods or changes that do not deviate from the technical spirit of the present invention should be included in the scope of protection of the present invention.

[0054] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0055] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A method for mutual simulation between heterogeneous processors, characterized in that: The following steps are involved: S1, initialize the register VPIDR_EL2 of the reference physical processor in the kernel space, write the value of the register MIDR_EL1 included in the physical processor to be simulated, so as to modify the kernel of the physical machine to which the reference physical processor belongs; S2. In the operating system to which the reference physical processor belongs, compile the kernel of the physical machine to which the modified reference physical processor belongs, update it to the operating system where the reference physical processor is located, and run the compiled kernel to modify the value of the register VPIDR_EL2 of the reference physical processor; S3, the virtualization management program determines the manufacturer and / or model of the physical processor to be simulated according to the value of the register VPIDR_EL2 of the modified benchmark physical processor; Herein, heterogeneous processors are physical processors with the same logical architecture but from different manufacturers and / or different versions; S4. Start a virtual machine on the physical machine where the physical processor to be simulated is located through a virtualization management program, and select the manufacturer and / or model of the added physical processor to be simulated for the virtual machine.

2. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: The value of the register VPIDR_EL2 of the reference physical processor is modified to be the value of the register MIDR_EL1 included in the physical processor to be simulated.

3. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: The step between step S2 and step S3 also includes: pre-configuring the virtualization management software of the physical machine where the reference physical processor is located with the description information of the manufacturer and / or model of the physical processor to be simulated.

4. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: In step S2, the user manually types a command line in the UI interface to perform kernel compilation on the physical machine.

5. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: It is used to simulate heterogeneous processors deployed on at least two physical machines in a server cluster.

6. The method for mutual simulation between heterogeneous processors according to claim 5, characterized in that: The physical machine includes: a physical computer, a tablet computer or a wearable electronic device based on the ARM architecture.

7. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: The physical processor is a physical processor based on ARM architecture.

8. The method for mutual simulation between heterogeneous processors according to claim 1, characterized in that: The step S3 is executed when the virtualization management program creates a virtual machine in the physical machine, and the virtualization management program directly modifies the value of the register VPIDR_EL2 included in the multiple logical processors included in the virtual processor.

Images