A virtual machine memory virtualization method and system for a sunway processor

Abstract

The present application relates to the technical field of computer system virtualization, in particular to a virtual machine memory virtualization method and system for a Sunway processor. The method manages the reserved continuous physical memory through a virtual memory device, and provides a standard interface to the user state; the virtual machine obtains continuous memory as the guest physical memory through the interface; and then the direct mapping of the guest physical address to the host physical address is established by using the segment mapping of the virtual mode of the Sunway processor. The system comprises corresponding memory pools, driving modules and other components. The scheme realizes near-zero overhead address conversion on the Sunway platform without hardware assistance, and solves the flexible management and efficient sharing of the guest memory across processes through the device interface for the first time.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a virtual machine memory virtualization method and system for Shenwei processors. Background Technology

[0002] In the general-purpose processor field, hardware-assisted memory virtualization technologies (such as Intel's EPT and AMD's NPT) have become key to improving virtual machine performance. They significantly reduce virtualization overhead by directly handling nested address translation in hardware. However, on domestic processor platforms like Shenwei, due to the lack of dedicated hardware support, memory virtualization still relies entirely on software, leading to significant performance challenges. Traditional software solutions mainly follow the technical path of "shadow page tables" or "software-simulated nested page tables." The core problem is that, in order to maintain and synchronize the address mapping relationship between the guest and host machines, the virtual machine monitor needs to frequently intervene in the guest's memory access operations, resulting in a large amount of context switching and trap / escape overhead. Especially when handling exceptions such as nested page table page faults, the performance loss is even more severe, becoming a bottleneck restricting the overall efficiency of the virtual machine.

[0003] To address the aforementioned performance issues, existing technologies have proposed several optimization approaches. One approach attempts to improve the query efficiency of nested page tables, for example, by designing "smooth nested page tables" to reduce the number of query stages. However, this does not fundamentally change the basic model that relies on page table traversal and trap handling, resulting in limited performance improvements and increased complexity. Another approach is to statically reserve contiguous physical memory for the virtual machine and utilize the address offset mapping (i.e., segmented mapping) supported by the Shenwei processor to simplify the conversion. However, this approach typically relies on fixed memory reservations at kernel startup, making the reserved memory region invisible to user space and rigidly managed. It cannot achieve dynamic allocation and is difficult for other processes on the host machine (such as user-space backend services implementing network and storage acceleration) to directly access it. Therefore, it cannot support modern virtualization functions that require efficient memory sharing, such as zero-copy I / O and hot migration, greatly limiting its practicality.

[0004] Therefore, the current virtualization technology of the Shenwei platform faces a dual dilemma: on the one hand, software solutions based on page table lookups have inherent performance overhead; on the other hand, simple segment mapping schemes that can achieve efficient translation sacrifice the flexibility and shareability of memory management. A new solution that can balance high-performance address translation with flexible memory resource management is urgently needed. Summary of the Invention

[0005] The purpose of this invention is to provide a memory virtualization solution for Shenwei processors that balances high-performance address translation with flexible memory resource management.

[0006] According to a first aspect of the present invention, a virtual machine memory virtualization method for Shenwei processors is proposed, comprising: Memory reservation step S1: During the host machine startup phase, a contiguous physical memory region is reserved; Device interface provides step S2: Provide a virtual memory device in the operating system kernel to manage a contiguous physical memory region and expose an access interface to user space; Guest memory allocation step S3: The virtual machine monitoring process allocates and maps a contiguous physical address space from a contiguous physical memory region to the virtual machine instance by calling the access interface, which serves as the guest physical memory of the virtual machine instance. Segmented direct mapping step S4: Based on the virtual mode supported by the Shenwei processor, establish a segmented direct mapping relationship that maps the guest physical address space of the virtual machine instance as a whole to the allocated contiguous physical address space linearly, where the host physical address = guest physical address + fixed offset.

[0007] According to some embodiments, in the method of the first aspect of the present invention, the memory reservation step S1 specifically includes: By configuring bootloader parameters, the contiguous memory allocator in the operating system kernel can perform reservations during initialization to form contiguous physical memory regions.

[0008] According to some embodiments, in the method of the first aspect of the present invention, in step S2 of providing the device interface, the virtual memory device is a user-mode character device; The guest memory allocation step S3 specifically includes: the virtual machine monitoring process completes the allocation and mapping by opening the device file corresponding to the character device and calling the memory mapping system call.

[0009] According to some embodiments, in the method of the first aspect of the present invention, the virtual memory device is configured as follows: In response to memory-mapped system calls, it dynamically partitions sub-regions from a contiguous physical memory region for allocation.

[0010] According to some embodiments, the method of the first aspect of the present invention further includes a memory sharing step: At least one auxiliary process accesses a physical memory subregion shared with the virtual machine instance by opening and mapping the same virtual memory device.

[0011] According to some embodiments, in the method of the first aspect of the present invention, the auxiliary process and the virtual machine instance communicate with each other using a circular buffer in a shared physical memory sub-region and a corresponding synchronization mechanism, with zero-copy data communication.

[0012] According to some embodiments, the method of the first aspect of the present invention further includes a linear memory view construction step: When organizing the memory view of virtual machine instances, the virtual machine monitoring process merges multiple logical memory regions into a single linear address space view because the guest physical memory addresses are contiguous.

[0013] According to a second aspect of the present invention, a virtual machine memory virtualization system for Shenwei processors is proposed, deployed in a host computer containing a Shenwei processor, the system comprising: The hardware resource layer includes a memory resource pool consisting of a contiguous physical memory segment of the host computer, and a Shenwei processor operating in a virtual mode that supports segmented mapping. The kernel management layer contains virtual memory device driver modules loaded into the operating system kernel. These driver modules are configured to manage the memory resource pool and expose a unified device file access interface to user space. The user space layer contains the virtual machine monitoring process running in the host user space. The virtual machine monitoring process is configured to dynamically obtain and map a contiguous physical address space from the memory resource pool through the device file access interface, so as to serve as the physical memory of the virtual machine instance. The segment mapping unit of the Shenwei processor is configured to directly map the guest physical address space of the virtual machine instance to the contiguous physical address space mapped by the virtual machine monitoring process with a fixed offset.

[0014] According to some embodiments, in the system of the second aspect of the present invention, the virtual memory device driver module of the kernel management layer includes: The resource management unit is used to record and manage the allocation status of the memory resource pool at the page level. The address mapping service unit is used to respond to mapping requests initiated by user-space processes through the device file access interface and establish a mapping relationship between the virtual address of the process and the physical page in the memory resource pool.

[0015] According to some embodiments, the system of the second aspect of the present invention further includes at least one auxiliary process; The auxiliary process runs in the host user space and is configured to map and access physical memory regions shared with the virtual machine instance by operating the same device file interface; The system also includes communication data structures located in a shared physical memory area to support zero-copy data exchange between auxiliary processes and virtual machine instances.

[0016] The solution proposed by the present invention achieves the following technical effects: 1. To address the problem that the lack of hardware-assisted virtualization units in the Shenwei processor leads to huge performance overhead in software-simulated address translation, this invention achieves near-zero overhead GPA to HPA address translation at the software level by combining a collaborative architecture of "segment direct mapping" and "virtual memory device interface", making the virtual machine memory access performance approach the native level of the physical machine.

[0017] 2. In response to the problems of traditional static segmented mapping schemes, such as reserved memory being invisible to user space, rigid management, and inability to dynamically adjust, this invention creates and exposes a standard virtual memory character device to achieve dynamic and fine-grained management of the contiguous memory pool in the form of a driver. This enables on-demand allocation and reclamation of guest memory, significantly improving the flexibility and efficiency of memory resource utilization.

[0018] 3. To address the issue that guest machine physical memory cannot be directly accessed by other user-mode processes on the host machine (such as network and storage backend services), thus preventing the implementation of advanced functions such as zero-copy and hot migration, this invention achieves efficient zero-copy data communication between the virtual machine and auxiliary processes through a cross-process memory sharing mapping mechanism based on the same virtual memory device file and communication data structures such as a pre-set circular buffer in shared memory. This provides a fundamental support for high-performance I / O and hot migration at the product level.

[0019] 4. To address the problem of complex and inefficient internal memory management models in virtual machine monitors (such as QEMU) due to memory dispersion, this invention enables virtual machine monitors to construct a single, linear, flat memory view by ensuring the continuity of guest physical memory, thereby simplifying their memory management logic and improving overall operation and parsing efficiency. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without exceeding the scope of protection claimed by the present invention.

[0021] Figure 1 This is a flowchart illustrating an embodiment 1000 of a virtual machine memory virtualization method for Shenwei processors according to the present invention. Figure 2 This is a schematic diagram of the memory access process of the Shenwei processor in Embodiment 1000 of the present invention; Figure 3 This is a flowchart illustrating an embodiment 2000 of a virtual machine memory virtualization method for Shenwei processors according to the present invention. Figure 4This is a flowchart illustrating an embodiment 3000 of a virtual machine memory virtualization method for Shenwei processors according to the present invention. Figure 5 This is a schematic diagram of an embodiment 4000 of a virtual machine memory virtualization system for Shenwei processors according to the present invention; Figure 6 for Figure 5 A schematic diagram of the structure of the kernel management layer 402 in embodiment 4000. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Figure 1 This is a flowchart illustrating an embodiment 1000 of a virtual machine memory virtualization method for the Shenwei processor according to the present invention. Figure 1 As shown, Example 1000 includes steps S1-S4.

[0024] In memory reservation step S1, during the host machine startup phase, a contiguous physical memory region is reserved. Optionally, step S1 configures bootloader parameters to cause the contiguous memory allocator in the operating system kernel to perform reservation during initialization, thereby forming a contiguous physical memory region.

[0025] The subsequent segmented direct mapping in this scheme requires that the client's physical address space be mapped contiguously to the host's physical address space. Therefore, obtaining a large, contiguous block of physical memory in advance is a necessary prerequisite. Traditional operating system memory allocators are prone to fragmentation and cannot guarantee this. Through the memory reservation step S1, the physical continuity of the required memory resources is ensured from the source.

[0026] In some specific embodiments, the implementation process of memory reservation step S1 includes: (1) Configuration: The system administrator adds the configuration instruction for the contiguous memory allocator (CMA) to the kernel boot parameters by modifying the host machine's boot loader (such as GRUB) configuration file. For example, cma=2048M indicates that 2GB of contiguous physical memory needs to be reserved during system initialization.

[0027] (2) Execution: After the host machine restarts, during the Linux kernel initialization process, the mm_init function parses the CMA parameters. The CMA framework then, after the buddy system completes basic initialization, allocates a contiguous physical page frame of the requested size from a specific region of available physical memory (usually the low-end memory region) and marks it as a "CMA region" for reservation. This region is represented as a reserved memory area in the system's / proc / iomem file.

[0028] At this point, a pool of physically contiguous memory resources managed solely by the kernel is ready. This region will not be used by the general memory allocator to satisfy requests from ordinary kernel or user processes during normal system operation; it will be dedicated to subsequent virtual machine memory allocation.

[0029] In step S2, a virtual memory device is provided in the operating system kernel to manage a contiguous physical memory region and expose an access interface to user mode. Optionally, in step S2, the virtual memory device is a user-mode character device. Optionally, in step S2, the virtual memory device is configured to dynamically allocate sub-regions from the contiguous physical memory region in response to a memory-mapped system call.

[0030] In this invention, the memory reserved by CMA is invisible to user-mode processes and cannot be used directly. The core innovation of step S2, which provides the device interface, lies in creating a virtual memory device, abstracting the physical resources managed by the kernel into a standard device file. This allows user-mode processes to request and access this special memory through standard system calls (such as open, mmap) just like operating on ordinary files, thereby opening up a channel between user mode and kernel-reserved resources, achieving both management flexibility and interface standardization.

[0031] Specifically, the implementation process of step S2 provided by the device interface includes: (1) Driver module loading: After the kernel starts, the proprietary device driver module named sw64_vmem.ko is loaded by using the insmod command or by compiling it into the kernel.

[0032] (2) Device creation and initialization: In its initialization function (init_module), the driver module calls register_chrdev to register a major device number with the kernel, declaring itself as a character device driver.

[0033] The driver calls device_create to create a device node file in the / dev directory, such as / dev / sw64_vmem.

[0034] The driver initializes an important data structure—the memory pool management unit. This unit first acquires ownership of the contiguous physical memory reserved in step S1 by using the `cma_alloc` interface provided by the kernel CMA or by directly managing the reserved physical page frame number range. Subsequently, this unit establishes a set of metadata, meticulously recording the allocation status of each page in the entire memory pool, including allocated / free, at the page (e.g., 4KB) granularity.

[0035] The driver module in step S2 implements the key file operation interface. When the user-space process subsequently executes the mmap system call on the device file, the corresponding .mmap callback function within the driver will be triggered. The core logic of this function is: based on the size of the requested mapping, query the memory pool management unit to find a sufficient number of contiguous free physical pages; establish a mapping relationship between the page frame number (PFN) of these physical pages and the virtual address (VMA) of the process; and simultaneously update the memory pool management metadata, marking these pages as allocated. This process realizes dynamic sub-region partitioning and allocation. In guest memory allocation step S3, the virtual machine monitor process allocates and maps a contiguous physical address space from a contiguous physical memory region for the virtual machine instance by calling the access interface. This contiguous physical address space serves as the guest physical memory for the virtual machine instance. Guest memory allocation step S3 is the specific process of resource consumption. Through a standard interface, the virtual machine monitor can flexibly request a specific size of contiguous memory for each virtual machine without worrying about underlying fragmentation issues. This achieves on-demand, dynamic allocation of guest memory, significantly improving physical memory utilization compared to traditional solutions that require static pre-allocation of a fixed size of memory for virtual machines.

[0036] Optionally, the guest memory allocation step S3 specifically includes: the virtual machine monitoring process completes the allocation and mapping by opening the device file corresponding to the character device and calling the memory mapping system call.

[0037] In some specific embodiments, the specific implementation process of step S3 includes: (1) Process startup and configuration: The system administrator starts the QEMU process and specifies the memory backend as the previously created device file in its command line parameters.

[0038] (2) Interface calls and memory mapping: The initialization code of the QEMU process executes open(“ / dev / sw64_vmem”, O_RDWR) to open the device file and obtain a file descriptor (fd).

[0039] QEMU then calls mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0). This system call will pass through the kernel and eventually trigger the device driver's .mmap callback function in step S2.

[0040] The memory pool management unit within the driver responds to the request, allocates contiguous physical pages of a specified size (e.g., 4GB) from the reserved pool, and establishes a direct mapping from the QEMU process virtual address space (HVA) to these physical pages (HPA).

[0041] The QEMU process acquires a contiguous virtual address space, which in turn corresponds to contiguous physical memory. QEMU informs the virtual machine about this address space as physical memory. From the virtual machine's perspective, it has a contiguous physical address space (GPA) of a specified size, starting from address 0.

[0042] In the segmented direct mapping step S4, based on the virtual mode supported by the Shenwei processor, a segmented direct mapping relationship is established to linearly map the guest physical address space of the virtual machine instance to the allocated contiguous physical address space, where the host physical address = guest physical address + fixed offset.

[0043] Step S4 is the core step in this invention to solve the performance bottleneck of the Shenwei platform's hardware-unassisted virtualization. By configuring the processor itself, the conversion process, which originally required multiple table lookups in software (GPA->HPA), is transformed into a single fixed offset calculation performed by the hardware. This eliminates the software overhead caused by nested page table lookups and page fault handling, reducing the virtual machine memory access latency to almost the same level as native host programs. Specifically, step S4 includes: (1) Offset Calculation: In QEMU or its cooperating kernel modules, a fixed offset delta is calculated. This delta value is the final host physical address HPA corresponding to the address representing the client physical address 0GPA 0 in the QEMU process virtual address space HVA, obtained through mmap mapping in step S3. Since the mapping in step S3 is linear, the GPA to HPA satisfies: HPA = GPA + delta.

[0044] (2) Processor mode configuration: Before starting the virtual machine (via KVM_RUN ioctl), the VMM (KVM kernel module) sets the Shenwei processor to virtual mode.

[0045] (3) Segment Mapping Register Settings: The VMM writes to system registers specific to the Shenwei processor in virtual mode, such as the VPPTBR (Virtual Physical Page Table Base Register) or a similar register. The starting physical address HPA_base of the contiguous physical memory region obtained in step S1 is configured in this register. This operation informs the processor that all physical addresses GPA generated by virtual machine guests must be converted to the real physical address HPA by adding the offset implicit in this base address register. This offset is fixed at the hardware level as delta = HPA_base - GPA_base (usually 0).

[0046] (4) Runtime conversion: After the virtual machine starts, when its internal applications access memory, the CPU hardware automatically completes the following: a) using the page table in the virtual machine to complete the GVA -> GPA conversion; b) in virtual mode, the hardware automatically sends the GPA to the segment mapping unit, performs HPA = GPA + delta calculation, and directly obtains the target HPA. This process is highly efficient without software intervention.

[0047] In embodiment 1000 of this invention, through the coordination of steps S1 to S4, memory virtualization with both high performance and high flexibility is achieved on the Shenwei processor platform: First, in step S1, contiguous physical memory is reserved through the CMA mechanism, laying the resource foundation for efficient mapping; second, in step S2, the contiguous memory managed by the kernel is innovatively abstracted into a standard device file through the virtual memory device driver, opening up a channel for user-mode secure and dynamic access to this resource; then, in step S3, the virtual machine monitoring process can dynamically allocate contiguous memory as guest physical memory as needed through this interface, improving resource utilization; finally, in step S4, by configuring the segmented mapping unit of the Shenwei processor virtual mode, the conversion from guest physical address to host physical address is solidified into a fixed offset calculation executed by hardware, eliminating the overhead of software page table lookups and trap handling.

[0048] Overall, the solution of this invention solves the dual dilemma of "low performance of nested page table conversion" and "rigid and unshareable static segment mapping management" on the Shenwei platform, providing core technical support for realizing high-performance virtualization products that support advanced features such as zero-copy I / O.

[0049] Figure 2 This is a schematic diagram of the memory access process of the Shenwei processor in Embodiment 1000 of the present invention.

[0050] Shenwei CPUs support both Physical Mode and Virtual Mode, with the key difference being the dimension of the address space and the translation level.

[0051] In physical mode, there is only one layer of mapping from virtual address VA to physical address PA, such as... Figure 2 As shown, the fourth-level page table replacement process in physical mode: First, the physical base address of the top-level page directory (PGD) is obtained through the page table base address register (PTBR). Then, the parent directory (PUD) and the intermediate directory (PMD) of the page are queried sequentially. Finally, the target physical page frame number (PFN) is obtained from the page table entry (PTE), and the physical address is calculated by combining it with the page offset. This process requires a total of 4 memory accesses and is a standard and efficient path for the operating system to manage native processes.

[0052] In virtual mode, a Virtual Physical Address (VPA) is introduced as an intermediate layer in the architecture, forming a two-layer mapping model of VA→VPA→PA. Here, VPA is the "physical address" (GPA) seen by the guest operating system. If a general, purely software-simulated nested page table model is mechanically used to implement the complete VA→PA translation in this mode, a serious performance bottleneck will be encountered: To convert a client Virtual Machine (VA) to a host Virtual Interface (PA), a VA→GPA conversion must first be performed through the client's page table, requiring a maximum of four memory accesses. Each access to the client's page table itself (since the page table is also located in the GPA space) requires a GPA→HPA conversion, theoretically also requiring four memory accesses. This nested lookup results in a worst-case scenario where a single client memory access requires 4*4=16 memory accesses. Compared to the four accesses in physical mode, this represents an order-of-magnitude increase in overhead, accompanied by significant cache pollution and unpredictable latency, becoming a fundamental bottleneck restricting the virtualization performance of the Shenwei platform.

[0053] To address this bottleneck, the core technological innovation of this invention lies in completely abandoning the use of the general page table mapping model in the second layer GPA→HPA of the virtual machine. Instead, it creatively utilizes hardware characteristics to reconstruct it into a hardware-assisted segmented direct mapping. Its principle is based on a key point: if the client's physical address GPA space can be continuously mapped to the host's physical address HPA space, then the second-layer translation can be simplified from complex page table traversal to a deterministic linear calculation.

[0054] See Figure 2 The segmented page table replacement process in virtual mode: First, during host machine startup, a large contiguous block of physical memory is reserved using the Linux kernel's Contiguous Memory Allocator (CMA) framework by configuring a bootloader such as Grub. Then, when a virtual machine is created, all its memory is dynamically allocated from this contiguous pool, thus physically guaranteeing a linear relationship between GPA and HPA. Finally, the starting physical address HPA_base of this contiguous host memory is programmed into the Shenwei processor's dedicated segmented base address register (VPPTBR) in virtual mode. Afterward, when a guest machine accesses memory, the hardware automatically executes HPA = GPA + HPA_base after completing the VA→GPA (i.e., VA→VPA) conversion within the guest machine. This process is entirely performed in parallel by the hardware, without any additional memory access or software intervention.

[0055] According to such Figure 2 The embodiments shown in the present invention bring significant technical effects, including: 1. Performance Improvement: Reduces the potential 16 memory accesses for GPA→HPA translation in virtual mode to zero. The overall translation path degenerates back to the equivalent state in physical mode, requiring only one page table traversal within the client (4 memory accesses), eliminating the performance penalty caused by nested page tables.

[0056] 2. Determinism and Real-time Performance: Address translation becomes a deterministic hardware computation, completely avoiding virtual machine exits and context switching caused by missing nested page tables, greatly reducing tail latency and improving the real-time performance and predictability of the system.

[0057] 3. Simplified Architecture and Efficient Resource Management: Based on the CMA reservation mechanism and segmented mapping model, guest memory is treated as a unified linear address space. This greatly simplifies the complexity of memory management in the Virtual Machine Monitor (VMM) and makes dynamic memory allocation, reclamation, and cross-process sharing efficient and elegant.

[0058] Figure 3 This is a flowchart illustrating an embodiment 2000 of a virtual machine memory virtualization method for the Shenwei processor according to the present invention. Figure 3 As shown, Embodiment 2000 includes steps S201-S205. Specifically, steps S201-S204 and... Figure 1 Steps S1-S4 in the illustrated embodiment 1000 are the same and will not be repeated here.

[0059] Optionally, in memory sharing step S205, at least one auxiliary process accesses a physical memory sub-region shared with the virtual machine instance by opening and mapping the same virtual memory device.

[0060] Step S205, the memory sharing step, builds upon the architecture established by the virtual memory device interface provided in step S202 and the guest memory allocated in step S203, enabling secure and efficient cross-process memory sharing within the host machine. In modern virtualization, virtual machines often need to exchange data with other service processes on the host machine with extremely low latency and high throughput. Traditional inter-process communication (IPC) based on sockets or pipes involves multiple data copies and kernel context switches, resulting in significant overhead. This solution exposes guest memory through a virtual memory device, naturally possessing the potential to achieve direct cross-process memory sharing. Step S205 aims to systematically utilize this potential to solve the last-mile problem of high-performance I / O.

[0061] Specifically, the implementation process of memory sharing step S205 includes: (1) Auxiliary process configuration and mapping: Similar to the QEMU process, the auxiliary process that needs to access the guest memory also performs the open(" / dev / sw64_vmem", O_RDWR) operation at startup to obtain a device file descriptor pointing to the same physical memory pool. Subsequently, the process calls mmap and can specify the specific sub-region to be mapped through the ioctl command provided by the driver or a predefined offset.

[0062] (2) Driver Coordination and Address Translation: The memory pool management unit inside the virtual memory device driver records the ownership and mapping status of each page of physical memory. When an mmap request arrives from an auxiliary process, the driver does not allocate new memory, but checks whether the target region has already been allocated by the QEMU process and marked as shareable. If the verification passes, the driver performs "shared mapping," simultaneously mapping this allocated, specific physical page to the virtual address space of the auxiliary process. This means that the same physical page now has virtual address mappings from two or more different processes.

[0063] (3) Communication Mechanism Establishment: To achieve collaborative work, inter-process communication data structures need to be pre-configured within the shared memory region. The most typical example is the virtual queue, which usually consists of a descriptor table, available rings, and used rings. The QEMU process (representing the virtual machine front-end driver) and the auxiliary process (representing the back-end service) will, according to the virtio protocol, convert the host virtual address (HVA) of these rings into pointers for their own access. After that, the virtual machine only needs to put the data packet descriptor into the available ring, and the auxiliary process can directly read the data packet content from the shared memory location pointed to by the descriptor for processing, with zero data copy throughout the process.

[0064] According to such Figure 3The implementation shown in this invention achieves secure cross-process zero-copy memory sharing through a standardized interface. Virtual machines and auxiliary processes can directly read and write to the same physical memory region as if it were their own memory, eliminating data copying overhead and latency from frequent kernel intervention. This provides underlying support for scenarios such as user-space networking, storage acceleration, and rapid hot migration.

[0065] Figure 4 This is a flowchart illustrating an embodiment 3000 of a virtual machine memory virtualization method for the Shenwei processor according to the present invention. Figure 4 As shown, Embodiment 3000 includes steps S301-S305. Specifically, steps S301-S304 and... Figure 1 Steps S1-S4 in the illustrated embodiment 1000 are the same and will not be repeated here.

[0066] In the linear memory view construction step S305, when organizing the memory view of the virtual machine instance, the virtual machine monitoring process merges multiple logical memory regions into a single linear address space view because the guest physical memory addresses are contiguous.

[0067] In traditional virtualization, a guest's physical address space may consist of multiple discrete memory blocks from different sources. Virtual machine monitors such as QEMU use a tree-like data structure called MemoryRegion to manage these intricate regions. Building the final "flat memory view" used for fast address translation requires handling a large amount of overlap, priority merging, and hole-filling logic between regions, resulting in complex algorithms and significant runtime overhead.

[0068] Because this invention forces the guest core memory to come from a single, contiguous range of physical addresses, it fundamentally eliminates memory discreteness. This greatly simplifies the MemoryRegion structure used by QEMU to describe the guest's physical address space, resulting in a flat view that is essentially a linear address space with almost no gaps. This significantly reduces the computational complexity and memory overhead of the virtual machine monitor during memory layout initialization, runtime address resolution, and hot-plugging operations, thereby improving the overall stability and response speed of the system.

[0069] In some specific embodiments, the implementation process of the linear memory view construction step S305 includes: (1) Simplified data structure: During the initialization phase of QEMU startup client, its memory subsystem (such as memory_region_init_ram) only needs to create one contiguous, large single region when creating MemoryRegion for memory allocated by / dev / sw64_vmem, instead of dozens of possible small regions.

[0070] (2) Linear flattening: When QEMU calls functions such as memory_region_transaction_commit to finally construct the global FlatView, since all MemoryRegions are continuous and non-overlapping, the merging algorithm will efficiently output them as one or a very few continuous FlatRanges. This transformation process requires almost no complex interval tree calculations and conflict checks.

[0071] (3) Efficient Address Resolution: Subsequently, when QEMU needs to simulate device access or process internal operations, any query for the client physical address (GPA) (via functions such as address_space_translate) can be quickly completed in FlatView through simple range lookup and offset calculation, directly hitting the unique linear mapping range without the need for multi-level navigation in a complex tree structure. This determinism greatly improves the efficiency of simulation execution.

[0072] Figure 5 This is a schematic diagram of an embodiment 4000 of a virtual machine memory virtualization system for the Shenwei processor according to the present invention. Figure 5 As shown, embodiment 4000 includes a hardware resource layer 401, a kernel management layer 402, and a user space layer 403.

[0073] The hardware resource layer 401 includes a memory resource pool consisting of a contiguous segment of physical memory of the host computer, and a Shenwei processor operating in a virtual mode that supports segmented mapping.

[0074] Optionally, the physical contiguousness of the contiguous physical memory resource pool is an absolute prerequisite for implementing subsequent segmented direct mapping. Through the CMA framework configured during boot, contiguous page frames are determined from the host machine's physical address space, forming a dedicated physical memory pool. The linear arrangement of this memory determines that the guest physical address GPA can be directly addressed, like an array index, through a fixed base address, i.e., the starting HPA of the resource pool. Optionally, the host machine memory is placed in the low-order bits, and memory is allocated as needed from the reserved contiguous address segment when the guest machine starts.

[0075] Optionally, in hardware resource layer 401, the virtual mode of the Shenwei processor is the hardware foundation upon which the solution is implemented. This mode not only provides the privilege level isolation required to run virtual machines, but more importantly, its address translation unit is designed to be software configurable. Specifically, it allows a linear offset to be hard-coded into the hardware translation pipeline by setting specific system registers, such as VPPTBR, thereby changing the GPA to HPA translation from table lookup to computation.

[0076] In this invention, the configuration of the hardware resource layer 401 has the following technical effects: 1. Laying the foundation for performance: The contiguous memory pool eliminates the interference of memory fragmentation on the mapping relationship, providing a perfect physical carrier for segmented mapping; the processor's virtual mode provides a hardware channel to bypass inefficient software page table emulation.

[0077] 2. Achieve resource isolation: This resource pool is managed by a kernel-specific driver and is isolated from the host machine's general memory system, ensuring the independence and security of virtualized memory resources and preventing them from being squeezed out by other applications.

[0078] The kernel management layer 402 contains virtual memory device driver modules loaded into the operating system kernel. These driver modules are configured to manage memory resource pools and expose a unified device file access interface to user space.

[0079] Optionally, the virtual memory device driver module includes a resource management unit and an address mapping service unit: the resource management unit is used to record and manage the allocation status of the memory resource pool at the page level; the address mapping service unit is used to respond to mapping requests initiated by user space processes through the device file access interface and establish the mapping relationship between the virtual address of the process and the physical page in the memory resource pool.

[0080] User space layer 403 contains a virtual machine monitoring process running in the host user space. The virtual machine monitoring process is configured to dynamically acquire and map contiguous physical address spaces from the memory resource pool through the device file access interface, as the physical memory of the virtual machine instance.

[0081] Optionally, the hypervisor process pre-stores a large contiguous block of physical address space to the kernel management layer via standard open() and mmap() operations, and submits it as the guest's physical memory to the virtualization framework (such as KVM). This process is completely dynamic and on-demand.

[0082] Optionally, the user space layer 403 also includes at least one auxiliary process configured to: map and access a physical memory region shared with the virtual machine instance by operating the same device file access interface; the shared physical memory region has a pre-built communication data structure for supporting zero-copy data exchange between the auxiliary process and the virtual machine instance based on shared memory.

[0083] Optionally, similar to the virtual machine monitoring process, the auxiliary process requests mapping of a specific physical memory sub-region already occupied by the virtual machine through the same device file interface. After verifying its permissions, the driver establishes a shared mapping. Optionally, the pre-defined communication data structure serves as the implementation carrier for the application layer protocol. Both processes agree to arrange data structures at specific offsets in the shared memory, using these structures to transmit data descriptors and notifications, rather than the data itself. For example, the data structure includes a descriptor table, an available ring, and a used ring.

[0084] Optionally, the segment mapping unit of the Shenwei processor is configured to directly map the guest physical address space of the virtual machine instance to the contiguous physical address space mapped by the virtual machine monitoring process with a fixed offset.

[0085] Specifically, before the virtual machine starts, the VMM calculates the starting physical address HPA_base of the contiguous memory resource pool and writes it into the segment-mapped base address register in the Shenwei processor's virtual mode. Once this operation is completed, a fast translation channel is created at the hardware level. Subsequently, when the CPU executes in virtual mode, its MMU will automatically and in parallel perform the addition operation HPA = GPA + HPA_base after completing the VA->GPA translation within the guest machine, instead of initiating a page table lookup.

[0086] According to such Figure 5 The implementation shown in this invention provides basic raw materials and hardware capabilities through a hardware resource layer, which is then used for secure and flexible abstraction and scheduling by the kernel management layer. Finally, processes in the user space layer consume resources and implement higher-order functions. The configuration of segmented mapping units acts like a high-speed pipeline, efficiently connecting each layer. This architecture not only solves the performance problem of hardware-unassisted virtualization on the Shenwei platform but also addresses the flexibility issue in productization through an innovative sharing mechanism, forming a complete, efficient, and practical solution.

[0087] Figure 6 for Figure 5 A schematic diagram of the kernel management layer 402 in embodiment 4000. (See attached diagram.) Figure 6 As shown, the kernel management layer 402 includes a virtual memory device driver module 4a, which includes a resource management unit 4a1 and an address mapping service unit 4a2.

[0088] Optionally, the virtual memory device driver module 4a takes over the contiguous physical memory pool in the hardware resource layer and abstracts and service-oriented it: by registering it as a standard character device (such as / dev / sw64_vmem), it provides the user space with a unique, secure, and standard file operation interface for interacting with the physical memory pool.

[0089] Optionally, the resource management unit 4a1 is used to record and manage the allocation status of the memory resource pool at the page level. Optionally, the address mapping service unit 4a2 is used to respond to mapping requests initiated by user-space processes through the device file access interface and establish a mapping relationship between the virtual address of the process and the physical page in the memory resource pool.

[0090] Optionally, when a user-mode process calls the mmap() system call, it will eventually trigger the callback function of the address mapping service unit 4a2. The address mapping service unit 4a2 requests several contiguous physical pages from the resource management unit 4a1 based on the size of the request, and then calls a kernel function to map the page frame numbers of these physical pages into the virtual address space (VMA) of the requesting process, establishing a mapping relationship between the process's virtual address and the actual physical pages.

[0091] According to such Figure 6 The implementation method shown in this invention has the following technical effects: it transforms static, rigid reserved memory into a resource pool that can be dynamically allocated and reclaimed on demand, greatly improving the utilization rate of physical memory; through file interface and driver verification, it achieves controlled and secure access to kernel-exclusive resources by user space, avoiding the security risks of directly manipulating physical addresses. The implementation of "one physical page can be mapped to multiple processes" provides fundamental kernel support for subsequent cross-process memory sharing.

[0092] The embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of the present invention, its specific implementation methods, and its application scope, are all within the scope of protection of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A virtual machine memory virtualization method for Shenwei processors, characterized in that, include: Memory reservation step S1: During the host machine startup phase, a contiguous physical memory region is reserved; Device interface provision step S2: Provide a virtual memory device in the operating system kernel to manage the contiguous physical memory region and expose an access interface to user mode; Guest memory allocation step S3: The virtual machine monitoring process allocates and maps a contiguous physical address space from the contiguous physical memory region to the virtual machine instance by calling the access interface, which serves as the guest physical memory of the virtual machine instance; Segmented direct mapping step S4: Based on the virtual mode supported by the Shenwei processor, establish a segmented direct mapping relationship that linearly maps the guest physical address space of the virtual machine instance to the allocated contiguous physical address space, wherein the host physical address = guest physical address + fixed offset.

2. The method according to claim 1, characterized in that, The memory reservation step S1 specifically includes: By configuring bootloader parameters, the contiguous memory allocator in the operating system kernel can perform reservations during initialization to form the contiguous physical memory region.

3. The method according to claim 1, characterized in that, In step S2, the virtual memory device is a user-mode character device; The guest memory allocation step S3 specifically includes: the virtual machine monitoring process completing the allocation and mapping by opening the device file corresponding to the character device and calling the memory mapping system call.

4. The method according to claim 3, characterized in that, The virtual memory device is configured as follows: In response to the memory-mapped system call, sub-regions are dynamically partitioned from the contiguous physical memory region for allocation.

5. The method according to claim 4, characterized in that, The method also includes a memory sharing step: At least one auxiliary process accesses a physical memory subregion shared with the virtual machine instance by opening and mapping the same virtual memory device.

6. The method according to claim 5, characterized in that, The auxiliary process and the virtual machine instance communicate with each other using a zero-copy data exchange through a circular buffer within the shared physical memory sub-region and a corresponding synchronization mechanism.

7. The method according to claim 1, characterized in that, The method also includes a linear memory view construction step: When organizing the memory view of the virtual machine instance, the virtual machine monitoring process merges multiple logical memory regions into a single linear address space view because the physical memory addresses of the guest machines are contiguous.

8. A virtual machine memory virtualization system for Shenwei processors, characterized in that, Deployed in a host computer containing a Shenwei processor, the system includes: The hardware resource layer includes a memory resource pool consisting of a contiguous segment of physical memory of the host computer, and a Shenwei processor operating in a virtual mode that supports segmented mapping. The kernel management layer includes a virtual memory device driver module loaded into the operating system kernel. This driver module is configured to manage the memory resource pool and expose a unified device file access interface to user space. The user space layer contains a virtual machine monitoring process running in the host user space. The virtual machine monitoring process is configured to dynamically acquire and map a contiguous physical address space from the memory resource pool by operating the device file access interface, so as to serve as the physical memory of the virtual machine instance. The segment mapping unit of the Shenwei processor is configured to directly map the guest physical address space of the virtual machine instance to the continuous physical address space mapped by the virtual machine monitoring process with a fixed offset.

9. The system according to claim 8, characterized in that, The virtual memory device driver module of the kernel management layer includes: The resource management unit is used to record and manage the allocation status of the memory resource pool at the page level; The address mapping service unit is used to respond to mapping requests initiated by user-space processes through the device file access interface and establish a mapping relationship between the virtual address of the process and the physical page in the memory resource pool.

10. The system according to claim 8, characterized in that, The user space layer also includes at least one auxiliary process; The auxiliary process is configured to map and access a physical memory region shared with the virtual machine instance by operating the same device file access interface; The shared physical memory area is pre-configured with communication data structures to support zero-copy data exchange between the auxiliary process and the virtual machine instance based on shared memory.

Images