A mutual simulation method between heterogeneous processors
By modifying register values in kernel space and adding model information in the virtualization hypervisor, mutual simulation between isomerized physical CPUs is achieved, solving the problem of users perceiving the underlying hardware differences and improving the user experience.
Patent Information
- Application Number
- CN202111312482.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-11-08
- Publication Date
- 2025-02-11
- Estimated Expiration
- 2041-11-08
AI Technical Summary
In isomerization scenarios, differences between physical CPUs with the same architecture but different manufacturers and/or versions will cause the user to perceive the differences in the underlying physical hardware, affecting the user experience.
By modifying the register HFGRTR_EL2 of the physical processor in the kernel space, setting the value of the MIDR_EL1 bit to 1, and using the hardware acceleration module to add the register MIDR_EL1 of the simulated virtual processor to the kernel space, writing the MIDR_EL1 value of the physical processor to be simulated. Add the model of the physical processor to be simulated in the hypervisor and pass its value into the register MIDR_EL1 of the virtual processor to realize mutual simulation between physical CPUs.
The differentiated hardware information between isomerized physical CPUs is masked, avoiding the user's perception of the differences between the underlying physical hardware, improving the user experience, and reducing abnormalities caused by hardware differences during virtual machine migration.
Smart Images

Figure CN114090170B_ABST
Abstract
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 basic physical hardware information such as the architecture, manufacturer, and version 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 differences 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 based on heterogeneous processors, which is used to realize mutual simulation between physical CPUs with the same architecture but different manufacturers and / or versions in a heterogeneous scenario, and to avoid the differences between the underlying physical hardware being perceived by users.
[0006] To achieve the above-mentioned object of the invention, the present invention provides a method for mutual simulation between heterogeneous processors, comprising the following steps:
[0007] S1. In the kernel space, set the value of the MIDR_EL1 bit in the register HFGRTR_EL2 contained in the physical processor to 1;
[0008] S2, using the hardware acceleration module to add the register MIDR_EL1 of the simulated virtual processor to the kernel space, and write the value of the register MIDR_EL1 contained in the physical processor to be simulated;
[0009] S3. Add the model of the physical processor to be simulated in the virtualization management program, and transfer the value of the register MIDR_EL1 contained in the physical processor to be simulated to the simulated register MIDR_EL1 contained in the virtual processor added to the kernel space.
[0010] As a further improvement of the present invention, after the step S3 is executed, it further 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 model of the added physical processor to be simulated for the virtual machine.
[0011] As a further improvement of the present invention, it also includes: pre-configuring a set of values of registers MIDR_EL1 included in multiple physical processors to be simulated, and transferring the set to the virtualization management program.
[0012] As a further improvement of the present invention, it also includes: establishing a mapping relationship between the value of register MIDR_EL1 and the manufacturers and / or models of multiple physical processors to be simulated, so that after adding the manufacturer and / or model of the physical processor to be simulated in the virtualization hypervisor, a call to the mapping relationship event is initiated to the kernel space, and the value of register MIDR_EL1 contained in the physical processor to be simulated is determined to be written according to the manufacturer and / or model of the physical processor to be simulated.
[0013] 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.
[0014] As a further improvement of the present invention, the physical processor is a physical processor based on ARM architecture.
[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] Compared with the prior art, the present invention has the following beneficial effects:
[0017] Through the present invention, it is possible to shield differentiated hardware information between multiple heterogeneous physical CPUs or physical machines containing heterogeneous physical CPUs, realize mutual simulation between heterogeneous processors in heterogeneous scenarios of physical CPUs with the same architecture but different manufacturers and / or versions, and achieve the technical effect of preventing users from perceiving differences between underlying physical hardware, thereby improving user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Figure 1 It is an overall flow chart of a method for mutual simulation between heterogeneous processors of the present invention;
[0019] 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;
[0020] Figure 3 The field description of the register HFGRTR_EL2 included in the physical processor, where the name of the 25th bit is MIDR_EL1;
[0021] Figure 4 This is to add the field description of register MIDR_EL1 for simulating a virtual processor in kernel space.
[0022] Figure 5 This is a schematic diagram of users and apps accessing KVM in kernel space through the Guest kernel in user space. 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] Ginseng Figures 1 to 5 A specific implementation of a method for mutual simulation between heterogeneous processors (hereinafter referred to as "method") of the present invention is shown.
[0025] 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 it will fall into VMM (Virtual Machine Monitor). At the same time, since the shadow page table realizes the mapping relationship of GVA (client virtual address, GuestVirtual 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 computing overhead and large performance loss.
[0026] Ginseng Figure 5 As shown, the user and APP (program or application or interface) access KVM in kernel space through the Guest kernel in user space. KVM provides virtualization of CPU and memory, as well as I / O interception of the client. The I / O of the Guest kernel is intercepted by KVM and then processed by QEMU. The QEMU code used by the KVM virtual machine is modified to run in user space, provide hardware I / O virtualization, and interact with KVM through IOCTL / dev / kvm devices.
[0027] Ginseng Figure 1 As shown, in this embodiment, the mutual simulation method between heterogeneous processors includes the following steps S1 to S4. The method is used to simulate the mutual simulation of 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. Figure 4As shown, for a 64-bit ARMv8 architecture physical CPU, register MIDR_EL1 is the main ID register describing the physical CPU, 0 to 3 bits represent the version (Revision), and 24 to 31 bits represent the manufacturer (Implementer). Therefore, in this embodiment, as long as two physical CPUs have different versions and / or different manufacturers, they constitute heterogeneous processors for users. Furthermore, the physical machine includes: a physical computer, tablet computer or wearable electronic device based on the ARM architecture. For example, one or more Kunpeng 920 physical CPUs, all of which are ARMv8 architectures, are deployed in physical machine 1, and one or more Feiteng 2000 physical CPUs, all of which are ARMv8 architectures, are deployed in physical machine 2.
[0028] 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.
[0029] Step S1, in the kernel space, set the value of the MIDR_EL1 bit in the register HFGRTR_EL2 contained in the physical processor to 1. Step S1 is executed by the physical machine kernel software. Register HFGRTR_EL2 is a fine-grained read trap event register, which is used to provide control of the MRS trap and MRC read of the system register. Register HFGRTR_EL2 exists only when FEAT_FGT is implemented; otherwise, direct access to HFGRTR_EL2 will be undefined. As shown in Figure 3, bit
[25] (i.e., the 25th bit) in register HFGRTR_EL2 is register MIDR_EL1, and the value of the MIDR_EL1 bit is set to 1 so that when the virtual machine created in the physical machine 2 reads the value of the register MIDR_EL1, it will trap into the virtualization management program (Hypervisor) of the physical machine 2, so as to facilitate the simulation of the virtualization management program.
[0030] Step S2, use a hardware acceleration module (such as KVM of Linux system) to add the register MIDR_EL1 of the simulated virtual processor to the kernel space (i.e. KernelSpace), and write the value of the register MIDR_EL1 contained in the physical processor to be simulated (i.e. Feiteng 2000). The aforementioned simulated virtual processor refers to the register MIDR_EL1 of Kunpeng 920. Feiteng 2000 also contains the same register MIDR_EL1 as Kunpeng 920, and only the value of the register MIDR_EL1 contained in Feiteng 2000 is different from the value of the register MIDR_EL1 contained in Kunpeng 920. Thus, vCPU_1 ( Figure 5 In the example, the register MIDR_EL1 contained in PCPU_1 in physical machine 1 (i.e. Kunpeng 920) is used to register vCPU_2 ( Figure 5 The MIDR_EL1 register is used to store the manufacturer information and version information of the physical processor.
[0031] Step S3: Add the model of the physical processor to be simulated in the virtualization management program (such as QEMU), and Figure 5 The value of register MIDR_EL1 (e.g. 0x00000000701f6622) contained in PCPU_2 in kernel space is passed to the virtual processor (i.e. Figure 5 The operation of adding the simulated register MIDR_EL1 of the simulated virtual processor to the kernel space is shown in the above step S2.
[0032] Specifically, in this embodiment, the core code of the register MIDR_EL1 that has been simulated and that is included in the virtual processor that has been added to the kernel space is as follows:
[0033]
[0034] Step S4: Start a virtual machine on the physical machine (eg, physical machine 2) where the physical processor to be simulated is located through a virtualization management program (Hypervisor), and select the model of the added physical processor to be simulated for the virtual machine.
[0035] Execute the above steps S1 to S4 in sequence. After the virtual machine is started on physical machine 2, the user can type the command line / proc / cpuinfo in the UI interface of the client after the virtual machine started by physical machine 2. The physical processors objectively viewed as Feiteng 2000 are modified to physical processors of the same manufacturer and the same version as Kunpeng 920 in physical machine 1. At the same time, since the method reads the manufacturer information and version information of the physical processors in physical machine 1 and physical machine 2 during the initialization phase of the virtual machine, and does not cause any performance loss to the virtual machine created by physical machine 2 after the virtual machine created by physical machine 2 is run, it is beneficial to save the resource overhead of physical machine 2. At the same time, the heterogeneous processors can shield the heterogeneous processors deployed in the underlying physical machine logically and the isolation between the virtual machines created by virtualization technology through this method to ensure user experience. After performing mutual simulation on multiple physical machines in a server cluster by this method, requirements such as 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.
[0036] Preferably, in this embodiment, the method further comprises: pre-configuring a set of values of register MIDR_EL1 included in a plurality of physical processors to be simulated, and transferring the set into the virtualization management program. At the same time, a mapping relationship between the value of register MIDR_EL1 and the manufacturers and / or models of the plurality of physical processors to be simulated is established, so that after the manufacturer and / or model of the physical processor to be simulated is added in the virtualization management program, a mapping relationship event is initiated to the kernel space, and the value of register MIDR_EL1 included in the physical processor to be simulated is determined to be written according to the manufacturer and / or model of the physical processor to be simulated. Based on the above technical means, more physical processors manufactured by different manufacturers, or physical processors of different versions of the same manufacturer, or physical processors of different versions manufactured by different manufacturers can be implemented to perform centralized mutual simulation, so that the physical processor that has recorded the virtualization management program and carries and characterizes the manufacturer information and version information of the physical processor is subsequently redeployed, thereby indirectly improving the operation of a server cluster composed of multiple physical machines, especially the simplicity of virtual machines deployed through virtualization technology, and avoiding exposing the underlying physical hardware information to users for all created virtual machines. As long as the aforementioned mapping relationship is formed, it can be called by KVM in the kernel space, thereby further improving the efficiency of mutual simulation between heterogeneous processors.
[0037] 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.
[0038] 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.
[0039] 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. In the kernel space, set the value of the MIDR_EL1 bit in the register HFGRTR_EL2 contained in the physical processor to 1; S2, using the hardware acceleration module to add the register MIDR_EL1 of the simulated virtual processor to the kernel space, and write the value of the register MIDR_EL1 contained in the physical processor to be simulated; S3, adding the model of the physical processor to be simulated in the virtualization management program, and transferring the value of the register MIDR_EL1 contained in the physical processor to be simulated to the simulated register MIDR_EL1 contained in the virtual processor added to the kernel space; 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 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: Also includes: A set of values of registers MIDR_EL1 included in a plurality of physical processors to be simulated is preconfigured, and the set is passed into the virtualization management program.
3. The method for mutual simulation between heterogeneous processors according to claim 2, characterized in that: Also includes: A mapping relationship between the value of register MIDR_EL1 and the manufacturers and / or models of multiple physical processors to be simulated is established, so that after the manufacturer and / or model of the physical processor to be simulated is added in the virtualization hypervisor, a call event of the mapping relationship is initiated to the kernel space, and the value of register MIDR_EL1 contained in the physical processor to be simulated is determined to be written according to 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: It is used to simulate heterogeneous processors deployed on at least two physical machines in a server cluster.
5. The method for mutual simulation between heterogeneous processors according to claim 2, characterized in that: The physical processor is a physical processor based on ARM architecture.
6. The method for mutual simulation between heterogeneous processors according to claim 4, characterized in that: The physical machine includes: a physical computer, a tablet computer or a wearable electronic device based on the ARM architecture.
Citation Information
Patent Citations
Glibc compatible method for different types of CPUs
CN112486570A
Emulating applications that use hardware acceleration
US10180850B1