Resource-constrained persistent memory-oriented server, virtual machine monitor construction method and system and electronic equipment

Abstract

The invention discloses a virtual machine monitor system for a resource-limited persistent memory server, which comprises a configuration file module, a CPU (Central Processing Unit) management module, a memory management module, a cache management module, an interrupt management module, a cross-partition communication module and a virtual machine management module. The CPU management module is used for binding a virtual CPU to a physical CPU core, so that computing resources of the virtual machines are dedicated, and meanwhile, the virtual machines are prevented from competing for the CPU; the memory management module is used for dividing a physical memory region according to a configuration file and realizing address space isolation between virtual machines by utilizing two-stage address translation; the cache management module is used for performing isolation control on cache access of a plurality of virtual machines through a coloring mechanism of the last-level cache; and the interrupt management module is used for simulating the universal interrupt controller, and the virtual machine monitor re-injects the interrupt into the target virtual machine according to the configuration file after capturing the hardware interrupt.

Description

Technical Field

[0001] This invention belongs to the field of computer system technology, and specifically relates to a method and system for constructing resource-constrained persistent memory servers, virtual machine monitors, and embedded electronic devices. Background Technology

[0002] With the rapid development of industrial intelligence, the deployment scale of computationally intensive applications is growing exponentially, placing higher demands on the carrying capacity of underlying embedded systems. In the past, traditional embedded systems were often deeply optimized for specific application scenarios, typically running as a single bare-metal program or real-time operating system to ensure system performance. However, with the slowdown of Moore's Law and the diversification of application needs, embedded systems need to achieve cross-domain, multi-application integration and secure isolation under constraints in power consumption, cost, size, and performance. For example, in the field of intelligent vehicles, in-vehicle infotainment systems (non-critical systems processing multimedia data) and advanced driver assistance systems (critical systems processing sensor data in real time) with vastly different critical characteristics are generally deployed on the same resource-constrained system platform. This has led to a surge in demand for high-capacity, low-latency storage (such as persistent memory), far exceeding the limited memory capacity and slow flash speed of traditional embedded systems. Such embedded system scenarios have given rise to resource-constrained persistent memory servers, whose core solution feature is the integration of high-performance persistent memory to provide large-capacity non-volatile storage capabilities with near-memory speeds in strictly constrained embedded environments.

[0003] Against this backdrop, the core challenge facing embedded systems lies in how to efficiently integrate multiple subsystems with vastly different functional requirements and performance metrics on a single resource-constrained hardware platform, particularly meeting their differentiated needs for high-speed, large-capacity, and persistent storage, while ensuring strong isolation and resource guarantees between them. Existing architectures based on a single operating system or bare metal are insufficient to meet these multi-dimensional requirements, making the balance between efficient resource utilization, strict security boundaries, and performance guarantees for critical applications a critical issue that urgently needs to be addressed.

[0004] Persistent memory is a key hardware innovation for addressing the storage challenges of embedded systems. It combines the low latency and high bandwidth of traditional DRAM with the non-volatility and large capacity of external disk storage. Persistent memory can directly store data that needs to be persisted, such as critical system states, operation logs, sensor data, and multimedia data, at near-RAM speeds, significantly reducing the performance overhead and latency fluctuations caused by data transfer along traditional paths through the processor, cache, RAM, and external storage.

[0005] Virtualization technology is one of the effective ways to solve the problem of balancing resource utilization, security boundaries, and performance guarantees in resource-constrained persistent memory servers. Virtualization technology deploys a virtual machine monitor on the hardware platform, building an abstraction layer on the computer hardware to achieve unified management, isolation, and on-demand allocation of physical hardware resources. Each virtual machine runs its own separate operating system or bare-metal program, and can only access and perceive the specific hardware resources allocated to it, while remaining completely invisible to the resources allocated to other virtual machines and their running status. Therefore, virtualization technology can achieve effective utilization of physical hardware resources, provide strict resource isolation and security boundaries for different subsystems, and meet the performance requirements of critical applications.

[0006] The technical terms used in this disclosure are as follows.

[0007] DRAM: Dynamic Random Access Memory. It is a type of memory hardware in computer systems used for temporary storage of data and programs. Its core characteristics include volatility, high speed, low capacity, and high cost.

[0008] Guest OS: Guest Operating System. It refers to an operating system instance running in a virtual machine environment, accessing abstracted hardware resources through a virtualization layer. Unlike the host operating system, which runs directly on physical hardware, the guest operating system runs in a virtualized, isolated environment created by a virtual machine monitor.

[0009] ATF: Arm Trusted Firmware. Provides a reference implementation of secure-world firmware for Armv7-A, Armv8-A, and Armv9-A, with core components including a security monitor running on EL3 and a secure partition manager running on S-EL2.

[0010] Armv8 architecture: ARMv8 refers to the eighth version of the ARM architecture, usually referring to ARMv8-A. This version introduced the 64-bit instruction set architecture (AArch64) for the first time, while also being compatible with the 32-bit instruction set (AArch32). It was designed to provide enhanced performance, better power efficiency, and support for modern computing needs, such as advanced multimedia and security features.

[0011] Linux is a free and open-source Unix-like operating system. It is licensed under the GNU General Public License, which allows any individual or organization to freely use, modify, and redistribute all of Linux's underlying source code. Its technical features include: a modular kernel architecture for hardware resource scheduling; a mechanism that separates user space from kernel space to ensure system stability; and support for cross-platform virtualization extensions (KVM / Xen, etc.).

[0012] PSCI: Power State Coordination Interface. Operating systems typically use PSCI for CPU and overall system power management. This interface provides standardized power control primitives, including CPU core hibernation state switching, dynamic addition and removal of CPU cores, secondary core booting, system-level shutdown and reset, etc.

[0013] TLB: Translation Lookaside Buffer. A dedicated cache component of the memory management unit used to store the mapping between virtual addresses and physical addresses. When a program accesses virtual memory, the TLB can quickly translate the virtual address into a physical address to improve memory access efficiency.

[0014] DoS attack: Denial of Service attack. A network attack that maliciously consumes the target system's critical resources (including processor power, memory bandwidth, or network connections), causing the computer system to lose its normal service capabilities.

[0015] GIC: Generic Interrupt Controller. A centralized interrupt management hardware component defined by the ARM architecture specification. It receives interrupts from peripherals, prioritizes them, and passes them to the appropriate processor core. Currently, there are four official versions: GICv1 to GICv4. GICv1 is deprecated, GICv2 supports up to eight ARM cores, and GICv3 / GICv4 support even more ARM cores.

[0016] vPE: Virtual Processing Element. A virtualized execution entity defined in the Arm architecture. Processing element implementations conforming to the Arm architecture must follow the behavior described in the corresponding Arm architecture reference manual.

[0017] SMC: Secure Monitor Call. A hardware instruction defined in the Armv7-A / Armv8-A / Armv9-A architecture, it is the core mechanism for implementing secure state switching. Calling the SMC instruction at EL1 or EL2 level triggers a synchronization exception, entering the highest privilege level EL3, achieving hardware-level isolation switching between the insecure and secure worlds.

[0018] EL: Exception level. The Armv8 architecture provides four exception levels: EL0 (user application layer), EL1 (operating system kernel layer), EL2 (virtual machine monitor layer), and EL3 (security firmware layer). In AArch64, the exception level determines the execution privilege level. Exception levels provide hardware isolation guarantees for cross-level memory / instruction access for all operational states in the Armv8 architecture. Summary of the Invention

[0019] One embodiment of this disclosure is a virtual machine monitor system for resource-constrained persistent memory servers. The virtual machine monitor includes a configuration file module, a CPU management module, a memory management module, a cache management module, an interrupt management module, a cross-partition communication module, and a virtual machine management module.

[0020] The configuration file module is used to statically partition all platform hardware resources, including CPU cores achieving exclusive binding through affinity, fixed address range partitioning of physical memory regions, and virtual machine binding of interrupt numbers and I / O devices, so as to support the configuration of platform hardware resource isolation topology during the embedded system initialization phase.

[0021] The CPU management module is used to bind the virtual CPU and the real CPU core of each virtual machine, ensuring that the tasks of each virtual machine obtain the necessary computing resources, and to implement the PSCI proxy mechanism of the virtualization monitor.

[0022] The memory management module is used to divide the physical memory DRAM and persistent memory regions according to the configuration file, and to achieve address space isolation based on two-stage virtual address translation, so as to ensure that virtual machines do not interfere with each other.

[0023] The cache management module is used to control the access isolation of the last-level cache by multiple virtual machines through cache coloring, so as to avoid cache interference and ensure the real-time performance of critical programs.

[0024] The interrupt management module is used to simulate a general interrupt controller using software. After the virtual machine monitor captures a hardware interrupt, it re-injects the interrupt into the corresponding virtual machine according to the configuration file.

[0025] The cross-partition communication module is used to provide an efficient and secure message communication mechanism between different virtual machines, including a high-speed data channel based on shared memory, event notification and interrupt triggering, so as to achieve low-latency cross-partition collaboration.

[0026] The virtual machine management module is used to create and start virtual machines, and to initialize virtual CPUs, virtual memory, virtual devices, etc.

[0027] One embodiment of this disclosure is a persistent memory server that integrates the aforementioned virtual machine monitor system.

[0028] One embodiment of this disclosure is an embedded electronic device, including the persistent memory server described above.

[0029] One embodiment of this disclosure is a SoC chip, which includes an ARMv8 multi-core, a last-level cache, a GICv3 interrupt controller, a persistent memory controller, and the virtual machine monitor is burned into the firmware ROM.

[0030] The embodiments disclosed herein have significant advantages in terms of security isolation capabilities and resource utilization efficiency in practical applications, and can effectively improve the overall performance and reliability of the system. Attached Figure Description

[0031] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:

[0032] Figure 1 Schematic diagrams of Type I and Type II virtual machine monitors.

[0033] Figure 2 A schematic diagram of two-stage address translation according to one embodiment of the present invention.

[0034] Figure 3 A schematic diagram of the cache coloring principle according to one embodiment of the present invention.

[0035] Figure 4 A schematic diagram of the cache coloring effect according to one embodiment of the present invention.

[0036] Figure 5 A schematic diagram of the process of generating and sending a virtual interrupt according to one embodiment of the present invention. Detailed Implementation

[0037] According to one or more embodiments, a virtual machine monitor system for resource-constrained persistent memory servers includes a configuration file module, a CPU management module, a memory management module, a cache management module, an interrupt management module, a cross-partition communication module, and a virtual machine management module.

[0038] The configuration file module is used to statically allocate persistent memory server resources (including platform hardware resources such as CPU, memory, interrupts, I / O, etc.) and allocate each resource to a specific virtual machine instance.

[0039] The CPU management module is used to bind virtual CPU cores to physical CPU cores, ensuring that virtual machine computing resources are dedicated to virtual machines, while avoiding performance loss caused by competition for CPU between virtual machines.

[0040] The memory management module is used to divide the physical memory region according to the configuration file and to achieve address space isolation between virtual machines using two-stage address translation;

[0041] The cache management module is used to isolate and control cache access from multiple virtual machines through the coloring mechanism of the last-level cache.

[0042] The interrupt management module is used to simulate a general interrupt controller using software. After the virtual machine monitor captures a hardware interrupt, it re-injects the interrupt into the target virtual machine according to the configuration file.

[0043] The cross-partition communication module is used to provide low-latency, secure message communication between virtual machines through shared memory, event notification, and interrupt triggering mechanisms.

[0044] The virtual machine management module is used to create, initialize, and start virtual machine instances, and to perform simple low-level initialization work on virtual CPUs, virtual memory, virtual devices, etc.

[0045] Furthermore, the configuration file module statically partitions all platform resources, providing other modules with a view of the static partitioning of virtual machine resources.

[0046] The CPU management module completes the initialization of the physical CPU at the virtual machine monitor level, including setting Armv8 architecture-related information, and provides a general PSCI interface to the virtual machine management module.

[0047] The memory management module supports two-stage address translation and physical page memory pool management, and has the function of accessing the corresponding page table entry based on the virtual address through a recursive page table. It also provides a virtual page allocation interface to other modules.

[0048] The cache management module uses cache coloring technology to divide the last-level cache, ensuring that each virtual machine accesses the last-level cache in a spatially isolated manner.

[0049] The interrupt management module implements virtualization support for GIC, including generating and sending virtual interrupts, and providing a maintenance interrupt mechanism to notify the virtual machine monitor of specific events in the virtual machine.

[0050] The steps for the interrupt management module to generate and send virtual interrupts include:

[0051] Step A: The redistributor forwards the physical interrupt to the physical CPU interface, and the CPU interface triggers a physical exception after checking.

[0052] Step B: When the physical CPU interface triggers an exception, the CPU enters the virtual machine monitor exception context, and the virtual machine monitor reads GICC_IAR to obtain the physical interrupt number.

[0053] Step C: The virtual machine monitor determines the target vPE based on the configuration file and writes the physical interrupt number to ICC_EOIR1_EL1;

[0054] Step D: The virtual machine monitor registers the physical interrupt and its corresponding virtual interrupt number in the idle list register, thus suspending the virtual interrupt.

[0055] Step E: The virtual machine monitor returns from an exception and resumes vPE operation, triggering a virtual interrupt at this time.

[0056] Step F: vPE reads GICC_IAR, obtains the virtual interrupt number, and processes the interrupt;

[0057] Step G: After the interrupt handling is completed, vPE writes GICC_EOIR, lowers the priority, and clears both virtual and physical interrupts.

[0058] The cross-partition communication module provides virtual machine communication functionality through shared memory.

[0059] The cross-partition communication module, the steps for inter-virtual machine communication include:

[0060] Step A: After writing the data to the shared physical memory, virtual machine 1 traps into EL2 using the SMC instruction;

[0061] Step B: The virtual machine monitor detects an exception and injects a virtual interrupt into virtual machine 2 through the interrupt management module;

[0062] Step C: Virtual machine 2 receives an interrupt and processes the data in the shared memory.

[0063] The virtual machine management module has the functions of allocating the resources required by the virtual machine, installing the virtual machine image in a specified memory location, initializing registers, performing virtual machine initialization work, and starting the virtual machine.

[0064] According to one or more embodiments, in order to achieve a balance between efficient utilization of embedded system resources, secure application isolation, and effective performance assurance, this disclosure proposes a method and system for constructing a virtual machine monitor for resource-constrained persistent memory servers. Embedded systems typically have extremely stringent limitations in terms of hardware resources, often possessing very small RAM and Flash / ROM, relatively weaker CPU performance compared to general-purpose computer systems, lower clock frequencies, fewer peripheral interfaces, and needing to simultaneously meet constraints such as low power consumption, strong real-time performance, small size, and low cost. In persistent memory server scenarios, the system integrates high-performance, non-volatile persistent memory, which makes it possible to handle applications requiring large-capacity, low-latency persistent storage (such as real-time data processing and critical status logs), but also places more stringent requirements on resource management and isolation. Currently, multiple distinct subsystems are often integrated on a single hardware platform. To meet system constraints and the strong isolation requirements between multiple critical subsystems, the virtual machine monitor implements static resource partitioning, permanently allocating the platform's CPU cores, physical memory regions, interrupts, and other hardware resources to designated virtual machines, and managing them independently of any other operating system, further saving system hardware resources.

[0065] The virtual machine monitor disclosed herein belongs to the first type of virtual machine monitor, currently supporting Armv8 architecture hardware platforms and running directly on the hardware, such as... Figure 1 As shown. This disclosure relies solely on low-level platform-managed firmware (such as ATF) and a platform-specific minimal serial driver, and does not depend on any other software to run, making it completely independent of general-purpose operating systems such as Linux.

[0066] Figure 1 This section showcases the architectures of two different types of hypervisors: Type I hypervisors and Type II hypervisors. Type I hypervisors run directly on top of the hardware, interacting directly with the underlying hardware (such as the CPU, memory, and hard drive), and are independent of the host operating system. Type I hypervisors reside above the hardware layer and directly manage multiple guest operating systems. Each guest operating system can run its own applications.

[0067] The second type of virtual machine monitor runs on top of the host operating system, creating and managing virtual machines on the host operating system. It resides above the host operating system layer, managing the Guest OS through the host operating system, and applications also run within the Guest OS.

[0068] The main function of the configuration file module is to statically partition all platform resources, providing other modules of the virtual machine monitor with a static view of virtual machine resources, including CPU core partitioning, physical memory range allocation, cache color configuration, interrupt resource mapping, and cross-partition communication memory pool configuration. This strictly isolates the resources owned by each virtual machine from those owned by other virtual machines at the virtual machine monitor level. The virtual machine monitor strictly controls the resource access permissions of each virtual machine; except for the cross-partition communication module, each virtual machine cannot access the resources of other virtual machines. This static partitioning of platform resources provides virtual machines with hardware abstraction capabilities, logically abstracting various entity resources of the embedded system and providing them to virtual machines with hardware from the same perspective as the Guest OS. This allows the Guest OS to make more reasonable scheduling strategy selections based on existing limited resources. This enables virtual machines to exclusively possess all their resources and access them in real time, avoiding performance losses caused by competing for hardware resources with other virtual machines.

[0069] The main function of the CPU management module is to perform CPU initialization at the virtual machine monitor level, initialize virtual CPU Armv8 architecture-related information, and provide a general PSCI interface to the virtual machine for low-level power control operations. Because the physical CPU and virtual CPU have a one-to-one mapping, complex CPU context management and a scheduler are unnecessary, further simplifying the size and complexity of the software code. In terms of implementation, upon system startup, the ATF performs basic hardware initialization, then transfers execution to the virtual machine monitor. The provision of a general PSCI interface to the virtual machine for low-level power control relies on the PSCI interface provided by the ATF. When the Guest OS calls the PSCI service, it is captured by the virtual machine monitor, which only checks the parameter validity and forwards the call to the ATF as an intermediary. The CPU initialization at the virtual machine monitor level includes: after simple page table initialization and CPU stack memory allocation, the CPU master core initializes the CPU synchronization token and calls the PSCI interface provided by the ATF firmware to start other CPU cores. Each CPU core reads the MPIDR_EL1 register, performs a flattening transformation, and records the real CPU ID into its own structure. The initialization of Armv8 architecture-related information for the virtual CPU includes: saving the value of the virtual CPU ID and writing it to the VMPIDR_EL2 register, converting the virtual address of the virtual machine root page table to a physical address and setting the VTTBR_EL2 register, etc.

[0070] Figure 2 This diagram illustrates a two-stage address translation mechanism used in virtualization environments to achieve address space isolation and memory management between virtual machines. From the application's perspective, the address space includes different memory regions such as peripherals, the kernel, and applications. The application's address space is mapped to the physical address space from the Guest OS's perspective through a first-stage address translation table. The Guest OS's physical address space includes physical memory regions such as DDR, peripherals, and Flash. The Guest OS's physical address space is then mapped to the virtual machine monitor's physical address space through a second-stage address translation table. The virtual machine monitor's physical address space includes physical memory regions such as DDR, peripherals, Flash, SRAM, and ROM. These regions are the physical memory that the virtual machine monitor can directly access.

[0071] The main functions of the memory management module are: two-stage address translation support, physical page memory pool management, and access to page table entries using recursive page tables. The two-stage address translation support provides logical address space isolation between virtual machines based on the physical memory allocation of the configuration file module. The second stage of the two-stage address translation ensures that a virtual machine can only see the physical memory regions allocated to it, and not the physical memory regions allocated to other virtual machines or virtual machine monitors. Figure 2 As shown, the Guest OS controls the first-stage address translation table, mapping the virtual address space to what it perceives as the physical address space. However, this process involves a second translation of the actual physical address space, controlled by the Virtual Machine Monitor (VMMonitor). Each virtual machine is assigned a Virtual Machine Identifier (VMID). The VMID is used to mark translation TLB entries to identify which virtual machine each entry belongs to. This marking allows translation entries from multiple different virtual machines to coexist in the TLB. The physical page memory pool is used by the VMMonitor to uniformly manage physical memory pages. During the initialization of the memory management module, an independent physical memory region is allocated as a memory pool for each virtual machine according to the configuration file module. The pool uses physical pages as the basic unit and employs a bitmap algorithm for management. Each bit in the bitmap represents a physical page; a value of 0 indicates that the page is not allocated, and a value of 1 indicates that the page is allocated. When a virtual machine needs memory, it allocates pages from its dedicated memory pool; when it releases memory, the pages are returned to the pool. The recursive page table is used to quickly calculate the virtual address of each level of page table entry corresponding to a certain virtual address. Its main principle is to map an entry from the level 0 page table to the level 0 page table itself, so that multi-level page table entries can be directly located through virtual addresses without the need for a whole block of continuous physical mapping.

[0072] Figure 3This diagram illustrates the principle of cache coloring. L2 cache includes: cache group number and cache block offset. The cache group number determines which cache group data should be stored in, and the cache block offset determines the specific location of the data within the cache block. Physical memory includes: physical page number and page offset. The physical page number determines the physical memory page where the data resides. The page offset determines the specific location of the data within the physical memory page. The page color is a part of the physical page number and is used to determine which cache group data should be stored in. By using page color, different physical memory pages can be mapped to different cache groups, thus avoiding cache conflicts. Cache coloring, by mapping different physical memory pages to different cache groups, can avoid cache conflicts between different virtual machines and improve cache utilization. Simultaneously, it prevents malicious virtual machines from launching DoS attacks by sharing the last-level cache between virtual machines, or indirectly accessing data of other virtual machines through implicit time-side channels.

[0073] Figure 4 This demonstrates the effect of cache coloring. Figure 4 It consists of four parts, each representing a cache set. Each cache set is divided into multiple cache lines, which can be allocated (shaded areas) or unallocated (blank areas). Through cache coloring, each virtual machine is assigned a specific cache color, meaning each virtual machine can only access cache lines of that specific color. In this way, access to the last-level cache by different virtual machines is strictly isolated, avoiding cache conflicts and potential security issues between virtual machines. This isolation helps prevent malicious virtual machines from stealing data from other virtual machines through cache side-channel attacks (such as time side-channel attacks).

[0074] The main function of the cache management module is to divide the last-level cache by cache coloring, preventing malicious virtual machines from potentially launching DoS attacks by sharing the last-level cache among virtual machines, or indirectly accessing data of other virtual machines through implicit time-side channels. Figure 3 As shown, there is some address overlap between the cache group number and the physical page number. This overlapping address field is used as the page color. Figure 3 In the example, the entire physical address space can be divided into a maximum of 2^4 = 16 colors, with each color having 2^5 = 32 cache groups. When a virtual machine requests a page, the virtual machine monitor only allocates physical memory pages belonging to the virtual machine's color specified in the configuration file. Ultimately, as shown... Figure 4As shown, by using cache coloring, access to the last-level cache by different virtual machines will be strictly isolated according to color, achieving stricter security control.

[0075] Figure 5 The process of generating and sending virtual interrupts in a virtualized environment is demonstrated. Figure 5 It includes multiple modules, including a virtual machine monitor, a guest OS, a physical CPU interface, and vGIC. The specific process includes:

[0076] S501, physical interrupts are forwarded from the redistributor to the physical CPU interface;

[0077] S502, the physical CPU interface checks whether the physical interrupt can be forwarded to the PE (Processing Element). If it can, it forwards the interrupt to the corresponding PE and triggers an exception. Here, PE refers to the CPU processing unit at the physical level. Only when the interrupt can be forwarded to the PE at the physical level will the program jump to the interrupt handler function. Then, the interrupt handler function decides which virtual machine vPE to forward the interrupt to.

[0078] S503, the virtual machine monitor reads the GICC_IAR register to obtain the physical interrupt number;

[0079] S504, the virtual machine monitor forwards virtual interrupts to the corresponding vPE according to the configuration file, and writes the physical interrupt number to the ICCEOIR1_EL1 register:

[0080] S505, Virtual Machine Monitor writes to list register to register a virtual interrupt:

[0081] S506, Virtual Machine Monitor error returned to Guest OS;

[0082] S507, the virtual machine reads the GICC_IAR register, returns the virtual interrupt number, and the virtual machine handles the exception;

[0083] After the S508 Guest OS finishes processing the interrupt, it writes to the GICC_EOIR register.

[0084] The main function of the interrupt management module is to implement virtualization support for the GIC, including generating and sending virtual interrupts, and providing maintenance interrupts for virtual machines to notify the virtual machine monitor of specific events within the virtual machine. The GIC is a general-purpose interrupt controller in the ARM architecture, responsible for interrupt routing and arbitration. In embedded systems supporting the ARMv8 architecture, GICv2 or GICv3 hardware architectures are generally used. Therefore, all interrupts are first sent to the virtual machine monitor, which then re-injects the interrupts into the specified virtual machine via a list register. Regarding the generation and sending of virtual interrupts, taking GICv3 virtualization support as an example, the implementation method is as follows... Figure 5 As shown: Step 1, the physical interrupt is forwarded from the redistributor to the physical CPU interface; Step 2, the physical CPU interface checks whether the physical interrupt can be forwarded to the PE. If the check passes, a physical exception is triggered; Step 3, the interrupt is passed to the virtual machine monitor, which then reads the GICC_IAR register to obtain the physical interrupt number; Step 4, according to the configuration file, the hypervisor determines that the interrupt needs to be forwarded to the currently running vPE, writes the physical interrupt number to the ICC_EOIR1_EL1 register, and when EOImode in the ICC_CTLR_EL1 register is 1, the priority is reduced and the physical interrupt is not disabled; Step 5, the hypervisor writes an idle list register to register a virtual interrupt as pending. The list register specifies the virtual interrupt number and physical interrupt number to be sent; Step 6, the virtual machine monitor executes an exception return, returning execution to the vPE; Step 7, the virtual exception is passed to the vPE. When the virtual machine reads the GICC_IAR register, it returns the virtual interrupt number and then processes the interrupt; Step 8, after the virtual machine processes the interrupt, it writes to the GICC_EOIR register. At this time, the priority is reduced, and both virtual and physical interrupts are disabled. The mechanism described above provides maintenance interrupts for virtual machines. These interrupts notify the virtual machine monitor of specific events, enabling the monitor to handle these critical events promptly. Three specific events trigger maintenance interrupts: 1) After the virtual machine handles the interrupt, it writes to the GICV_EOIR register, and the list register contains a specific entry, requiring the virtual machine monitor to perform cleanup work; 2) Currently, there is no valid interrupt entry in the list register, requiring the virtual machine monitor to fill it; 3) After the virtual machine handles the interrupt, it writes to the GICV_EOIR register, but the list register does not contain a corresponding entry, requiring further processing by the virtual machine monitor.

[0085] The main function of the cross-partition communication module is to transmit data between multiple virtual machines. Since the virtual machine monitor isolates the virtual machines, direct memory access and communication are restricted, so a dedicated mechanism is needed to achieve communication between virtual machines. In terms of implementation, this virtual machine monitor uses shared memory for inter-virtual machine communication, meaning multiple virtual machines interact by reading and writing to the same physical memory area. Taking communication between two virtual machines as an example, the specific communication steps are as follows: Step 1, after virtual machine 1 writes data to the shared physical memory area, it calls the SMC instruction and traps into EL2; Step 2, the virtual machine monitor catches an exception and injects a virtual interrupt into virtual machine 2, which shares the same physical memory area, through the interrupt management module; Step 3, the virtual machine receives the virtual interrupt and performs further processing on the data in the shared physical memory area.

[0086] The main functions of the virtual machine management module are: allocating resources required by the virtual machine, installing the virtual machine image in a specified memory location, performing a series of register initialization tasks, initializing the virtual machine, and starting the virtual machine. Allocating resources includes binding the CPU specified in the configuration file to the virtual machine and allocating the physical memory space necessary for the virtual machine management-related structures. The register initialization tasks include setting the VTCR_EL2 register (virtualization translation control register), HCR_EL2 register (virtual machine monitor control register), and CPTR_EL2 register (architectural feature trap register). Setting the latter two is mainly to prevent virtual machine access to high-level registers from being captured by EL2; setting the clock offset register CNTVOFF_EL2 to 0, indicating that the offset between the physical counter value and the virtual counter value is 0; and writing 0x30C50830 to the SCTLR_EL1 register to avoid unpredictable behavior after the virtual machine starts. The virtual machine initialization process includes: writing the virtual CPU ID to the VMPIDR_EL2 register; initializing the PSCI context state of the virtual CPU (setting it to ON if it's the virtual CPU master core, otherwise setting it to OFF); translating the virtual address of the virtual machine root page table into a physical address and setting the VTTBR_EL2 register for the second-stage address translation in the memory management module. The specific steps for starting the virtual machine are as follows: if it's the virtual CPU master core, jump to the starting address of the virtual machine image; if it's not the virtual CPU master core, call the PSCI interface in the CPU management module to put the CPU core into a shutdown state, waiting for the Guest OS to call the PSCI interface to wake it up. This is to prevent some Guest OSs from not supporting multi-core processors.

[0087] On resource-constrained embedded platforms with integrated persistent memory, this disclosure establishes a lightweight and controllable abstraction layer between the hardware and client software. This layer enables static resource partitioning and dedicated mapping (CPU affinity binding, physical memory / persistent memory area allocation), two-stage address translation and address space isolation, last-level cache coloring, virtualization interrupts, and controlled cross-partition communication. This satisfies the diverse needs of different client operating systems for high-speed, large-capacity, and persistent storage, while ensuring strong isolation and resource guarantees. This method is particularly suitable for Type I virtual machine monitors running directly on ARMv8 embedded platforms, achieving low-overhead hardware affinity isolation and engineering-level portability, thereby effectively mitigating contention, interference, and consistency issues in resource-constrained persistent memory servers.

[0088] It should be understood that in the embodiments of the present invention, the term "and / or" is merely a description of the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, the character " / " in this document generally indicates that the preceding and following associated objects have an "or" relationship.

[0089] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A virtual machine monitor system for resource-constrained persistent memory servers, characterized in that, The virtual machine monitor includes a configuration file module, a CPU management module, a memory management module, a cache management module, an interrupt management module, a cross-partition communication module, and a virtual machine management module. The configuration file module is used to statically allocate persistent memory server resources, and allocate each resource to a virtual machine. The CPU management module is used to bind virtual CPUs to physical CPU cores, so that virtual machine computing resources are dedicated to virtual machines and at the same time avoid competition for CPU between virtual machines. The memory management module is used to divide the physical memory region according to the configuration file and to achieve address space isolation between virtual machines using two-stage address translation; The cache management module is used to isolate and control cache access from multiple virtual machines through the coloring mechanism of the last-level cache. The interrupt management module is used to simulate a general interrupt controller. After the virtual machine monitor captures a hardware interrupt, it re-injects the interrupt into the target virtual machine according to the configuration file. The cross-partition communication module is used to provide low-latency, secure message communication between virtual machines through shared memory, event notification, and interrupt triggering mechanisms. The virtual machine management module is used to create, initialize, and start virtual machines, and to perform simple low-level initialization work on virtual CPUs, virtual memory, virtual devices, etc.

2. The virtual machine monitor system according to claim 1, characterized in that, The persistent memory server is based on the ARM architecture.

3. The virtual machine monitor system according to claim 1, characterized in that, The memory management module supports two-stage address translation and physical page memory pool management. It accesses the corresponding page table entry based on the virtual address through a recursive page table and provides a virtual page allocation interface to other modules of the system.

4. The virtual machine monitor system according to claim 1, characterized in that, The cache management module uses cache coloring technology to divide the last-level cache, ensuring that each virtual machine accesses the last-level cache in a spatially isolated manner.

5. The virtual machine monitor system according to claim 1, characterized in that, The interrupt management module implements virtualization support for GIC, including generating and sending virtual interrupts, and providing a maintenance interrupt mechanism to notify the virtual machine monitor of specific events in the virtual machine.

6. The virtual machine monitor according to claim 5, characterized in that, The steps for the interrupt management module to generate and send virtual interrupts include: Step 101: The redistributor forwards the physical interrupt to the physical CPU interface, and the CPU interface triggers a physical exception after checking. Step 102: After the exception enters the virtual machine monitor, the virtual machine monitor reads the GICC_IAR register to obtain the physical interrupt number; Step 103: The virtual machine monitor determines the target vPE based on the configuration file and writes the physical interrupt number into the ICC_EOIR1_EL1 register. Step 104: The virtual machine monitor registers the physical interrupt and its corresponding virtual interrupt number in the idle list register, thus suspending the virtual interrupt. Step 105: The virtual machine monitor returns from an exception and resumes vPE operation, triggering a virtual interrupt at this point. Step 106: vPE reads the GICC_IAR register, obtains the virtual interrupt number, and handles the interrupt; Step 107: After the interrupt handling is completed, vPE is written to the GICC_EOIR register to reduce the priority and clear both virtual and physical interrupts.

7. The virtual machine monitor system according to claim 1, characterized in that, The cross-partition communication module provides virtual machine communication via shared memory. The cross-partition communication module, the steps for inter-virtual machine communication include: Step 201: After the first virtual machine writes the data to the shared physical memory, it traps into EL2 using the SMC instruction. Step 202: The virtual machine monitor detects an exception and injects a virtual interrupt into the second virtual machine through the interrupt management module; Step 203: The second virtual machine receives the interrupt and processes the data in the shared memory.

8. A method for constructing a virtual machine monitor for a resource-constrained persistent memory server, characterized in that, (1) Read the configuration file, statically partition the persistent memory server resources and hardware resources, and allocate each resource to a specific virtual machine instance; (2) Initialize the core binding between the virtual CPU and the real CPU so that the tasks of each virtual machine can obtain computing resources and implement the PSCI proxy mechanism of the virtualization monitor to realize low-level power control operations. (3) Divide the physical memory DRAM and persistent memory regions according to the configuration file, and realize address space isolation based on virtual address two-stage translation to ensure that virtual machines do not interfere with each other; (4) By controlling the access isolation of the last-level cache by multiple virtual machines through cache coloring, cache interference is avoided and the real-time performance of critical programs is guaranteed; (5) Use software to simulate a general interrupt controller, capture hardware interrupts, and then re-inject the interrupts into the corresponding virtual machines according to the configuration file; (6) Provide a message communication mechanism for different virtual machines, including high-speed data channels based on shared memory, event notification and interrupt triggering, to achieve low-latency cross-partition collaboration; (7) Create and start the virtual machine, and initialize the virtual CPU, virtual memory, and virtual devices; (8) If it is a virtual CPU master core, then jump to the starting address of the virtual machine image; If it is not a virtual CPU master core, the PSCI interface in the CPU management module is called to put the CPU core into a shutdown state, waiting for the Guest OS to call the PSCI interface to wake it up.

9. A persistent memory server, characterized in that, Integrate the virtual machine monitor system as described in claim 1.

10. An embedded electronic device, characterized in that, Includes the persistent memory server as described in claim 9.

Images