CN114064200A - Two-stage embedded virtual machine management program framework and embedded system - Google Patents
Two-stage embedded virtual machine management program framework and embedded system Download PDFInfo
- Publication number
- CN114064200A CN114064200A CN202111183545.7A CN202111183545A CN114064200A CN 114064200 A CN114064200 A CN 114064200A CN 202111183545 A CN202111183545 A CN 202111183545A CN 114064200 A CN114064200 A CN 114064200A
- Authority
- CN
- China
- Prior art keywords
- virtual machine
- management module
- level management
- level
- embedded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000007246 mechanism Effects 0.000 claims abstract description 43
- 238000005192 partition Methods 0.000 claims abstract description 21
- 238000000638 solvent extraction Methods 0.000 claims abstract description 13
- 238000013519 translation Methods 0.000 claims description 21
- 238000004088 simulation Methods 0.000 claims description 10
- 238000012544 monitoring process Methods 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 4
- 241001522296 Erithacus rubecula Species 0.000 claims description 2
- 238000005516 engineering process Methods 0.000 abstract description 7
- 238000012938 design process Methods 0.000 abstract 1
- 230000006870 function Effects 0.000 description 16
- 238000000034 method Methods 0.000 description 16
- 230000014616 translation Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 11
- 238000002955 isolation Methods 0.000 description 10
- 238000003860 storage Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 3
- 230000007547 defect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the invention provides a two-stage embedded virtual machine management program framework and an embedded system, belonging to the embedded virtualization technology. The architecture comprises: the first-level management module runs on physical hardware of the embedded system, is used for providing a partitioning mechanism for virtualizing a CPU, a memory and equipment, and provides a virtual machine scheduling resource for the second-level management module; and the second-level management module runs on the first-level management module, is used as a main virtual machine of the embedded system, and is used for implementing service logic of CPU, memory and equipment virtualization by utilizing the virtual machine partition resources provided by the first-level management module. The embodiment of the invention is suitable for the design process of the management program of the embedded virtual machine.
Description
Technical Field
The invention relates to an embedded virtualization technology, in particular to a two-stage embedded virtual machine management program framework and an embedded system.
Background
With the increasing demand of users for the computing power of the internet of things, to better utilize hardware resources, a plurality of operating systems of different types (e.g., Linux, Android, etc.) need to be run on the same embedded platform at the same time, and currently, the operating systems are usually implemented by an embedded virtualization technology. The current embedded virtualization implementation technology has three types, namely hardware partitioning, software partitioning and dynamic scheduling.
The hardware partition relies on a plurality of hardware instances to replace time sharing of the same hardware unit and relies on firmware running on a special processor to manipulate a scheduling strategy, but because the partition is fixed, hardware resources cannot be dynamically allocated, and therefore resource utilization rate is relatively limited.
The advantages and disadvantages of software partitioning are the same as those of hardware partitioning, and the resources between partitions are independent and isolated from each other, but the partitions are fixed, so that the utilization rate of system resources is low.
The dynamic scheduling needs to implement a Virtual Machine management program, uniformly manage hardware resources of the system, abstract the hardware resources, and provide the abstracted hardware resources for sharing by multiple Virtual Machines (VMs), but because the isolation between the VMs needs to be ensured while implementing a complex resource scheduling policy, the existing server-level Virtual Machine management program has a complex architecture and an excessively large code size, which results in uncontrollable code scale and complexity, and thus it is difficult to ensure the reliability of the Virtual Machine management program.
Disclosure of Invention
The embedded virtualization management program is divided into two levels, the first level directly runs on hardware, the complexity and the code scale of the embedded virtualization management program are strictly controlled, the most basic partitioning mechanism is only realized by being matched with a hardware mechanism, the virtualization service logic is not involved, and the second level runs on the first level as a virtual machine and is not the bottommost software of the system, so that the complexity and the code scale of the second level do not need to be controlled, the complex virtualization service logic can be realized, and the resource utilization rate is improved.
In order to achieve the above object, an embodiment of the present invention provides a two-level embedded virtual machine management program architecture, including: the first-level management module runs on physical hardware of the embedded system, is used for providing a partitioning mechanism for virtualizing a CPU, a memory and equipment, and provides a virtual machine partitioning resource for the second-level management module; and the second-level management module runs on the first-level management module, is used as a main virtual machine of the embedded system, and is used for implementing service logic of CPU, memory and equipment virtualization by utilizing the virtual machine partition resources provided by the first-level management module.
Further, the first-stage management module runs on an ARM 64-bit processor.
Further, the first level management module operates in EL2 mode of ARMv 8-A.
Further, the first-level management module is further configured to provide initialization configuration, context switching of a VCPU (Virtual Central Processing Unit) between the second-level management module and a secondary Virtual machine, and Processing of exceptions, exception instructions, and sensitive instructions in the embedded system.
Further, the initialization configuration comprises a CPU initialization configuration, a memory initialization configuration, a low-level interrupt service routine initialization configuration and a virtual machine physical memory partition initialization configuration.
Further, the exception comprises an external interrupt, a soft interrupt and an instruction access exception.
Further, the exception instructions include undefined instructions, soft interrupt instructions, and instructions that cause memory access exceptions.
Further, the sensitive instruction includes an instruction to change a state of a PCPU (Physical Central Processing Unit).
Further, the second level management module operates in EL1 mode of ARMv 8-A.
Further, the first-level management module is further configured to monitor a heartbeat of the second-level management module by using a setting mechanism, and reload the second-level management module when it is monitored that the second-level management module fails.
Further, the architecture also includes a device emulation virtual machine for providing respective device drivers; the second-level management module is further used for monitoring the heartbeat of the equipment simulation virtual machine by using a set mechanism, and reloading the equipment simulation virtual machine when the equipment simulation virtual machine is monitored to be in fault.
Further, the device emulation virtual machine is further configured to monitor a heartbeat of a secondary virtual machine by using a setting mechanism, and notify the second-level management module when it is monitored that the secondary virtual machine fails, so that the second-level management module cooperates with the first-level management module to reload the failed secondary virtual machine.
Further, the setting mechanism is a watchdog mechanism.
Further, the first-level management module is further configured to retrieve physical memory partition information using a flat device tree table, and perform area division at a page granularity, where the divided areas include an area used by the first-level management module, an area used by the second-level management module, and an area used by a secondary virtual machine.
Further, the second-level management module further stores a first address translation page table, where the first address translation page table includes translation identification information from a virtual address of the virtual machine to an intermediate physical address.
Further, the first-level management module further stores a second address translation page table, where the second address translation page table includes translation identification information from an intermediate physical address to a real physical address of the virtual machine.
Further, the second-level management module is also used for executing the multi-core bootstrap program.
Further, the second-level management module is further configured to determine, according to the PCPU affinity configuration of the virtual machine, a PCPU bound to the VCPU thread of the virtual machine, and log the VCPU thread of the virtual machine into a running queue of the bound PCPU to execute in a time slice round robin manner.
Further, the device emulation virtual machine operates as a first secondary virtual machine of the embedded system.
Further, the first-level management module is further configured to restore the operation right of the second-level management module through hypercall when it is monitored that other secondary virtual machines send out a cross-region access request, where the cross-region access request is a request of the other secondary virtual machines to access a non-allocated physical memory region; the second-level management module is further used for sending a virtual interrupt to the equipment simulation virtual machine after the running right is obtained; the device emulation virtual machine is also used for calling a native device driver to access the non-distributed physical memory area by triggering the back end of the device driver, and sending access data to the second-level management module; the second-level management module is further configured to, after receiving the access data, invoke the hypercall provided by the first-level management module to perform context switching to the other secondary virtual machines, so that the other secondary virtual machines obtain the access data.
Correspondingly, the embodiment of the invention also provides an embedded system, and the embedded system comprises the two-stage embedded virtual machine management program architecture.
According to the technical scheme, the embedded virtualization management program is divided into two stages, the first-stage management module directly runs on hardware, the complexity and the code scale of the first-stage management module are strictly controlled, the most basic partitioning mechanism is realized only by being matched with a hardware mechanism, the virtualization service logic is not involved, the second-stage management module runs on the first-stage management module as a virtual machine and is not the bottommost software of a system, so that the complexity and the code scale of the second-stage management module do not need to be controlled, the complex virtualization service logic can be realized, and the resource utilization rate is improved.
Additional features and advantages of embodiments of the invention will be set forth in the detailed description which follows.
Drawings
The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the embodiments of the invention without limiting the embodiments of the invention. In the drawings:
fig. 1 is a schematic diagram of a two-level embedded virtual machine management program architecture according to an embodiment of the present invention;
fig. 2 is an exemplary diagram of reliability monitoring provided by an embodiment of the present invention.
Detailed Description
The following detailed description of embodiments of the invention refers to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating embodiments of the invention, are given by way of illustration and explanation only, not limitation.
In the current embedded virtualization implementation technology, dynamic scheduling is to provide hardware resources for sharing among multiple VMs after abstracting the hardware resources by managing a program of a virtual machine and performing unified management on the hardware resources of the system, and to implement efficient utilization of the resources by a complex resource scheduling algorithm.
However, the dynamic scheduling has a disadvantage in that it is difficult to ensure the reliability of the virtual machine hypervisor. Because isolation between VMs is guaranteed while implementing a complex resource scheduling policy, existing server-level virtual machine managers are complex in architecture and oversized in code size (e.g., hundreds of thousands of lines). Therefore, the code size and complexity are not controllable, and the new forward design is difficult to strictly meet the requirements of standards such as IEC 61508 and ISO 26262. Another technical route of current embedded hypervisor is to extend virtualization functions based on Real-time operating system (RTOS) certified by IEC 61508 or ISO 26262. And the existing scheduling function of the RTOS is utilized to realize resource scheduling, and the expanded virtualization function is used as an RTOS service routine or module. However, because of the code size limitation of the RTOS itself, it is difficult to flexibly implement a more complex resource scheduling algorithm. In summary, the utilization rate of system resources can be effectively improved by implementing dynamic scheduling in the embedded system through the virtual machine management program, but the reliability of the virtual machine management program and the isolation between virtual machines need to be ensured.
To ensure the reliability of the embedded system, the reliability of the software at the bottom layer in the system needs to be ensured first, and the reliability of the embedded virtual machine management program in the embedded system, which is the software at the bottom layer in the system, needs to be ensured. Ensuring the reliability of the software first requires ensuring that the software is free from defects (or controlling the number of defects to a controllable level), that is, ensuring the correctness of the code. At present, for software systems, methods that generally guarantee code correctness are only applicable to smaller-scale software, such as exhaustive testing and mathematical proofs. These methods typically require limiting the code size to hundreds or at most thousands of lines of code. Therefore, how to reduce the software size to the extent that the software can be processed by exhaustive testing or formalization methods has become an important means for improving the reliability of the software. Another aspect to ensure software reliability is to follow the most stringent design flow and comply with industry regulations, such as IEC 61508 and ISO 26262.
Ensuring the reliability of the embedded system also requires ensuring isolation between VMs, because shared access to hardware resources may cause resource contention between partitions or VMs, and if not, side channel attacks may result, which may also easily affect the time predictability of the system.
Reliability monitoring of multiple levels can be realized according to the software hierarchy to ensure the reliability of the embedded system. By means of a watchdog mechanism, the bottom layer software monitors the heartbeat of the upper layer software, and whether the upper layer software fails or not is judged through the heartbeat.
In order to realize the controllability of the complexity and the code scale of the embedded virtual machine management program, the embedded virtual machine management program can be designed in a forward direction strictly according to the requirements of standards such as IEC 61508 and ISO 26262. The method and the device for achieving the virtual machine management program have the advantages that the virtual machine management program function is combed, the most necessary and most core function is achieved, the core function can be roughly divided into three aspects of CPU virtualization, memory virtualization and device virtualization, in order to simplify software functions and control code size, the three aspects of functions can be achieved through cooperation with a hardware mechanism of an ARM processor, and isolation between VMs is achieved through the hardware mechanism of the ARM processor. Generally, the embedded virtualization management program is divided into two stages, the first stage directly runs on hardware, complexity and code scale of the embedded virtualization management program are strictly controlled, the most basic partitioning mechanism is only realized by being matched with a hardware mechanism, virtualization service logic is not involved, the second stage runs on the first stage as a virtual machine and is not bottom layer software of a system, and therefore the complexity and the code scale of the embedded virtualization management program do not need to be controlled, the complex virtualization service logic can be realized, and therefore reliability of the virtual machine management program is guaranteed, and isolation between the virtual machines is guaranteed.
Fig. 1 is a schematic diagram of a two-level embedded virtual machine management program architecture according to an embodiment of the present invention. As shown in fig. 1, the architecture comprises: the first-level management module 11 runs on physical hardware of the embedded system, and is used for providing a partition mechanism for virtualization of a CPU, a memory and equipment, and providing partition resources of a virtual machine for the second-level management module; and the second-level management module 12 runs on the first-level management module, serves as a main virtual machine of the embedded system, and is used for implementing service logic of CPU, memory and device virtualization by using the virtual machine partition resources provided by the first-level management module.
The first-level management module is the bottom-level software in the system, so that the complexity of the program is guaranteed to be controllable, and the code scale is small. In the framework, a physical memory partitioning mechanism of the virtual machine is realized only in the first-level management module, so that partition resources of the virtual machine are obtained, and forward design is performed according to standard requirements of IEC 61508, ISO26262 and the like. And providing a relevant interface for the second-level management module through the partition mechanism, so that the second-level management module can utilize the partition resources of the virtual machine to implement service logic of CPU, memory and equipment virtualization. In addition, no business logic is implemented in the first level management module. The first-level management module runs on an ARM64 bit processor, specifically, the first-level management module runs in an EL2 mode of ARMv8-A and serves as the bottommost software directly interacting with bottom-layer hardware, and the code scale of the first-level management module is controlled within 1 ten thousand lines. The first level management module provides the basic mechanism to take advantage of the hardware virtualization capabilities available in EL2 mode. First, the first-level management module provides an initialization configuration mechanism, which includes CPU initialization, memory initialization, low-level interrupt service routine initialization configuration, and virtual machine physical memory partition initialization configuration. The first-level management module strengthens protection and isolation between different VMs through hardware protection functions such as Non-secure PL1&0stage 2MMU in an ARM processor. Secondly, the first level management module provides a mechanism for VCPU context switching between the second level management module and the secondary virtual machine. The execution context, also called world (world), includes general purpose registers, system registers, and an address mapping table. Switching from one world to another is called world switching (also called context switching). Thirdly, the first-level management module captures various exceptions, abnormal instructions and sensitive instructions occurring in the embedded system. The exceptions include external interrupts (e.g., IRQ (Interrupt Request), FIQ (Fast Interrupt Request)), soft interrupts, and instruction access exceptions. The exception instructions include undefined instructions, soft interrupt instructions, and instructions that cause memory access exceptions. The sensitive instructions include instructions that change the state of the PCPU, such as WFI (Wait For Interrupt) instructions, WFE (Wait For Event) instructions, MSR (Move to Special Register from general Register) instructions, and the like. After capturing the abnormal/abnormal instruction, the first-level management module may directly process the abnormal instruction, and after capturing the sensitive instruction, the first-level management module may also route the abnormal instruction to the second-level management module, and the second-level management module schedules a Device Emulation VM (Device Emulation VM) in the embedded system to perform complex Device Emulation. And finally, the first-level management module provides a calling interface of a basic mechanism for the second-level management module through hypercall.
In addition, the second-level management module runs on the first-level management module and serves as a main virtual machine of the embedded system. Because the second-level management module runs on the first-level management module and is not the lowest software of the system, the complexity and the code scale of the second-level management module do not need to be controlled, and therefore complex service logic (including a complex resource scheduling algorithm) can be realized. Because the code scale of the second-level management module is large and the business logic is complex, the second-level management module cannot meet the reliability requirement of safety key or mission key, but because the first-level management module and the second-level management module run at different processor exception levels, and the first-level management module realizes isolation between VMs by using a hardware mechanism, the normal work of the first-level management module and other VMs in the system cannot be influenced when the second-level management module fails or has errors.
In addition, the second level management module operates in EL1 mode of ARMv8-A, which focuses on controlling all available resources of the hardware platform and performs resource scheduling for VMs. The second-level management module can be divided into two layers, the bottom layer is an embedded real-time operating system, and the embedded real-time operating system can manage the MMU, process various interrupts, operate a plurality of processors and perform thread scheduling. Based on the function of the embedded real-time operating system, the second-level management module also realizes VCPU scheduling. It is necessary to allocate VCPUs to multiple secondary VMs (e.g., DVM, Linux, RTOS, etc.) and create one VCPU thread for each VCPU. And after the VCPU thread is scheduled, the second-level management module switches to the secondary VM to run by calling the super call of context switching provided by the first-level management module. From the perspective of the second level management module, the hypercall that invokes the context switch will be blocked and will only return after the secondary VM exits the VCPU execution for some reason (e.g., executes a sensitive instruction, generates an exception, etc.).
In the embodiment of the present invention, because a two-level virtual machine management program architecture is adopted, a complex scheduling policy and algorithm are placed in the second-level management module, which simplifies the complexity of the first-level management module to ensure strict reliability, and at the same time, a layer of reliability monitoring is added in the embodiment of the present invention, as shown in fig. 2, the first-level management module is further configured to monitor the heartbeat of the second-level management module by using a setting mechanism, and when it is monitored that the second-level management module fails, the second-level management module is reloaded, which may be referred to as L1 RS. The second-level management module is further configured to monitor a heartbeat of the device emulation virtual machine by using a setting mechanism, and reload the device emulation virtual machine when it is monitored that the device emulation virtual machine fails, where the mechanism may be referred to as L2 RS. The device emulation virtual machine is further configured to monitor a heartbeat of a secondary virtual machine using a setup mechanism, and notify the second level management module when it is monitored that the secondary virtual machine fails, so that the second level management module cooperates with the first level management module to reload the failed secondary virtual machine, where the setup mechanism may be referred to as L3 RS. The setting mechanism may be a watchdog mechanism, thereby implementing a reliability supervision mechanism.
Three aspects of memory virtualization, CPU virtualization and device virtualization that can be achieved by the embodiments of the present invention will be described below.
In a first aspect, for memory virtualization:
the purpose of memory virtualization is to provide non-interfering memory spaces between VMs. The first-level management module is further configured to retrieve physical memory partition information by using a flat device tree table, and perform area division by using page granularity, where the divided areas include a first-level management module usage area, a second-level management module usage area, and a secondary virtual machine usage area. The first-level management module reserves a part of physical memory partitions for self use, and allocates memory pages which do not need to be shared to the use area of the second-level management module and the secondary virtual machine according to the flat device tree table.
In addition, the second-level management module further stores a first address translation page table, where the first address translation page table includes translation identification information from a virtual address of the virtual machine to an intermediate physical address. The first-stage management module is further used for storing a second address translation page table, and the second address translation page table comprises translation identification information from an intermediate physical address to a real physical address of the virtual machine. In order to simplify the function of the first-level management module, the second-level management module may implement mapping from a Virtual Address (VA) to an Intermediate Physical Address (IPA). However, since the IPA is not the final Physical Address, the access cannot be performed according to the IPA, and for all the memory access operations running in the VM, the first-level management module implements conversion from the IPA to a real Physical Address (PA). Wherein the second address translation page table is stored in a configuration register, and the first level management module is only able to access the configuration register if operating in EL2 mode of ARMv8-A, and the IPA to PA translation is completely transparent to the VM. Since the address space of the ARM 64-level architecture is very large, in order to simplify the design, the IPA address spaces of the VMs are defined not to conflict with each other, for example, the IPA range generated by the RTOS is defined to be 0-1GB, the IPA range generated by the Linux is defined to be 1GB-2GB, the IPA range generated by the DVM is defined to be 5GB-6GB, and the IPA range generated by the second-level management module is 6GB-7 GB.
In addition, in the embodiment of the present invention, another advantage of the memory virtualization is that a higher level of optimization can be performed in the second-level management module to improve the memory utilization without modifying the first-level management module. For example, the first-level management module provides the second-level management module with a function of configuring the IPA to PA mapping table through a hypercall, and the second-level management module may dynamically adjust its available physical memory area according to the runtime behavior of the VM (e.g., memory occupancy is too high at a certain time).
In a second aspect, for CPU virtualization:
in embedded systems, each PCPU is independent in that it has its own general purpose registers, system registers, MMU, L1 cache, local interrupt controller, and even local timers. The goal of CPU virtualization is to bind VCPUs to PCPUs and ensure that one VCPU context is not revealed to another VCPU that shares the same PCPU. In combination with hardware support, if a register is not a sensitive register that affects isolation between VMs, the first-level management module may save/restore the register state to its internal per-vcpu structure during a context switch to save/restore a context. In addition to ensuring consistent register state presentation, there are two additional tasks related to CPU virtualization: multi-core boot and VCPU binding.
In order to ensure that the complexity of the first-level management module is controllable, a multi-core bootstrap program is put into the second-level management module to be implemented, that is, the second-level management module is also used for executing the multi-core bootstrap program. And the first level management module only implements a mechanism for supplying power to a specific CPU core.
The second-level management module is further configured to determine, according to the PCPU affinity configuration of the virtual machine, a PCPU bound to the VCPU thread of the virtual machine, and log the VCPU thread of the virtual machine into a running queue of the bound PCPU to be executed in a time slice rotation manner. Specifically, to simplify system design, the second level management module implements a generic, configurable thread scheduling framework, with each PCPU registered with a dedicated scheduler. The default scheduler of the second-level management module is a round-robin thread scheduler, which maintains a running queue list of VCPUs, and each VCPU thread executes in a time slice round-robin manner. When a VCPU thread is created, the second-level management module is put into a running queue of a preferred PCPU according to the PCPU affinity configuration of the VM, and then the execution of the VM is switched by calling the super call of context switching. The second-level management module can also select other complex VCPU scheduling algorithms according to the workload scene of the VM.
In a third aspect, for device virtualization:
the device emulation virtual machine operates as a primary virtual machine of the embedded system, which provides various device drivers. The second-level management module allocates hardware equipment resources to the DVM, a standard Linux system is operated in the DVM, the hardware equipment is operated through a primary equipment driver in the Linux system, and the virtual equipment driving back end is realized to provide equipment virtualization support for other secondary VMs. A plurality of operating systems (such as Linux, RTOS and the like) in the system all operate as secondary VMs, resources required by operation are provided for the secondary VMs through the cooperation of the primary management module and the secondary management module, and the access to the hardware devices is completed through the communication of the device driver front end in the secondary VMs and the virtual device driver back end in the DVM.
When monitoring that other secondary virtual machines send out a cross-region access request, the first-stage management module recovers the operation right of the second-stage management module through hypercall, wherein the cross-region access request is a request of the other secondary virtual machines for accessing a non-allocated physical memory region. And after obtaining the operation right, the second-level management module sends virtual interrupt to the equipment simulation virtual machine. And then, the device simulation virtual machine calls a native device driver to access the non-distributed physical memory area by triggering the back end of the device driver, and sends access data to the second-level management module. And after receiving the access data, the second-level management module calls the hypercall provided by the first-level management module to execute context switching to the other secondary virtual machines so as to enable the other secondary virtual machines to obtain the access data. Specifically, when other secondary virtual machines attempt to access other physical memory regions, accessing this address may first be trapped in the first level management module because the second address translation page table does not store translations to other physical memory regions. And then the first-level management module saves the context of other secondary VMs and restores the context of the second-level management module. The second-level management module obtains the operation right, then the second-level management module enables the DVM to trigger the execution of the device driver back end by injecting the virtual interrupt into the DVM, the device driver back end can call a native device driver in the DVM to access the non-allocated physical memory area, after the execution is finished, the access data is sent back to the second-level management module, and then the second-level management module calls the hypercall provided by the first-level management module to execute context switching to other secondary virtual machines so that the other secondary virtual machines obtain the access data. In this way, device virtualization is achieved in a manner that is imperceptible to the secondary virtual machine.
In the embodiment of the invention, the embedded virtualization management program is divided into two levels, the first level management module is used as a program directly running on hardware, the complexity and the code scale of the first level management module are strictly controlled, the most basic partitioning mechanism is realized only by being matched with a hardware mechanism, the virtualization service logic is not involved, the code scale can be controlled to be about 6000 rows, and forward design can be carried out according to the requirements of IEC 61508 and ISO 26262. The second-level management module is used as a main virtual machine and runs on the first-level management module, and is not the bottommost software of the system, so that the complexity and the code scale of the second-level management module do not need to be controlled, and complex virtualization service logic (including a complex resource scheduling algorithm) can be realized, so that the resource utilization rate is improved. Because the code scale of the second-level management module is large and the business logic is complex, the second-level management module cannot meet the reliability requirement of safety key or mission key, but because the first-level management module and the second-level management module run at different processor exception levels, and the first-level management module realizes isolation between VMs by using a hardware mechanism, the normal work of the first-level management module and other VMs in the system cannot be influenced when the second-level management module fails or has errors. In addition, a hierarchical reliability supervision mechanism is implemented, the heartbeat of the second-level management module is supervised by the first-level management module, the heartbeat of the DVM is supervised by the second-level management module, the heartbeat of other secondary VMs is supervised by the DVM, and the reliability of the system is ensured by reloading when a fault is found.
Correspondingly, the embodiment of the invention also provides an embedded system, and the embedded system comprises the two-stage embedded virtual machine management program architecture.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.
The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.
Claims (21)
1. A two-level embedded virtual machine hypervisor framework, comprising:
the first-level management module runs on physical hardware of the embedded system, is used for providing a partitioning mechanism for virtualizing a CPU, a memory and equipment, and provides a virtual machine partitioning resource for the second-level management module;
and the second-level management module runs on the first-level management module, is used as a main virtual machine of the embedded system, and is used for implementing service logic of CPU, memory and equipment virtualization by utilizing the virtual machine partition resources provided by the first-level management module.
2. The two-level embedded virtual machine hypervisor architecture of claim 1, wherein the first level management module runs on an ARM 64-bit processor.
3. The two-level embedded virtual machine hypervisor architecture of claim 1, wherein the first level management module operates in EL2 mode of ARMv 8-a.
4. The two-level embedded virtual machine hypervisor architecture of claim 3, wherein the first level management module is further to provide initialization configuration, VCPU context switching between the second level management module and a secondary virtual machine, handling exceptions, exception instructions, and sensitive instructions in the embedded system.
5. The two-level embedded virtual machine hypervisor architecture of claim 4, wherein the initialization configuration comprises a CPU initialization configuration, a memory initialization configuration, a low-level interrupt service routine initialization configuration, and a virtual machine physical memory partition initialization configuration.
6. The two-level embedded virtual machine hypervisor architecture of claim 4, wherein the exceptions include external interrupts, soft interrupts, instruction access exceptions.
7. The two-level embedded virtual machine hypervisor architecture of claim 4, wherein the exception instructions comprise undefined instructions, soft interrupt instructions, and instructions that cause memory access exceptions.
8. The two-level embedded virtual machine hypervisor architecture of claim 4, wherein the sensitive instruction comprises an instruction to change a PCPU state.
9. The two-level embedded virtual machine hypervisor architecture of claim 1, wherein the second level management module operates in EL1 mode of ARMv 8-a.
10. The two-level embedded virtual machine management program architecture according to claim 1, wherein the first-level management module is further configured to monitor a heartbeat of the second-level management module by using a setting mechanism, and reload the second-level management module when it is monitored that the second-level management module fails.
11. The two-level embedded virtual machine hypervisor architecture of claim 1, further comprising a device emulation virtual machine to provide respective device drivers;
the second-level management module is further used for monitoring the heartbeat of the equipment simulation virtual machine by using a set mechanism, and reloading the equipment simulation virtual machine when the equipment simulation virtual machine is monitored to be in fault.
12. The two-level embedded virtual machine hypervisor framework of claim 11, wherein the device emulation virtual machine is further configured to monitor a heartbeat of a secondary virtual machine using a setup mechanism, and when it is monitored that the secondary virtual machine fails, notify the second level management module, so that the second level management module cooperates with the first level management module to reload the failed secondary virtual machine.
13. A two-level embedded virtual machine hypervisor architecture according to any of claims 10-12, wherein said setting mechanism is a watchdog mechanism.
14. The two-level embedded virtual machine manager architecture of claim 1, wherein the first-level management module is further configured to retrieve physical memory partition information using a flat device tree table and perform region partitioning at page granularity, wherein the partitioned regions include a first-level management module usage region, a second-level management module usage region, and a secondary virtual machine usage region.
15. The two-level embedded virtual machine hypervisor architecture of claim 14, wherein the second level management module further stores a first address translation page table, the first address translation page table including translation identification information of a virtual address to an intermediate physical address of a virtual machine.
16. The two-level embedded virtual machine hypervisor architecture of claim 14, wherein the first level management module further stores a second address translation page table that includes translation identification information of an intermediate physical address to a real physical address of the virtual machine.
17. The two-level embedded virtual machine hypervisor architecture of claim 1, wherein the second level management module is further to execute a multi-core bootstrap program.
18. The two-level embedded virtual machine hypervisor architecture of claim 1, wherein the second-level management module is further to determine a PCPU bound by a VCPU thread of the virtual machine according to a PCPU affinity configuration of the virtual machine, and to post the VCPU thread of the virtual machine to a run queue of the bound PCPU to execute in a time slice round robin manner.
19. The two-level embedded virtual machine hypervisor architecture of claim 11, wherein the device emulation virtual machine runs as a first secondary virtual machine of the embedded system.
20. The two-level embedded virtual machine management program architecture according to claim 19, wherein the first-level management module is further configured to restore the operation right of the second-level management module through a hypercall when it is monitored that other secondary virtual machines send out a cross-region access request, where the cross-region access request is a request of the other secondary virtual machines to access a non-allocated physical memory region;
the second-level management module is further used for sending a virtual interrupt to the equipment simulation virtual machine after the running right is obtained;
the device emulation virtual machine is also used for calling a native device driver to access the non-distributed physical memory area by triggering the back end of the device driver, and sending access data to the second-level management module;
the second-level management module is further configured to, after receiving the access data, invoke the hypercall provided by the first-level management module to perform context switching to the other secondary virtual machines, so that the other secondary virtual machines obtain the access data.
21. An embedded system, characterized in that it comprises a two-level embedded virtual machine hypervisor architecture according to any of claims 1-20.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111183545.7A CN114064200A (en) | 2021-10-11 | 2021-10-11 | Two-stage embedded virtual machine management program framework and embedded system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111183545.7A CN114064200A (en) | 2021-10-11 | 2021-10-11 | Two-stage embedded virtual machine management program framework and embedded system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114064200A true CN114064200A (en) | 2022-02-18 |
Family
ID=80234468
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111183545.7A Pending CN114064200A (en) | 2021-10-11 | 2021-10-11 | Two-stage embedded virtual machine management program framework and embedded system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114064200A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101075198A (en) * | 2006-05-17 | 2007-11-21 | 国际商业机器公司 | Method and system for providing two levels server virtualization |
| US20160170912A1 (en) * | 2014-12-16 | 2016-06-16 | Vmware, Inc. | Safely discovering secure monitors and hypervisor implementations in systems operable at multiple hierarchical privilege levels |
| CN106844007A (en) * | 2016-12-29 | 2017-06-13 | 中国科学院计算技术研究所 | A kind of virtual method and system based on spatial reuse |
-
2021
- 2021-10-11 CN CN202111183545.7A patent/CN114064200A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101075198A (en) * | 2006-05-17 | 2007-11-21 | 国际商业机器公司 | Method and system for providing two levels server virtualization |
| US20160170912A1 (en) * | 2014-12-16 | 2016-06-16 | Vmware, Inc. | Safely discovering secure monitors and hypervisor implementations in systems operable at multiple hierarchical privilege levels |
| CN106844007A (en) * | 2016-12-29 | 2017-06-13 | 中国科学院计算技术研究所 | A kind of virtual method and system based on spatial reuse |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10691363B2 (en) | Virtual machine trigger | |
| Mergen et al. | Virtualization for high-performance computing | |
| RU2398267C2 (en) | Hierarchical virtualisation through multi-level virtualisation mechanism | |
| US7757231B2 (en) | System and method to deprivilege components of a virtual machine monitor | |
| JP2018190454A (en) | Dynamic virtual machine sizing | |
| US20150169346A1 (en) | Method for controlling a virtual machine and a virtual machine system | |
| US11579908B2 (en) | Containerized workload scheduling | |
| US8539499B1 (en) | Symmetric multiprocessing with virtual CPU and VSMP technology | |
| US20180157519A1 (en) | Consolidation of idle virtual machines | |
| JP2013516021A (en) | Hypervisor separation of processor core | |
| Kang et al. | ConVGPU: GPU management middleware in container based virtualized environment | |
| CN110447012B (en) | Collaborative virtual processor scheduling | |
| CN115269057B (en) | Method for generating configuration file of isolation system based on equipment tree | |
| US20200341789A1 (en) | Containerized workload scheduling | |
| US20220156103A1 (en) | Securing virtual machines in computer systems | |
| CN111880891A (en) | Micro-kernel-based extensible virtual machine monitor and embedded system | |
| JP5030647B2 (en) | Method for loading a program in a computer system including a plurality of processing nodes, a computer readable medium containing the program, and a parallel computer system | |
| CN114064200A (en) | Two-stage embedded virtual machine management program framework and embedded system | |
| US11429424B2 (en) | Fine-grained application-aware latency optimization for virtual machines at runtime | |
| US11934890B2 (en) | Opportunistic exclusive affinity for threads in a virtualized computing system | |
| US9619277B2 (en) | Computer with plurality of processors sharing process queue, and process dispatch processing method | |
| WO2019139515A1 (en) | Management of dynamic sharing of central processing units | |
| CN114281529A (en) | Distributed virtualized client operating system scheduling optimization method, system and terminal | |
| US9122549B2 (en) | Method and system for emulation of instructions and hardware using background guest mode processing | |
| US8402191B2 (en) | Computing element virtualization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220218 |
|
| RJ01 | Rejection of invention patent application after publication |