Method for managing dynamic memory of virtual machine, virtual machine system and computing device

Abstract

Embodiments of the present specification provide a virtual machine dynamic memory management method, a virtual machine system and a computing device. The virtual machine dynamic memory management method is applied to a virtual machine system and includes the following steps. In response to a memory query request from a front end for a target secure virtual machine, target physical memory blocks allocated to the target secure virtual machine are determined from a plurality of physical memory blocks according to the secure virtual machines recorded in an extended memory tracking table of the plurality of physical memory blocks. The extended memory tracking table records address information and the secure virtual machines corresponding to the physical memory blocks. The address information recorded in the extended memory tracking table of the target physical memory blocks is obtained, and the address information is fed back to the front end. The risk of cross-virtual machine query is isolated. At the same time, through the dynamic query process, the address information obtained by the front end is synchronized with the extended memory tracking table, the operation of accessing the recycled memory through the residual address by the historical virtual machine is blocked, and the data life cycle is ensured to be traceable.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of virtual machine technology, and in particular to a method for managing dynamic memory in a virtual machine, a virtual machine system, and a computing device. Background Technology

[0002] With the development of virtual machines, the requirements for data security of virtual machine systems deployed in the cloud are increasing, with particular attention paid to the risk of sensitive data being tampered with or leaked during the operation of virtual machines.

[0003] Currently, mainstream virtualization solutions dynamically allocate physical memory blocks to secure virtual machines through the kernel virtual machine module and reclaim memory resources after the virtual machine stops running.

[0004] However, since the same physical memory block may be repeatedly allocated to different virtual machines, if the memory allocation status and data lifecycle are not effectively tracked, sensitive data remaining in released memory may be illegally accessed by subsequent virtual machines, leading to potential data leaks or tampering. Therefore, there is an urgent need for a virtual machine memory management method that can dynamically track and query physical memory information to ensure the reliability and traceability of memory data during the operation of secure virtual machines. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a method for managing dynamic memory in a virtual machine. One or more embodiments of this specification also relate to a virtual machine system, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a method for managing dynamic memory of a virtual machine is provided, applied to a virtual machine system, comprising: In response to a memory query request from the front end for the target security virtual machine, the target physical memory block to be allocated to the target security virtual machine is determined from multiple physical memory blocks based on the security virtual machine to which it belongs, as recorded in the extended memory tracking table of multiple physical memory blocks. The extended memory tracking table records the address information and the security virtual machine to which the corresponding physical memory block belongs. Obtain the address information recorded in the extended memory trace table of the target physical memory block and feed the address information back to the front end.

[0007] According to a second aspect of the embodiments of this specification, a virtual machine system is provided, including a virtualization management interface module, a virtual machine manager of a host operating system, and a system permission management software module; The virtualization management interface module is used to initiate an extended memory trace table query request to the system permission management software module through the virtual machine manager of the host operating system; The system permission management software module is used to determine the target physical memory block corresponding to the target security virtual machine based on the security virtual machine recorded in the extended memory tracking table, collect the address information recorded in the extended memory tracking table of the target physical memory block, and feed the address information back to the virtualization management interface module through the virtual machine manager of the host operating system.

[0008] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above method.

[0009] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0010] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0011] This specification provides an embodiment of a method for managing dynamic memory of a virtual machine system, which is applied to a virtual machine system and includes the following steps: in response to a memory query request from the front end for a target secure virtual machine, determining a target physical memory block to be allocated to the target secure virtual machine from multiple physical memory blocks according to the security virtual machine to which it belongs, wherein the extended memory tracking table records the address information and the security virtual machine to which the corresponding physical memory block belongs; obtaining the address information recorded in the extended memory tracking table of the target physical memory block and feeding the address information back to the front end.

[0012] By extending the memory tracking table to record the associated security virtual machine field, the system can track the identity of the virtual machine to which each physical memory block belongs in real time. When responding to frontend queries, only physical memory block addresses marked as belonging to the target security virtual machine are filtered and fed back, ensuring that the virtual machine can only access the memory region it is bound to, isolating the risk of cross-virtual machine queries. Simultaneously, the memory block status field, combined with address information, provides verification for memory allocation. When a physical memory block is released, the system can identify whether it contains residual sensitive data based on the status flag and forcibly trigger an erasure process before reallocating it to other virtual machines, avoiding illegal access to uncleaned memory due to misjudgment of status. Through a dynamic query process, the address information obtained by the frontend is synchronized with the extended memory tracking table. Even if the same physical memory block is allocated multiple times, the system can block historical virtual machines from accessing reclaimed memory through residual addresses based on the real-time updated virtual machine identifier and memory status, ensuring the traceability of data lifecycle. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a method for managing dynamic memory in a virtual machine, as provided in one embodiment of this specification. Figure 2 This is a hardware and software schematic diagram of a virtual machine system in a method for managing dynamic memory of a virtual machine provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the register group in a virtual machine dynamic memory management method provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the flowchart of a method for managing dynamic memory in a virtual machine according to one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a virtual machine system provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] Confidential Virtualization Extension: A confidential computing extension framework for virtualization scenarios. It provides runtime protection for secure virtual machines (TVMs) through hardware-assisted encryption and isolation technologies (such as memory encryption and key binding), ensuring that sensitive data of virtual machines is not illegally accessed or tampered with by the host machine or other virtual machines during physical memory and computing. Core capabilities include memory encryption, remote authentication, and trusted I / O channel management.

[0020] The Memory Tracking Table (MTT) is a metadata table in a virtual machine system used to record the basic status of physical memory blocks (such as allocated / free). It allows for quick retrieval of the current usage of memory blocks via address indexes, providing a basis for decision-making by the memory allocation module. Its limitation lies in the lack of fine-grained security attribute tracking and its inability to address the risk of data residue when memory is reused across virtual machines.

[0021] Extended Memory Tracking Table (EMTT): This is an extension of the memory tracking table structure, adding fields for the associated security virtual machine (e.g., binding a security virtual machine identifier) ​​and memory block status, enabling full lifecycle tracking of physical memory blocks. During memory allocation, release, and querying, the extended memory tracking table associates memory blocks with the security virtual machine identity, and triggers a data erasure process based on the status fields, preventing cross-virtual machine data leakage at its source.

[0022] Virtual Machine (VM): An independent computing environment simulated through virtualization technology, sharing underlying physical resources (CPU, memory, etc.). Traditional VMs rely on the Hypervisor for resource scheduling, but lack proactive protection mechanisms against residual memory data. Physical memory blocks may be maliciously reclaimed and reused, leading to the leakage of sensitive information across VMs.

[0023] Physical Address (PA): The actual storage unit address of a physical memory block, mapped to a virtual address (VA) through the memory management unit. In a virtualization scenario, the virtual addresses of multiple VMs may map to the same physical address. If the ownership and status of physical addresses are not controlled (e.g., by extending the memory trace table mechanism), residual data in the released physical memory may be illegally read by newly allocated virtual machines.

[0024] TrustVirtualMachine (TVM): A secure virtual machine instance built on a confidential security domain. Its memory space, CPU state, and I / O operations are protected by hardware-level security mechanisms, allowing access only to authorized entities. Through confidential virtualization extension capabilities and an extended memory tracking table, TVM ensures that physical memory allocation and access adhere to confidentiality and integrity verification rules.

[0025] Trusted Execution Environment (TEE): An isolated execution environment built on CPU security extensions, providing protected memory regions and a trusted application sandbox. Combined with a secure virtual machine, the TEE ensures that the secure virtual machine's code and data are processed in encrypted memory, preventing direct access to or modification of sensitive information within the TEE even by the host machine or other virtual machines with high privileges.

[0026] Kernel-based Virtual Machine (KVM) module: A virtualization module that achieves hardware-assisted virtualization by directly exposing the host machine's physical resources (CPU, memory) to virtual machines. Its core relies on CPU virtualization extensions, providing CPU scheduling and memory management capabilities as a kernel module, and collaborating with user-space components to complete device emulation. The KVM module supports the creation of various types of virtual machines, but it lacks a native mechanism for actively erasing residual data in memory; therefore, it needs to be combined with extended tables such as extended memory trace tables to achieve secure memory reuse.

[0027] Linux Kernel-based Virtual Machine (LKVM): A kernel virtual machine module based on the Linux kernel, which allows the Linux kernel to be transformed into a high-performance hypervisor, supporting the running of multiple isolated virtual machines on the same physical host.

[0028] In cloud computing applications, with the development of virtual machines, the requirements for data security in cloud-deployed virtual machine systems are increasing, especially the risk of sensitive data being tampered with or leaked during virtual machine operation. Therefore, there is an urgent need to introduce secure cloud application scenarios to eliminate distrust of virtual machine systems. Mainstream virtualization solutions run user workloads by creating an isolated and protected virtual machine, thereby ensuring that user data always runs in an isolated and protected environment, free from leakage and tampering. Virtual machines running in such isolated and protected environments are also called secure virtual machines.

[0029] Currently, mainstream virtual machine solutions are based on the kernel virtual machine module mechanism. The kernel virtual machine module dynamically allocates memory to the security virtual machine, and reclaims the memory once the virtual machine stops running. This means that the same memory may be repeatedly allocated to different virtual machines. This requires dynamic isolation and allocation management of virtual machine memory to ensure that the workload data of the security virtual machine is not leaked or tampered with due to memory issues. This requires a memory trace table isolation mechanism.

[0030] However, since the same physical memory block may be repeatedly allocated to different virtual machines, if the memory allocation status and data lifecycle are not effectively tracked, sensitive data remaining in released memory may be illegally accessed by subsequent virtual machines, leading to potential data leaks or tampering. Therefore, there is an urgent need for a virtual machine memory management method that can dynamically track and query physical memory information to ensure the reliability and traceability of memory data during the operation of secure virtual machines.

[0031] This specification provides a method for managing dynamic memory in a virtual machine. It also relates to a virtual machine system, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0032] See Figure 1 , Figure 1 The flowchart illustrates a method for managing dynamic memory in a virtual machine according to an embodiment of this specification. This method is applied to a virtual machine system and includes the following specific steps: Step 102: In response to the front end's memory query request for the target security virtual machine, determine the target physical memory block to be allocated to the target security virtual machine from the multiple physical memory blocks according to the security virtual machine to which it belongs, wherein the extended memory tracking table records the address information and the security virtual machine to which the corresponding physical memory block belongs.

[0033] A virtual machine system (VM) is a computing environment built on virtualization technology. It includes physical hardware resources (such as CPU and memory) and virtualization management components (such as a hypervisor and security modules) for creating, running, and managing multiple virtual machine instances. VM systems achieve resource isolation and sharing through hardware-assisted virtualization, support confidential computing technologies such as confidential virtualization extensions, and enhance memory and data protection mechanisms. VM systems include extended memory trace tables to dynamically track the physical memory state. For example, a VM system based on LKVM (Linux kernel virtual machine module) combines extended memory trace pages to achieve secure memory isolation.

[0034] The frontend, acting as a user-space component or client interface, is responsible for receiving and processing memory operation requests (such as memory allocation and queries) from users or other systems, and for sending instructions to the backend of the virtual machine system. As the interaction point between the user and the virtual machine system, the frontend provides an Application Programming Interface (API) or command-line tools. The frontend translates user requests into executable instructions for the virtual machine system (such as querying memory allocation for a specific security virtual machine). For example, a user might send a memory query request (EMTTQuery) to the kernel virtual machine module of the virtual machine system via a command-line tool.

[0035] A secure virtual machine (VM) is a virtual machine instance running in a confidential security domain. Its memory, CPU state, and I / O operations are protected by hardware-level encryption and isolation, allowing access only to authorized entities. Secure VMs rely on confidential virtualization extensions to achieve capabilities such as memory encryption and remote authentication. The physical memory allocation of a secure VM is linked to its unique identifier (such as a VM identifier) ​​through extended memory trace pages, ensuring traceability of physical memory block ownership. For example, in cloud computing scenarios, VM instances processing sensitive data are configured as secure VMs.

[0036] The target security virtual machine is the security virtual machine instance specified in the memory query request for which its memory allocation information needs to be obtained. The target security virtual machine serves as the object of the query operation. Its virtual machine identifier is used to filter information related to physical memory blocks in the extended memory trace page. The virtual machine system only returns information related to the physical memory blocks bound to that virtual machine, ensuring data isolation from other virtual machines. For example, a user requests a query for the memory allocation information of the security virtual machine with the ID "TVM-001".

[0037] A memory query request is a memory operation instruction initiated by the frontend for a target security virtual machine, used to obtain information about the currently allocated physical memory blocks of the specified security virtual machine. The memory query request contains the identifier of the target security virtual machine, triggering the virtual machine system to query the extended memory trace page and filter physical memory block records that meet the criteria. For example, the frontend calls the EMTT_Query(TVM_ID) interface and passes in a memory query request EMTTQuery carrying the identifier of the target security virtual machine "TVM-001".

[0038] A physical memory block is a contiguous or discrete storage unit in physical memory, serving as the basic unit for virtual machine memory allocation. Each physical memory block has a unique physical address, is dynamically allocated to virtual machines, and its associated security virtual machine and memory block status are recorded through an extended memory trace table. For example, a 4KB memory block with a physical address range of 0x1000 to 0x2000 might be allocated to the security virtual machine "TVM-001".

[0039] The extended memory trace table for physical memory blocks is an extended metadata structure that records the address information of physical memory blocks and the identifier of the security virtual machine to which they belong. The extended memory trace table adds security attributes and status fields to the traditional memory trace table, used for memory allocation decisions and security verification to prevent data residue across virtual machines.

[0040] The address information of physical memory blocks refers to the actual storage location of the physical memory blocks recorded in the extended memory trace table, represented by a range of physical addresses. Physical memory blocks are allocated by the kernel virtual machine module and recorded in the extended memory trace pages. The virtual machine accesses memory through a mapping between virtual and physical addresses. For example, physical addresses 0x5000 to 0x6000 correspond to the encrypted memory region of the secure virtual machine "TVM-001".

[0041] The security virtual machine to which a physical memory block belongs is the security virtual machine instance currently bound to the physical memory block, as recorded in the extended memory trace table, ensuring that the memory block is only accessed by the virtual machine to which it belongs. For example, the security virtual machine to which physical memory blocks 0x5000 to 0x6000 belong is "TVM-001".

[0042] The target physical memory block for the target security virtual machine is the physical memory block allocated to the target security virtual machine, determined by querying the extended memory trace page. The filtering criteria are that the security virtual machine in the extended memory trace page matches the target virtual machine identifier. The returned address information is used for front-end display or further operations (such as memory release). For example, querying the target physical memory block for "TVM-001" returns a list of addresses of its allocated 10 4KB memory blocks.

[0043] For example, in a RISC-V architecture cloud computing platform, three secure virtual machines (TVM-001, TVM-002, and TVM-003) run on the virtualization platform. Each secure virtual machine uses secure virtual extension technology to ensure the security and isolation of its data. An extended memory tracking table is maintained in the system to record the status of all physical memory blocks and their binding relationships with each secure virtual machine. A user wants to check the currently allocated physical memory of the secure virtual machine with ID "TVM-001," so they initiate a memory query request (EMTT_Query(TVM_ID)) to the kernel virtual machine module of the virtual machine system via a command-line tool, carrying the identifier "TVM-001" of the target secure virtual machine. Upon receiving the user's memory query request, the system parses the target secure virtual machine identifier "TVM-001." Based on this identifier, it searches the EMTT for the physical memory block marked as belonging to "TVM-001." The physical address range is 0x5000 to 0x6000, the status is allocated, and it belongs to TVM-001. Filter out all physical memory blocks marked TVM-001 from the above records.

[0044] In step 102, by extending the memory tracking table to record the security virtual machine field, the system can track the identity of the virtual machine to which each physical memory block belongs in real time. When responding to front-end queries, only the physical memory block addresses marked as belonging to the target security virtual machine are filtered out and fed back, ensuring that the virtual machine can only access the memory region bound to it and isolating the risk of cross-virtual machine queries.

[0045] Step 104: Obtain the address information recorded in the extended memory trace table of the target physical memory block and feed the address information back to the front end.

[0046] For example, based on the target physical memory blocks determined in the previous step (i.e., 0x5000~0x6000 and 0x7000~0x8000), the system obtains the detailed address information of these memory blocks. The obtained information is then packaged into a response message and sent back to the front end.

[0047] In the embodiments described in this specification, the system uses an extended memory tracking table to record the security virtual machine field, enabling real-time tracking of the virtual machine identity of each physical memory block. When responding to front-end queries, only physical memory block addresses marked as belonging to the target security virtual machine are filtered and fed back, ensuring that the virtual machine can only access the memory region bound to it, isolating the risk of cross-virtual machine queries. Simultaneously, the memory block status field, combined with address information, provides verification for memory allocation. When a physical memory block is released, the system can identify whether sensitive data remains based on the status marker and forcibly trigger an erasure process before reallocating it to other virtual machines, avoiding illegal access to uncleaned memory due to misjudgment of status. Through a dynamic query process, the address information obtained by the front-end is synchronized with the extended memory tracking table. Even if the same physical memory block is allocated multiple times, the system can, based on the real-time updated virtual machine identifier and memory status, block historical virtual machines from accessing reclaimed memory through residual addresses, ensuring the traceability of data lifecycle.

[0048] In one optional embodiment of this specification, step 102 includes the following specific steps: In response to a memory query request from the virtualization management interface, an extended memory trace table query request is initiated to the system permission management software through the virtual machine manager of the host operating system. Using system access control software, the target physical memory block corresponding to the target security virtual machine is determined based on the security virtual machine recorded in the extended memory tracking table. Correspondingly, step 104 includes the following specific steps: The system access control software collects the address information recorded in the extended memory trace table of the target physical memory block and feeds the address information back to the virtualization management interface through the virtual machine manager of the host operating system.

[0049] The virtualization management interface (VMI) is a management interface for a low-privilege virtual machine system running on the front end. It receives memory operation commands (such as memory allocation, querying, and deallocation) from users or upper-layer applications, converts the requests into a standard format, and forwards them to the host operating system's virtual machine manager. The VMI provides a command-line interface, a graphical interface, or an application programming interface (API) to trigger memory query processes and visualize the results. The VMI can parse the identifier of the target secure virtual machine input by the user and generate a memory query request carrying that identifier. The VMI passes the memory query request to the host operating system's virtual machine manager via inter-process communication or system calls. The VMI receives the query results returned by the host operating system's virtual machine manager, formats them, and outputs them to the front end. For example, the VMI runs in machine mode and has low privileges.

[0050] The host operating system's virtual machine manager is a medium-privilege virtualization management component running on the host operating system. It coordinates physical resource allocation, virtual machine lifecycle management, and security policy enforcement. As an intermediary between the virtualization management interface and the system access control software, the host operating system's virtual machine manager translates user-mode requests into hardware-level operations. The virtual machine manager receives and verifies memory operation requests (such as queries and allocations) from the virtualization management interface, triggers operations in the system access control software, maintains virtual machine metadata (such as TVM identifiers and memory mappings), ensures accurate request routing, and implements access control to restrict cross-virtual machine memory operations. For example, the host operating system's virtual machine manager may run in privileged mode, such as the HS mode in RISC-V, with medium privileges.

[0051] The system privilege management software is a high-privilege security firmware management software running on the processor. It has direct access to hardware resources and is responsible for maintaining extended memory trace pages and responding to memory query requests. The system privilege management software receives memory query requests from the virtual machine manager of the host operating system and parses the identifier of the target secure virtual machine. It then traverses the page table entries of the extended memory trace pages, filters out physical memory blocks whose identifiers match those of the target secure virtual machine, and generates an address list. For example, the system privilege management software runs in machine mode and has high privileges.

[0052] For example, in a RISC-V architecture cloud computing platform, users need to troubleshoot abnormal memory usage issues in the secure virtual machine "TVM-001". After logging into the host machine's management node, the virtualization management interface parses the secure virtual machine's ID and generates a standardized EMTT Query request. This request is then passed to the host operating system's virtual machine manager via a Unix domain socket. After verifying administrator privileges, the host operating system's virtual machine manager forwards the request to the system permission management software. The system permission management software accesses the hardware-protected extended memory trace pages, traverses all page table entries, selects the physical memory block with "PAGE_OWNER=TVM-001", and encapsulates the physical address range, memory type (TVM private memory), and allocation time (2025-07-01 14:30:00 UTC) into an encrypted data packet, which is then sent back to the virtualization management interface via the host operating system's virtual machine manager.

[0053] In the embodiments described in this specification, complex operations are encapsulated through a unified interface of the virtualization management interface to reduce management complexity. The virtual machine manager of the host operating system ensures the legitimacy of requests and the security of cross-level communication through permission verification and protocol conversion. The system permission management software relies on hardware-level protection mechanisms to implement anti-tampering query of extended memory tracking pages. The three work together to achieve physical memory status tracking and effectively block the risk of accessing historical data residues across virtual machines.

[0054] In one optional embodiment of this specification, the following specific steps are included before step 102: In response to the creation command of the target secure virtual machine, the target physical memory block is determined from multiple physical memory blocks based on the memory block status recorded in the extended memory trace table of multiple physical memory blocks, and the target physical memory block is dynamically allocated to the target secure virtual machine. Update the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory trace table.

[0055] The target secure virtual machine creation command is a request initiated by the front end to create a new secure virtual machine instance. This command contains basic configuration information for the secure virtual machine to be created, such as memory size and number of CPU cores, and specifies that the virtual machine must use secure virtual extension technology to ensure the security and isolation of its data. The creation command triggers a series of operations, including resource allocation, initialization, and setting necessary security attributes.

[0056] The physical memory block status is a marker recorded in the extended memory trace table describing the current security attributes of the physical memory block. The physical memory block status triggers the memory erase process to prevent data leaks during cross-virtual machine allocation. Changes in the physical memory block status trigger synchronous updates to the memory block status in the extended memory trace table. Examples include confidential or non-confidential memory.

[0057] For example, in a cloud computing environment based on RISC-V architecture, when an administrator decides to create a new secure virtual machine instance (e.g., with the ID "TVM-004"), the extended memory trace pages are traversed, physical memory blocks in the CLEANED state are filtered, and contiguous address spaces are prioritized to meet the allocation requirements of large pages (e.g., 2MB). The secure virtual machine field in the page table entry of the extended memory trace page of the selected memory block is set to "TVM-004", and the memory block status is marked as CONFIDENTIAL (confidential memory).

[0058] In the embodiments described in this specification, memory is dynamically allocated based on the physical memory block status recorded in the extended memory tracking table when the target secure virtual machine is created. The status of the relevant memory blocks and the identifier of the security virtual machine to which they belong are also updated. This ensures the secure allocation and management of memory resources. It not only effectively avoids the risk of data leakage between virtual machines, but also further strengthens the data protection mechanism by updating the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory tracking table. This ensures the confidentiality and integrity of sensitive information even when resources are reused, thereby enhancing the security and reliability of the entire virtual machine system.

[0059] In one optional embodiment of this specification, in response to a creation instruction for a target secure virtual machine, a target physical memory block is determined from multiple physical memory blocks based on the memory block status recorded in an extended memory trace table of multiple physical memory blocks, and the target physical memory block is dynamically allocated to the target secure virtual machine, including the following specific steps: In response to the creation command of the target secure virtual machine, the kernel virtual machine module in the virtual machine manager of the host operating system determines the target physical memory block from multiple physical memory blocks based on the memory block status recorded in the extended memory trace table of multiple physical memory blocks, and dynamically allocates the target physical memory block to the target secure virtual machine. Correspondingly, update the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory trace table, including the following specific steps: Update the memory block status and associated security virtual machine in the extended memory trace table of the target physical memory block using system access control software.

[0060] The host operating system's virtual machine manager is a virtualization management component running in privileged mode on the host machine (such as HS mode in RISC-V). It is used for physical resource pooling management, virtual machine lifecycle scheduling, and security policy arbitration. The host operating system's virtual machine manager can parse requests submitted by the virtualization management interface, verify operation permissions, maintain virtual machine metadata tables, coordinate with system permission management software to complete hardware-level memory isolation configuration, and implement access control to prevent out-of-bounds operations across virtual machine resources.

[0061] The kernel virtual machine module is integrated into the host operating system's virtualization driver module (such as KVM), providing a complete virtualization function stack and supporting features such as device emulation, interrupt virtualization, and nested memory paging. The kernel virtual machine module can be a Linux kernel virtual machine module, specifically designed for the Linux kernel, and it completes secure memory allocation through interaction with system permission management software.

[0062] For example, when an administrator initiates a creation command to create the target secure virtual machine "TVM-004" via the command-line interface or management platform, a memory allocation request is first initiated through the Linux kernel virtual machine module in the secure virtual machine manager software. Based on the memory specifications of the target virtual machine (e.g., 4GB of encrypted memory), the secure virtual machine manager software initiates a physical memory block allocation request to the system permission management software, simultaneously triggering a memory security attribute conversion process. During this process, the system permission management software traverses the Extended Memory Tracking Table (EMTT) and the Memory Tracking Table (MTT), filtering out physical memory blocks with a status of "..." that are not bound to any secure virtual machine. For eligible memory blocks, the system access control software will perform the following key operations: First, it will rebind the selected memory block using a hardware encryption engine, associating it with the target secure virtual machine's exclusive key. Second, it will update the metadata of the corresponding memory block in the extended memory tracking table, setting the associated secure virtual machine field to "TVM-004" and marking the memory block status as confidential memory (CONFIDENTIAL). Finally, it will configure the Hypervisor Guest Address Translation and Protection (HGATP) page table to establish a secure mapping between the target virtual machine's virtual address and physical address, ensuring that subsequent memory access requires security domain permission verification. It should be noted that this includes not only workload memory allocation but also dynamic management of the security metadata storage area. The memory space required by the secure virtual machine context control block (TVMC Context) will be allocated from the reserved protected area, and its physical address will be marked as "super domain exclusive" in the extended memory tracking table, prohibiting unauthorized virtual machines from accessing it. Meanwhile, the context switching buffer between the super domain and the normal security domain will also implement dual state tracking by extending the memory tracking table—recording both the security domain identifier to which the memory block belongs and tracking its current load data type.

[0063] In the embodiments described in this specification, this mechanism ensures that even when the same physical memory block is reclaimed and reassigned to different security virtual machines, the system can still forcibly trigger memory allocation before allocation based on the complete lifecycle information recorded in the extended memory trace table, thereby enhancing data security, achieving efficient resource management, and strengthening access control and isolation.

[0064] In one optional embodiment of this specification, the following specific steps are included before step 102: In response to the virtual machine system's startup command, the host machine's physical memory is divided into multiple physical memory blocks, and an extended memory trace table is built for each physical memory block.

[0065] The virtual machine system's startup command is a hardware resource initialization command triggered during host machine initialization. This command reads firmware configuration parameters to determine the physical memory partitioning strategy and security domain configuration scheme, establishing the basic virtualization runtime environment. The startup command includes key parameters such as memory block granularity (e.g., 4KB / 2MB) and reserved area settings (e.g., security metadata storage area) to ensure the synchronized construction of the extended memory trace table and the physical memory layout.

[0066] The host machine's physical memory is a set of raw memory resources provided by the hardware layer, and its address space is uniquely identified by physical addresses. During the virtual machine system startup phase, physical memory is re-partitioned into storage units that meet the isolation requirements of virtualization. Each unit is tracked throughout its entire lifecycle through an extended memory trace table. Physical memory partitioning follows hardware platform specifications (such as the RISC-V Sv48 paging standard) to ensure atomic configuration of address alignment and access permissions.

[0067] For example, in a RISC-V architecture virtual machine system, the address space from 0x80000000 to 0xFFFFFFFFFFFFFFFF is divided into contiguous physical memory blocks according to the total physical memory capacity of the host machine (e.g., 256GB) and the preset block partitioning strategy (4KB). Then, an extended memory trace table entry is created for each memory block, with the initial state marked as UNASSIGNED (unallocated) and the security virtual machine field of the block being set to null.

[0068] In the embodiments described in this specification, a secure and controllable underlying foundation for dynamic memory allocation is established through physical memory pre-partitioning and extended memory tracking table initialization during the system startup phase. The lifecycle of each physical memory block is incorporated into the tracking system from creation, and its state changes and the binding relationship with its virtual machine are all subject to mandatory hardware verification. This effectively prevents the risk of memory mapping leaks or out-of-bounds access during the startup phase, ensuring not only the traceability of memory resources but also providing atomic and verifiable memory allocation units for the subsequent dynamic creation of secure virtual machines.

[0069] In one optional embodiment of this specification, in response to the virtual machine system's startup command, the host machine's physical memory is divided into multiple physical memory blocks, and an extended memory trace table is built for each physical memory block, including the following specific steps: In response to the virtual machine system's startup command, the system permission management software guides the secure virtual machine manager software, which divides the host machine's physical memory into multiple physical memory blocks and builds an extended memory trace table for each physical memory block.

[0070] For example, in a RISC-V architecture cloud computing platform, upon system startup, the system access management software guides the secure virtual machine manager software to divide the host machine's physical memory into contiguous physical memory blocks based on the total physical memory capacity (e.g., 256GB) and a preset 4KB block granularity. The address range is from 0x80000000 (starting address) to 0xFFFFFFFFFFFFFFFF, with each memory block being 4KB in size. Each physical memory block corresponds to an extended memory tracking table containing the following fields: physical address range (e.g., 0x80000000~0x80000FFF); the associated secure virtual machine identifier (initially NULL); and the memory block status: NON-CONFIDENTIAL (initially unencrypted memory). The base address register of the extended memory tracking table (e.g., EMTT_BASE=0x10000000) and access key are set, allowing only the system access management software to modify table entries via a hardware authentication protocol. The area containing EMTT is configured to be machine-only readable and writable, preventing tampering by virtual machines or user-space software.

[0071] In the embodiments described in this specification, the partitioning of memory blocks and the construction of extended memory trace pages are completed by hardware-protected system permission management software during the startup phase, ensuring the integrity of the physical memory layout and trace table, and avoiding out-of-bounds access or metadata tampering caused by software-level vulnerabilities. Each memory block is recorded by the extended memory trace page from system startup, and subsequent operations such as allocation, release, and encryption status changes must be updated through hardware verification, forming a closed-loop full lifecycle trace mechanism.

[0072] In one optional embodiment of this specification, after constructing an extended memory trace table for each physical memory block, the following specific steps are further included: To expand the memory trace table configuration register set, the register set includes an address register and an attribute configuration register. The address register stores the address information of the physical memory block, and the attribute configuration register stores the memory block status and the security virtual machine to which the physical memory block belongs. After updating the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory trace table, the following specific steps are also included: Update the memory block status and the security virtual machine to which the target physical memory block belongs, which is stored in the attribute configuration register of the register group.

[0073] The register set is a collection of hardware registers that accompany the extended memory trace table. It includes address registers, attribute configuration registers, and control registers, used to store real-time status information of physical memory blocks and control query behavior. The register set employs hardware protection mechanisms to ensure its contents can only be accessed by system access control software, preventing tampering at the user space or virtual machine level. For example, in the RISC-V architecture, the register set contains three core registers: the address register (EMTT_CFG): stores the page address of the physical memory block to be queried (e.g., 0x80001000); the attribute configuration register (EMTT_INFO): stores the type of the memory block (confidential / non-confidential), the identifier of the associated security virtual machine (e.g., TVM-001), and metadata (e.g., allocation timestamp); and the control register (EMTT_CTRL): controls the query mode (by page or by raw address) and its enabled state.

[0074] The control register, located in the register bank, is used to configure the extended memory trace table lookup function. It includes mode selection (page-by-page or physical address-by-physical-address lookup), a lookup enable flag, and a status feedback bit. The control register is accessed via privileged instructions and can only be modified under machine mode, the highest level of privilege. For example, in a virtual machine system debugging scenario, an administrator can activate the page-by-page lookup mode by writing `Enable=1` and `Mode=page` to the control register, and then poll the `Status` bit until it is ready, triggering an extended memory trace table lookup for the specified page address.

[0075] The address register is a dedicated register in the register bank that stores the address of the physical memory block to be queried. Its value is written by the system access control software to specify the target of the extended memory trace table query. The address register must meet address alignment requirements (e.g., 4KB alignment), otherwise a hardware exception will be triggered. For example, when it is necessary to query the status of the memory block corresponding to physical address 0x90000000, the system access control software writes 0x90000000 to the address register (EMTT_CFG.PAGE_PA), and then triggers the query process.

[0076] The attribute configuration register is a register in the register group that stores the security attributes and ownership information of physical memory blocks. Its fields include memory type (confidential / unconfidential), the identifier of the owning security virtual machine, and metadata checksum. The contents of the attribute configuration register are updated by the system permission management software when memory is allocated or released. For example, after the security virtual machine "TVM-002" releases physical address 0xA0000000, the system permission management software sets the owning security virtual machine field in the attribute configuration register to empty, marks the memory type as "to be erased," and generates a metadata checksum to prevent tampering.

[0077] For example, in a RISC-V architecture virtual machine system, each physical memory block's extended memory trace table corresponds to a set of hardware registers. The address register (e.g., EMTT_CFG) is used to set the physical address of the memory block to be queried (e.g., 0x80001000), while the attribute configuration register (e.g., EMTT_INFO) stores the confidential status (e.g., CONFIDENTIAL), the security virtual machine identifier (e.g., TVM-001), and the allocation timestamp of the memory block corresponding to that address. When the target memory block is allocated to a security virtual machine, the system access control software writes the new virtual machine identifier to the security virtual machine field of the attribute configuration register, updates the memory block status to confidential memory (CONFIDENTIAL), and simultaneously ensures the consistency between the register set and the extended memory trace table through memory barrier instructions.

[0078] In the embodiments described in this specification, atomicity and hardware-level protection of memory state changes are achieved by configuring a hardware register set for the extended memory tracking table. The address register and attribute configuration register of the register set are directly associated with the real-time state of the physical memory blocks, ensuring that memory allocation, release, and query operations are subject to permission verification by the system permission management software, preventing unauthorized tampering at the user space or virtual machine level. Simultaneously, the coordination between the register set and the control register ensures that updates to the memory tracking table and hardware cache refreshes are completed synchronously, eliminating potential state delays or concurrency conflicts in traditional software tracing mechanisms.

[0079] In one optional embodiment of this specification, an extended memory trace table is constructed for each physical memory block, including the following specific steps: Build a memory trace table and an extended memory trace table for each physical memory block, and associate the page table entries of the memory trace table and the extended memory trace table. The memory trace table records the security access permissions for the corresponding physical memory block.

[0080] It should be noted that the memory trace table can conform to the Confidential Virtualization Extended Page Table Entry Specification. The page table entry definition of the extended memory trace table is not restricted, but it must include the information in the attribute register.

[0081] For example, during the system startup phase, the system access control software divides the host machine's physical memory into 4KB granularities and creates both a Memory Tracking Table (MTT) entry and an Extended Memory Tracking Table (EMTT) entry for each memory block. The MTT entry records whether the memory block has been allocated (e.g., ALLOCATED / FREE), while the EMTT entry records security attributes (e.g., NON-CONFIDENTIAL / CONFIDENTIAL) and the identifier of the security virtual machine to which it belongs. The two are associated through the page number (PPN) of the physical address. For instance, the MTT entry index corresponding to physical address 0x80001000 is 0x1000, and its EMTT entry index is mapped to 0x2000 using a hash algorithm, ensuring that information in the other table can be quickly retrieved through either entry.

[0082] In the embodiments described in this specification, a decoupled management of basic memory state and security attributes is achieved by simultaneously constructing a Memory Tracking Table (MTT) and an Extended Memory Tracking Table (EMTT) for each physical memory block and establishing a bidirectional index association between the two. The MTT focuses on the allocation state of physical memory blocks, while the EMTT strengthens the tracking of security attributes; the two are linked. During memory allocation, the system first filters free memory blocks through the MTT, and then verifies whether their historical state meets the security policy (such as whether residual data has been erased) through the EMTT. This design decouples resource allocation efficiency from security verification, avoiding the performance overhead of traversing the entire table while ensuring the data security of data reused across virtual machine memory.

[0083] In one optional embodiment of this specification, the method further includes the following specific steps: In the event of a system anomaly in the virtual machine system, the address information of the target physical memory block is read from the address register of the register group, the memory block status and the security virtual machine to which the target physical memory block belongs are read from the attribute register of the register group, and the address information and the security virtual machine to which the target physical memory block belongs are fed back to the front end.

[0084] System exceptions in a virtual machine system are events that violate memory safety policies or hardware rules, including but not limited to: memory access out of bounds: the virtual machine attempts to read or write an unallocated physical address; double free error: the same physical memory block is freed multiple times, resulting in inconsistent states; unauthorized encrypted memory access: an insecure virtual machine accesses a memory region marked as confidential; hardware verification failure: memory block metadata (such as ECC checksum) does not match the records in the extended memory trace table.

[0085] For example, when the secure virtual machine "TVM-005" attempts to write to physical address 0xC0000000, the system permission management software detects that the address is marked as "TVM-006" in the extended memory trace table (with a state of CONFIDENTIAL), immediately triggers an exception interrupt, locks the exception address to the address register (EMTT_CFG.PAGE_PA=0xC0000000), reads the actual owner virtual machine identifier (TVM-006) and memory state (CONFIDENTIAL) from the attribute configuration register (EMTT_INFO), generates an exception log, and freezes the operation of "TVM-005" to prevent data tampering from spreading.

[0086] In the embodiments described in this specification, the register group serves as the hardware interface for the extended memory tracking table. Through the collaboration of address registers, attribute configuration registers, and control registers, it enables atomic operations for memory state changes. When an abnormal system event is detected, the system access control software locks the abnormal memory block through the address register, extracts its owner virtual machine and security status from the attribute configuration register, and generates an encrypted log. This mechanism supports nanosecond-level threat blocking and precise source tracing. Simultaneously, by directly reading register information during system crashes through the debugging interface, it quickly locates the source of the problem, forming a closed-loop defense system of real-time blocking and offline auditing.

[0087] In one optional embodiment of this specification, the register set of the extended memory trace table further includes a control register; In the event of a system anomaly in the virtual machine system, the address information of the target physical memory block is read from the address register of the register set, and the memory block status and the security virtual machine to which the target physical memory block belongs are read from the attribute register of the register set. This includes the following specific steps: In the event of a system anomaly in the virtual machine system, a query enable instruction is written to the control register through the debug interface to trigger the query function of the extended memory trace page. If the status bit of the control register confirms that the query function is activated, the address information of the target physical memory block is read from the address register of the register group, and the memory block status and the security virtual machine to which the target physical memory block belongs are read from the attribute register of the register group.

[0088] The debug interface (such as JTAG) provides a hardware-level debugging channel for virtual machine systems. It allows direct access to register sets and extended memory trace tables to perform memory status tracing and repair operations when the system crashes or privileged software becomes unavailable. Access to the debug interface requires physical contact or pre-configured key authentication. For example, when the host machine crashes due to out-of-bounds memory access, maintenance personnel can connect to a physical device via JTAG, bypass the operating system, directly read control registers and attribute configuration registers, locate the virtual machine (such as TVM-003) to which the abnormal memory block belongs, and trigger a forced erase.

[0089] For example, after the virtual machine system enters debug mode due to a double free error triggered by the security virtual machine "TVM-003", the maintenance personnel connect to the host machine through the JTAG interface, write EMTT_CTRL.Enable=1 and Mode=page to the control register to activate the page lookup function. After the status bit changes to READY, the abnormal memory page address 0xA0000000 is written to EMTT_CFG.PAGE_PA. The EMTT_INFO register reads that the security virtual machine to which the page belongs is "TVM-004". Since the memory has not been erased, it is determined that this is a risk of cross-virtual machine memory residue. The forced erase instruction is manually triggered and the extended memory trace entry is rebuilt.

[0090] In the embodiments described in this specification, hardware-level linkage between the debug interface and control registers ensures that the system can accurately trace the ownership and state of abnormal memory in the event of a crash or privileged software failure, quickly locate residual memory blocks, and trigger erasure, avoiding reliance on complex software stack recovery processes. This mechanism not only enhances the system's fault tolerance but also provides an immutable chain of evidence for root cause analysis of security incidents through hardware-mandated isolation and log auditing, meeting the compliance requirements of high-security scenarios.

[0091] Figure 2 This specification illustrates a hardware and software diagram of a virtual machine system in an embodiment of a virtual machine dynamic memory management method. Figure 2 As shown: The host management domain includes: The Linux kernel virtual machine module is used to manage and schedule Linux virtual machines. The host operating system's virtual machine manager is used to manage all virtual machine instances on the host machine, including resource allocation and scheduling.

[0092] Confidential security domains include: Secure Virtual Machine-1 and Secure Virtual Machine-2: Virtual machine instances running in a confidential security domain, offering enhanced security and isolation.

[0093] Secure Virtual Machine Manager Software: Software specifically designed to manage secure virtual machines, ensuring the security and isolation of their data.

[0094] Perform the following steps on the system access control software: Step 1: System startup initialization: The system performs initialization operations during startup to prepare for subsequent memory management and virtual machine creation.

[0095] Step 2: Secure Virtual Machine Construction: Locate available physical memory blocks based on the extended memory trace table, and dynamically allocate the found physical memory blocks to the target secure virtual machine.

[0096] Step 3: Software query: Receive memory query requests from the front end for the target security virtual machine.

[0097] Step 4: Hardware Query: In response to the front end's memory query request for the target security virtual machine, based on the security virtual machine to which it belongs as recorded in the extended memory tracking table of multiple physical memory blocks, determine the target physical memory block allocated to the target security virtual machine from the multiple physical memory blocks, obtain the address information recorded in the extended memory tracking table of the target physical memory block, and feed the address information back to the front end.

[0098] The memory trace table records the basic allocation status of the corresponding physical memory block, the extended memory trace table records the security attributes and lifecycle status of the corresponding physical memory block, and the register set of the extended memory trace table contains the register set used to record the memory block status and security attributes, ensuring the secure allocation and erasure of memory blocks between different virtual machines.

[0099] Figure 3 This specification illustrates a schematic diagram of a register group in a virtual machine dynamic memory management method according to an embodiment of this specification, as shown below. Figure 3 As shown: The register set contains: Page address register: Stores the base address of the extended memory trace page, pointing to the physical storage location of the memory trace table; Control register: Configures the polling mode (page-by-page or physical address) and its enable status, and controls the operation permissions of the extended memory trace table; Address register: Records the address information of the physical memory block to be queried, and must meet alignment requirements; Attribute register: Stores security metadata of the memory block, including the security virtual machine identifier, memory type (confidential / non-confidential), parent object association information, and erase status flag.

[0100] The register bank is bound to the system access control software through hardware protection mechanisms to ensure the atomicity of memory status queries and updates. The overall layout adopts a layered design with clear information classification and separation of operation instructions and status feedback, supporting efficient and secure memory management.

[0101] Figure 4 This specification illustrates a flowchart of a method for managing dynamic memory in a virtual machine according to an embodiment of the present invention. Figure 4 As shown: The workflow framework of the virtual machine dynamic memory management method includes the following core components: Secure virtual machine manager software: responsible for configuring extended memory tracking tables and coordinating virtual machine resource allocation; System access control software: Creates and maintains extended memory tracking tables and executes hardware-level security policies; Extended memory trace table: records the virtual machine to which the physical memory block belongs, its security status, and its lifecycle information, and dynamically associates it with the page table to achieve a secure mapping from virtual addresses to physical addresses; Memory trace table: Stores the basic allocation status of memory blocks, and is associated with the extended memory trace table through an index to form a two-layer verification mechanism; Register set: Serves as the hardware interface for the extended memory trace table, storing real-time status and controlling query operations.

[0102] The diagram illustrates a "configuration-creation-association" process that enables collaboration between the secure virtual machine manager software and the system permission management software, ensuring secure control over the entire process of memory allocation, access, and reclamation. The overall structure is clearly hierarchical, demonstrating deep integration of hardware and software.

[0103] Although the solutions in the above embodiments are illustrated using a RISC-V architecture processor, the processor architecture is not limited. The execution logic of the above data processing method can also be implemented in processor architectures such as x86 and ARM, and is not limited here.

[0104] Corresponding to the above method embodiments, this specification also provides virtual machine system embodiments. Figure 5 A schematic diagram of the structure of a virtual machine system provided in one embodiment of this specification is shown. Figure 5 As shown, the virtual machine system 500 includes a virtualization management interface module 510, a virtual machine manager of the host operating system 520, and a system permission management software module 530. The virtualization management interface module 510 is used to initiate an extended memory trace table query request to the system permission management software module through the virtual machine manager 520 of the host operating system; The system permission management software module 530 is used to determine the target physical memory block corresponding to the target security virtual machine based on the security virtual machine recorded in the extended memory tracking table, collect the address information recorded in the extended memory tracking table of the target physical memory block, and feed the address information back to the virtualization management interface module 510 through the virtual machine manager 520 of the host operating system.

[0105] In one optional embodiment of this specification, the system permission management software module 530 is used to divide the host machine's physical memory into multiple physical memory blocks in response to the virtual machine system's startup command, and to build an extended memory tracking table for each physical memory block; In one optional embodiment of this specification, the virtual machine system 500 further includes a secure virtual machine manager software module 540; The security virtual machine manager software module 540 is used to respond to the creation command of the target security virtual machine, determine the target physical memory block from multiple physical memory blocks according to the memory block status recorded in the extended memory trace table of multiple physical memory blocks, and dynamically allocate the target physical memory block to the target security virtual machine. The system permission management software module 530 is also used to update the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory trace table; In one optional embodiment of this specification, the system permission management software module 530 is further configured to, upon detecting a system abnormal event in the virtual machine system, write a query enable instruction to the control register in the register group of the extended memory trace table through the debugging interface, triggering the query function of the extended memory trace page; if the status bit of the control register confirms that the query function has been activated, read the address information of the target physical memory block from the address register of the register group, read the memory block status and the security virtual machine to which the target physical memory block belongs from the attribute register of the register group, and feed back the address information and the security virtual machine to the virtual machine manager 520 of the host operating system to the virtualization management interface module 510.

[0106] In the embodiments described in this specification, the front end initiates an operation command, which is verified by the virtual machine manager of the host operating system and then forwarded to the system permission management software. The system permission management software completes memory allocation or query based on the extended memory tracking table and ensures isolation through the secure virtual machine manager. The virtual machine system achieves secure management of the entire memory lifecycle through hierarchical permission control and hardware-level state synchronization.

[0107] The above is an illustrative scheme of a virtual machine system according to this embodiment. It should be noted that the technical solution of this virtual machine system and the technical solution of the above-described virtual machine dynamic memory management method belong to the same concept. For details not described in detail in the technical solution of the virtual machine system, please refer to the description of the technical solution of the above-described virtual machine dynamic memory management method.

[0108] Figure 6A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0109] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0110] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0111] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0112] The processor 620 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the above-described virtual machine dynamic memory management method.

[0113] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described virtual machine dynamic memory management method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described virtual machine dynamic memory management method.

[0114] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described virtual machine dynamic memory management method.

[0115] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the virtual machine dynamic memory management method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the virtual machine dynamic memory management method described above.

[0116] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described virtual machine dynamic memory management method.

[0117] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described virtual machine dynamic memory management method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described virtual machine dynamic memory management method.

[0118] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0119] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0120] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0121] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0122] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for managing dynamic memory in a virtual machine, applied to a virtual machine system, comprising: In response to a memory query request from the front end for the target security virtual machine, the target physical memory block to be allocated to the target security virtual machine is determined from the multiple physical memory blocks according to the security virtual machine to which it belongs, as recorded in the extended memory tracking table of multiple physical memory blocks. The extended memory tracking table records the address information and the security virtual machine to which the corresponding physical memory block belongs. Obtain the address information recorded in the extended memory tracking table of the target physical memory block, and feed the address information back to the front end.

2. The method according to claim 1, wherein in response to a memory query request from the front end for the target security virtual machine, determining the target physical memory block allocated to the target security virtual machine from the plurality of physical memory blocks according to the security virtual machine recorded in the extended memory tracking table of the plurality of physical memory blocks includes: In response to a memory query request from the virtualization management interface, an extended memory trace table query request is initiated to the system permission management software through the virtual machine manager of the host operating system. The system permission management software determines the target physical memory block corresponding to the target security virtual machine based on the security virtual machine recorded in the extended memory tracking table. Obtain the address information recorded in the extended memory trace table of the target physical memory block, and feed the address information back to the front end, including: The system permission management software collects the address information recorded in the extended memory trace table of the target physical memory block, and feeds the address information back to the virtualization management interface through the virtual machine manager of the host operating system.

3. The method according to claim 1, further comprising, before determining the target physical memory block allocated to the target security virtual machine from the plurality of physical memory blocks according to the security virtual machine to which it belongs, based on the extended memory tracking table of the plurality of physical memory blocks, in response to a memory query request from the front end for the target security virtual machine: In response to the creation instruction of the target secure virtual machine, the target physical memory block is determined from the multiple physical memory blocks according to the memory block status recorded in the extended memory tracking table of the multiple physical memory blocks, and the target physical memory block is dynamically allocated to the target secure virtual machine; Update the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory trace table.

4. The method according to claim 3, wherein in response to the creation instruction of the target secure virtual machine, determining the target physical memory block from the plurality of physical memory blocks according to the memory block status recorded in the extended memory tracking table of the plurality of physical memory blocks, and dynamically allocating the target physical memory block to the target secure virtual machine, comprises: In response to the creation command of the target secure virtual machine, the kernel virtual machine module in the virtual machine manager of the host operating system determines the target physical memory block from the multiple physical memory blocks according to the memory block status recorded in the extended memory tracking table of the multiple physical memory blocks, and dynamically allocates the target physical memory block to the target secure virtual machine. The process of updating the memory block status and associated security virtual machine in the extended memory trace table of the target physical memory block includes: The system access control software updates the memory block status and associated security virtual machine in the extended memory tracking table of the target physical memory block.

5. The method of claim 1, further comprising, before determining the target physical memory block allocated to the target security virtual machine from the plurality of physical memory blocks according to the security virtual machine to which it belongs, based on the extended memory tracking table of the plurality of physical memory blocks, in response to a memory query request from the front end for the target security virtual machine: In response to the virtual machine system's startup command, the host machine's physical memory is divided into multiple physical memory blocks, and an extended memory trace table is built for each physical memory block.

6. The method according to claim 5, wherein responding to the virtual machine system's startup instruction, dividing the host machine's physical memory into multiple physical memory blocks and constructing an extended memory tracking table for each physical memory block includes: In response to the virtual machine system's startup command, the system permission management software guides the secure virtual machine manager software, which divides the host machine's physical memory into multiple physical memory blocks and builds an extended memory trace table for each physical memory block.

7. The method of claim 5, further comprising, after constructing the extended memory trace table for each physical memory block: Configure a register set for the extended memory tracking table, wherein the register set includes an address register and an attribute configuration register, the address register stores the address information of the physical memory block, and the attribute configuration register stores the memory block status and the security virtual machine to which the physical memory block belongs; After updating the memory block status and associated security virtual machine in the extended memory trace table of the target physical memory block, the following steps are also included: Update the memory block status and the security virtual machine to which the target physical memory block belongs, stored in the attribute configuration register of the register group.

8. The method according to claim 5, wherein constructing an extended memory trace table for each physical memory block comprises: A memory trace table and an extended memory trace table are constructed for each physical memory block, and the page table entries of the memory trace table and the extended memory trace table are associated. The memory trace table records the security access permissions of the corresponding physical memory block.

9. The method according to any one of claims 1-8, further comprising: In the event of a system anomaly in the virtual machine system, the address information of the target physical memory block is read from the address register in the register group of the extended memory trace table, the memory block status and the security virtual machine to which the target physical memory block belongs are read from the attribute register of the register group, and the address information, the memory block status and the security virtual machine to which the target physical memory block belongs are fed back to the front end.

10. The method of claim 9, wherein the register set of the extended memory trace table further includes a control register; In the event of a system anomaly in the virtual machine system, the step of reading the address information of the target physical memory block from the address register of the register group, and reading the memory block status and the security virtual machine to which the target physical memory block belongs from the attribute register of the register group, includes: In the event of a system anomaly in the virtual machine system, a query enable instruction is written to the control register through the debugging interface to trigger the query function of the extended memory trace page. If the status bit of the control register confirms that the query function is activated, the address information of the target physical memory block is read from the address register of the register group, and the memory block status and the security virtual machine to which the target physical memory block belongs are read from the attribute register of the register group.

11. A virtual machine system, comprising a virtualization management interface module, a virtual machine manager of a host operating system, and a system permission management software module; The virtualization management interface module is used to initiate an extended memory tracking table query request to the system permission management software module through the virtual machine manager of the host operating system; The system permission management software module is used to determine the target physical memory block corresponding to the target security virtual machine based on the security virtual machine recorded in the extended memory tracking table, collect the address information recorded in the extended memory tracking table of the target physical memory block, and feed the address information back to the virtualization management interface module through the virtual machine manager of the host operating system.

12. The virtual machine system according to claim 11, wherein the system permission management software module is configured to, in response to the startup command of the virtual machine system, divide the physical memory of the host machine into multiple physical memory blocks and construct an extended memory tracking table for each physical memory block.

13. The virtual machine system according to claim 11 further includes a secure virtual machine manager software module; The secure virtual machine manager software module is used to respond to the creation instruction of the target secure virtual machine, determine the target physical memory block from the multiple physical memory blocks according to the memory block status recorded in the extended memory tracking table of the multiple physical memory blocks, and dynamically allocate the target physical memory block to the target secure virtual machine; The system permission management software module is also used to update the memory block status and the security virtual machine to which the target physical memory block belongs in the extended memory tracking table.

14. In the virtual machine system according to claim 11, the system permission management software module is further configured to, upon detecting a system abnormal event of the virtual machine system, write a query enable instruction to the control register in the register group of the extended memory trace table through a debugging interface to trigger the query function of the extended memory trace page; if the status bit of the control register confirms that the query function has been activated, read the address information of the target physical memory block from the address register of the register group, read the memory block status and the security virtual machine to which the target physical memory block belongs from the attribute register of the register group, and feed back the address information, the memory block status, and the security virtual machine to the virtual machine manager of the host operating system to the virtualization management interface module.

15. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 10.

Images