Memory access device, memory access method, and processor

Abstract

The application provides a memory access device, a memory access method and a processor. The memory access device comprises a permission prediction unit, an address conversion unit and a pre-decoding module. The pre-decoding module is configured to synchronously acquire a memory access instruction in a decoding stage of an instruction execution pipeline, determine a target virtual address and an operation type based on the memory access instruction, determine a memory domain identifier based on the target virtual address and the operation type, generate a permission check request based on the target virtual address, the operation type and the memory domain identifier, and send the permission check request to the permission prediction unit and the address conversion unit. The permission prediction unit is configured to determine whether the memory access instruction satisfies an access condition based on the operation type and the memory domain identifier, and generate a permission prediction result based on a determination result. The address conversion unit is configured to traverse a two-level page table based on the target virtual address to obtain a host physical address, and generate an address conversion result based on the host physical address.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of memory access technology, and in particular to a memory access device, a memory access method, and a processor. Background Technology

[0002] In related technologies, memory virtualization under the RISC-V architecture often employs a two-level page table traversal mechanism. The guest memory management unit performs the translation from guest virtual address to guest physical address, while the host memory management unit performs the translation from guest physical address to host physical address. The entire process is serial, with address translation and permission verification executed sequentially, resulting in high memory access latency, large exception handling overhead, and significant performance fluctuations, failing to fully utilize hardware parallelism. Summary of the Invention

[0003] This application provides a memory access device, a memory access method, and a processor.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a memory access device, which includes a permission prediction unit, an address translation unit, a two-level page table, and a pre-decoding module. The pre-decoding module is configured to: synchronously acquire a memory access instruction during the decoding stage of the instruction execution pipeline; determine a target virtual address and operation type based on the memory access instruction; determine a memory domain identifier based on the target virtual address and the operation type; generate a permission verification request based on the target virtual address, the operation type, and the memory domain identifier, and send it to the permission prediction unit and the address translation unit; the permission prediction unit is configured to: determine whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and generate a permission prediction result based on the determination result; the address translation unit is configured to: traverse the two-level page table based on the target virtual address to obtain the host physical address, and generate an address translation result based on the host physical address.

[0005] This application provides a memory access method applied to a memory access device. The memory access device includes a permission prediction unit, an address translation unit, a pre-decoding module, and a two-level page table. The method includes: the pre-decoding module synchronously acquiring a memory access instruction during the decoding stage of the instruction execution pipeline; determining a target virtual address and an operation type based on the memory access instruction; determining a memory domain identifier based on the target virtual address and the operation type; generating a permission verification request based on the target virtual address, the operation type, and the memory domain identifier and sending it to the permission prediction unit and the address translation unit; the permission prediction unit determining whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and generating a permission prediction result based on the determination result; and the address translation unit traversing the two-level page table based on the target virtual address to obtain the host physical address, and generating an address translation result based on the host physical address.

[0006] In this embodiment, the pre-decoding module synchronously extracts memory access instructions during the instruction decoding stage, parses the target virtual address and operation type from the instructions, determines the memory domain identifier based on the operation type and target virtual address, and generates a permission verification request containing the target virtual address, operation type, and memory domain identifier. This request is then sent in parallel to the permission prediction unit and the address translation unit. The permission prediction unit performs permission judgment based on the operation type and memory domain identifier, quickly determining whether the access meets preset access conditions, thereby filtering illegal access in advance. The address translation unit initiates a two-level page table traversal based on the target virtual address, realizing the mapping from the client virtual address to the host physical address. Thus, by initiating parallel processing of permission prediction and address translation during the instruction decoding stage, the structural delay caused by serial execution in related technologies is resolved, significantly improving memory access efficiency. Simultaneously, the permission prediction unit does not rely on specific page table entries, performing rapid judgment only based on the operation type and memory domain identifier, reducing hardware resource consumption and improving response speed. Attached Figure Description

[0007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0008] Figure 1 A schematic diagram of the composition structure of a memory access device provided in an embodiment of this application. Figure 1 ; Figure 2 A schematic diagram of the composition structure of a memory access device provided in an embodiment of this application. Figure 2 ; Figure 3 A schematic diagram of the composition structure of a memory access device provided in an embodiment of this application. Figure 3 ; Figure 4 A schematic diagram of the composition structure of a memory access device provided in an embodiment of this application. Figure 4 ; Figure 5 A schematic diagram illustrating the implementation flow of a memory access method provided in an embodiment of this application; Figure 6 A schematic diagram of a two-level nested page table structure and hardware register group configuration architecture provided in this application embodiment; Figure 7 A schematic diagram illustrating parallel extraction and request vector generation during the instruction decoding stage, provided in an embodiment of this application; Figure 8 This application provides a schematic diagram of a parallel execution process for permission prediction and address translation, as illustrated in an embodiment of the present application. Figure 9 A schematic diagram of an abnormal aggregation and page fault preloading process provided in an embodiment of this application; Figure 10 This is a schematic diagram of the composition structure of a processor provided in an embodiment of this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0011] It should be noted that the terms "first, second, and third" used in the embodiments of this application are merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0012] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this application pertain. It should also be understood that terms such as those defined in general dictionaries should be understood to have a meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0013] In related technologies, hardware virtualization under the RISC-V architecture employs a serial two-level address translation and recursive trap mechanism, resulting in high memory access latency, large exception handling overhead, and significant performance fluctuations, failing to fully utilize hardware parallelism. To address these issues, this application uses a pre-decoding module to synchronously extract memory access instructions during the instruction decoding stage, and to trigger permission prediction and address translation in parallel. This transforms the serial process in related technologies into a hardware parallel execution path, significantly reducing guest memory access latency and the frequency of virtual machine monitor intervention, thereby improving the overall performance and deterministic response of the virtualization system.

[0014] Based on the above description, embodiments of this application provide a memory access device. Figure 1 A schematic diagram of the composition structure of a memory access device provided in an embodiment of this application. Figure 1 ,like Figure 1 The memory access device 100 includes a permission prediction unit 110, an address translation unit 120, a pre-decoding module 130, and a two-level page table 140, wherein: The pre-decoding module 130 is used to synchronously acquire memory access instructions during the decoding stage of the instruction execution pipeline; determine the target virtual address and operation type based on the memory access instructions; determine the memory domain identifier based on the target virtual address and the operation type; generate a permission verification request based on the target virtual address, the operation type, and the memory domain identifier and send it to the permission prediction unit 110 and the address translation unit 120. The permission prediction unit 110 is used to determine whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and to generate a permission prediction result based on the determination result. The address translation unit 120 is used to traverse the two-level page table 140 based on the target virtual address to obtain the host physical address, and generate an address translation result based on the host physical address.

[0015] Here, the memory access device is a hardware unit in the processor used to process memory access instructions.

[0016] In some implementations, the memory access device is used in conjunction with the virtual machine monitor to perform address translation and permission verification. The memory access device may also be referred to as the Memory Management Unit (MMU).

[0017] In some implementations, a pre-decoding module is included in the memory access device to synchronously acquire memory access instructions during the decoding stage of the instruction execution pipeline, and perform hard-wired hardware analysis on the memory access instructions to extract the target virtual address and operation type. The target virtual address is a virtual memory address generated by the virtual machine's internal program, typically provided directly by the operand field or address calculation logic of the memory access instruction. The operation type is determined by the instruction encoding and usually includes basic access attributes such as read, write, and execute, and may also include atomic operations or device access flags.

[0018] In some implementations, after the pre-decoding module extracts the target virtual address and operation type, it determines the memory domain identifier based on the target virtual address and operation type, and generates an authorization verification request based on the target virtual address, operation type, and memory domain identifier. The target virtual address can also be called the virtual machine physical address.

[0019] The pre-decoding module is a dedicated hardware module embedded in the processor instruction pipeline decoding stage. Its core function is to complete the semantic parsing of memory access instructions within a single clock cycle. When the processor is in guest mode and fetches a memory access instruction from memory, the pre-decoding module immediately performs hardwired logic analysis on the instruction to extract the target virtual address (i.e., guest virtual address GVA), operation type (such as read, write, execute, etc.), and address space identifier.

[0020] In some implementations, the target virtual address is dynamically generated by the client program and has a high degree of context dependency; the operation type determines the behavioral attributes of memory access, used for permission judgment and exception handling; the memory domain identifier is a coarse-grained classification of access semantics, used for fast indexing of the global permission bitmap and realizing pre-permission pruning. The high-order bits of the target virtual address determine the memory region to which the address belongs, while the operation type further refines the access behavior within that region. Both are input into the memory domain identifier function to generate a unique memory domain identifier value, which becomes the index key for the permission prediction unit to query the global permission bitmap.

[0021] In one example, the client program attempts to read data from the target virtual address 0x8000_0000, which belongs to the user data area. Since the operation type is read, the memory domain identifier is generated as 0x2. In another scenario, the client program attempts to execute code at the target virtual address 0xF000_0000, which belongs to the kernel code area. Since the operation type is execute, the memory domain identifier is generated as 0x4. These two scenarios clearly demonstrate how the memory domain identifier generates different classification results based on different combinations of target virtual addresses and operation types, thereby supporting subsequent permission prediction.

[0022] In some implementations, after the pre-decoding module generates a permission verification request, it sends the permission verification request to the permission prediction unit and the address translation unit in parallel.

[0023] In some implementations, memory access instructions are synchronously acquired within a single clock cycle, the target virtual address and operation type (such as read, write, execute) are parsed, and the memory domain identifier is determined based on the operation type and the high-order bits of the virtual address. Then, a permission verification request vector containing the above information is generated, and the permission verification request vector is sent in parallel to the permission prediction unit and the address translation unit, so that the permission prediction unit and the address translation unit start simultaneously in the same context.

[0024] The permission prediction unit is a hardware logic module in the memory access device used for permission verification. It quickly determines whether an access operation satisfies the global access permission policy based on the operation type and memory domain identifier early in the execution of a memory access instruction (decoding phase). The permission prediction unit does not rely on specific page table entries; instead, it queries a preset global permission bitmap, performs rapid bitmasking, and outputs a prediction result indicating whether permission verification has passed or failed. This prediction serves as a pre-filtering condition, reducing unnecessary page table traversals.

[0025] In some implementations, the permission prediction unit performs permission verification synchronously with the address translation unit, pre-screening memory access instructions based on the global permission policy. The permission prediction unit receives a permission verification request vector from the pre-decoding module, which contains the operation type, memory domain identifier, and address space identifier. The core of the permission prediction unit is to query the global permission bitmap in the nested page table base address register group. The global permission bitmap is a three-dimensional logical structure whose index dimensions include the memory domain identifier, operation type (read / write / execute, etc.), and optional address space identifier. The permission prediction unit uses hard-wired bitmask comparison logic to combine the memory domain identifier and operation type in the current permission verification request vector into an index, and then queries the corresponding permission threshold bit in the global permission bitmap. If the corresponding bit is 1, it indicates that the current operation is within the scope allowed by the global policy, and the permission prediction result is "pass"; if the corresponding bit is 0, it indicates that the current operation violates the global permission policy, and the permission prediction result is "violation". It is important to note that the permission prediction unit serves only as a preliminary pruning condition and does not replace fine-grained permission checks in page table entries. The permission prediction result of the permission prediction unit must not allow for authorization expansion; that is, it can only deny legitimate access and cannot mistakenly allow illegal access. For example, when the memory domain is identified as 0x1 (user code area instruction fetch) and the operation type is execution, if the corresponding position in the global permission bitmap is 1, the permission prediction result is pass; if it is 0, the permission prediction result is violation. As another example, when the memory domain is identified as 0x3 (any operation in the device mapping area) and the operation type is read, if the corresponding position in the global permission bitmap is 0, the permission prediction result is violation, and even if subsequent page table entries might allow the access, it must be blocked early on.

[0026] In some implementations, the input to the permission prediction unit comes from the permission verification request vector. The key input fields of the permission prediction unit are the memory domain identifier and the operation type. These fields are generated by the pre-decoding module and form the basis of permission prediction. The hardware-dependent state of the permission prediction unit is the global permission bitmap in the nested page table base address register group. The global permission bitmap in the nested page table base address register group is written by the virtual machine monitor through a single privileged instruction during the virtual machine initialization phase and remains stable during runtime.

[0027] In some implementations, the core execution mechanism of the permission prediction unit is bitmask comparison logic, which does not access any specific page table entries, thus achieving extremely high execution efficiency. The permission prediction unit detects whether the operation exceeds the predefined global permission policy, and the output is the permission prediction result. The permission prediction result is bound to the current memory access instruction instance and address resolution context, and is directly sent to the exception aggregation module.

[0028] In some implementations, the permission prediction unit performs global permission pruning without accessing page table entries, significantly reducing the number of invalid page table traversals and lowering hardware resource consumption and power consumption. By filtering out obviously illegal access requests in advance, the entire memory access device can reduce unnecessary address translation operations, thereby improving overall performance. Furthermore, since the permission prediction result and the address translation result are output within the same clock cycle, the timeliness and consistency of subsequent exception handling mechanisms are ensured.

[0029] In some implementations, the address translation unit (ATU) is the core hardware module performing two-level address translation. The ATU's main task is to convert the client virtual address (GVA) into a host physical address (HPA) through a two-level page table traversal. The ATU receives the target virtual address from the permission verification request vector from the pre-decoding module. Starting with the first-level page table base address pointer, it initiates a first-level page table traversal state machine, resolving the client virtual address level by level and converting it into the client physical address (GPA). During each level of resolution, the ATU synchronously checks the presence bit, access permission bit, and address validity flag of page table entries. If a page table entry is missing or has incorrect permissions, the corresponding exception status is recorded. If no termination condition is triggered, the ATU continues, starting with the second-level page table base address pointer, and initiates a second-level page table traversal state machine to convert the client physical address (GPA) into the final host physical address (HPA), maintaining the same error detection semantics as the first-level traversal during the second-level page table traversal. Finally, the ATU outputs the address translation result, including the successfully obtained host physical address or the exception flag in case of failure. For example, in one real-world scenario, the target virtual address is 0x8000_0000, the first-level page table base pointer points to 0x1000_0000, and the second-level page table base pointer points to 0x2000_0000. The address translation unit first finds the corresponding page table entry in the first-level page table and resolves it to obtain the client physical address as 0x9000_0000; then it finds the corresponding page table entry in the second-level page table and resolves it to obtain the host physical address as 0xA000_0000. In another scenario, the target virtual address is 0x7000_0000, and the corresponding page table entry in the first-level page table does not exist. The address translation unit detects a page table entry missing anomaly and records it.

[0030] In some implementations, the input source for the address translation unit is a permission verification request vector. The key input field of the address translation unit is the target virtual address, which is extracted by the pre-decoding module. The hardware-dependent state of the address translation unit is the first-level page table base address pointer and the second-level page table base address pointer. These two pointers are provided by the nested page table base address register set, ensuring the determinism of the address translation path.

[0031] In some implementations, the address translation unit is started in complete synchronization with the permission prediction unit, that is, it is started within the same hardware clock cycle when the instruction decoding is completed.

[0032] In some implementations, the core execution mechanism of the address translation unit is a parallel execution of a two-level page table traversal state machine, accessing page table entries level by level. The address translation unit detects anomalies such as missing page table entries, page-level permission errors, and address out-of-bounds errors. The address translation unit maintains the current level and index state of the two-level page table traversal to enable execution recovery in case of anomalies. The output consists of the address translation result and a traversal status flag, which is bound to the current memory access instruction instance and address resolution context, and directly sent to the anomaly aggregation module.

[0033] In some implementations, the address translation unit (ATU) uses a hardware state machine to perform efficient two-level page table traversal, enabling most normal address translation operations to be completed within a single clock cycle. By synchronously detecting missing page table entries and permission errors, the ATU can promptly identify potential problems and compare them with permission prediction results, providing complete information for subsequent anomaly handling. This parallel processing approach significantly improves the throughput of address translation and reduces latency caused by serial execution.

[0034] In this embodiment, the pre-decoding module synchronously extracts memory access instructions during the instruction decoding stage, parses the target virtual address and operation type from the instructions, determines the memory domain identifier based on the operation type and target virtual address, and generates a permission verification request containing the target virtual address, operation type, and memory domain identifier. This request is then sent in parallel to the permission prediction unit and the address translation unit. The permission prediction unit performs permission judgment based on the operation type and memory domain identifier, quickly determining whether the access meets preset access conditions, thereby filtering illegal access in advance. The address translation unit initiates a two-level page table traversal based on the target virtual address, realizing the mapping from the client virtual address to the host physical address. Thus, by initiating parallel processing of permission prediction and address translation during the instruction decoding stage, the structural delay caused by serial execution in related technologies is resolved, significantly improving memory access efficiency. Simultaneously, the permission prediction unit does not rely on specific page table entries, performing rapid judgment only based on the operation type and memory domain identifier, reducing hardware resource consumption and improving response speed.

[0035] In some embodiments, the pre-decoding module is further configured to determine the memory domain identifier based on the operation type and the high-order domain of the target virtual address; the memory domain identifier is used to identify different address regions in the virtual address space.

[0036] In some implementations, the high-order domain of the target virtual address refers to the high N bits (e.g., the highest 8 bits or 16 bits) of the target virtual address, which is used to identify the address region to which the target virtual address belongs.

[0037] In some implementations, the client virtual address space may be divided into user code area, user data area, device mapping area, kernel code area, and kernel data area, etc.

[0038] In some implementations, the pre-decoding module jointly maps the operation type and the high-order field of the target virtual address to an element in a finite set of field identifiers, thereby generating the memory field identifier.

[0039] In some implementations, memory domain identifier It can be calculated using the following formula (1): (1); in, Refers to the operation type vector The extracted operation type classifications, such as value retrieval, reading, and writing, can also be extended to include atomic operations or device access flags. This refers to the classification of memory regions based on the high-order bits of the target virtual address of the client machine. A hardwired combinational logic function maps operation types to address regions as elements in a finite set of field identifiers.

[0040] For example, instruction fetch operations in the user code area are mapped to domain identifier 0x1, read and write operations in the user data area are mapped to 0x2, any operation in the device mapping area is mapped to 0x3, and code and data access in the kernel space are mapped to 0x4 and 0x5, respectively.

[0041] In some implementations, a hard-wired combination uniquely maps the operation type and address region binary input to a memory domain identifier output.

[0042] For example, instruction fetch operations in the user code area are mapped to domain identifier 0x1, read and write operations in the user data area are mapped to 0x2, any operation in the device mapping area is mapped to 0x3, and code and data access in the kernel space are mapped to 0x4 and 0x5, respectively.

[0043] In some implementations, memory domain identifiers enable the hardware to perform semantic classification of memory access during the instruction decoding stage, providing the permission prediction unit with a coarse-grained but fast basis for pre-access control and effectively isolating access behaviors of different security levels.

[0044] In some implementations, the memory domain identifier can be determined by the virtual machine monitor after statically partitioning the guest virtual address space during the initialization phase, and managed through the global permission bitmap in the page table base address register group.

[0045] In some implementations, memory domain identifiers can use 4-bit encoding to support up to 16 different memory domains, or 8-bit encoding to support finer divisions, suitable for virtualization systems of different sizes.

[0046] In this embodiment, the corresponding memory domain identifier is determined based on the operation type of the memory access instruction and the high-order bits of the target virtual address during the instruction decoding stage. This allows for pre-classification of memory access semantics, efficiently distinguishing access behaviors at different security levels, and effectively isolating sensitive areas such as user mode and kernel mode, and ordinary memory and device mapping areas. This enables rapid global permission pruning in the permission prediction unit, reducing the probability of triggering subsequent fine-grained verification.

[0047] In some embodiments, such as Figure 2 As shown, the memory access device 100 further includes an exception aggregation module 140 and a page table base address register group 160, wherein the page table base address register group 160 includes a global permission bitmap 161; The permission prediction unit 110 is used to query the global permission bitmap 161 based on the operation type and the memory domain identifier, determine whether the memory access instruction meets the access conditions, and generate a permission prediction result; and send the permission prediction result to the exception aggregation module 150; the global permission bitmap uses a bitmask to describe the mapping relationship between the operation type, the memory domain identifier, and the address region; the permission prediction result includes permission verification passed or permission verification failed.

[0048] In some implementations, after receiving the permission verification request vector, the permission prediction unit immediately queries the global permission bitmap in the nested page table base address register group and determines whether the current operation exceeds the predefined permission threshold by comparing the bitmask.

[0049] In some implementations, the permission prediction unit directly accesses the global permission bitmap that has been fixed in the nested page table base address register group based on the memory domain identifier, operation vector and address space identifier carried in the request vector, and completes a deterministic permission threshold pruning through hard-wired bitmask comparison logic. This pruning process does not involve reading any page table entries, and its output only indicates whether the current memory access is within the range allowed by the global permission policy, thus forming a pre-constraint in time before the fine page table permission judgment.

[0050] In some implementations, the permission prediction result output by the permission prediction unit and the traversal status result output by the address translation unit are submitted to the exception aggregation module on the same clock edge through the hardware-aligned result bus. The two types of results share the same instruction instance identifier and address resolution context, thereby ensuring that the subsequent exception handling logic can directly make a comprehensive judgment without cross-cycle association or result rearrangement, and naturally connect to the non-blocking page fault preloading and exception integration processing flow triggered by the exception aggregation module.

[0051] In some implementations, the input source of the permission prediction unit is the permission verification request vector, and the key input fields are memory domain identifier, operation vector, and address space identifier. The hardware dependency state is the global permission bitmap in the nested page table base address register group. The startup timing is the same hardware clock cycle synchronized with the completion of instruction decoding. The core execution mechanism is bitmask comparison logic to perform global permission threshold pruning. The permission prediction unit does not access any specific page table entry. The verification or detection content is whether the operation exceeds the predefined global permission policy. The permission prediction unit does not maintain the page table traversal state. The output result type of the permission prediction unit is the permission prediction result flag. The output timing of the permission prediction unit is fixed at the end of the current clock cycle. The output destination of the permission prediction unit is the exception aggregation module. The permission prediction unit is bound to the current instruction instance and address resolution context.

[0052] In some embodiments, such as Figure 3 As shown, the memory access device 100 further includes an exception aggregation module 150, and the two-level page table 140 includes a first-level page table 141 and a second-level page table 142; the address translation unit 120 is further configured to traverse the first-level page table 141 based on the target virtual address to obtain an intermediate physical address; and traverse the second-level page table 142 based on the intermediate physical address to obtain a host physical address; the address translation unit is further configured to send the address translation result to the exception aggregation module 150, and the address translation result includes a host physical address or a page table entry missing error.

[0053] Here, a two-level page table refers to the two-stage mapping system used to implement nested address translation. A two-level page table includes a first-level page table and a second-level page table.

[0054] In some implementations, a two-level page table is a nested page table structure configured by the virtual machine monitor in the host physical memory. During the initialization phase, the virtual machine monitor allocates a physical memory region for each virtual machine instance and constructs the two-level nested page table structure.

[0055] The first-level page table maps the target virtual address to the intermediate physical address, used to translate the target virtual address into the intermediate physical address. The second-level page table maps the intermediate physical address to the host physical address, used to translate the intermediate physical address into the host physical address. In one example, the intermediate physical address can also be referred to as the client physical address.

[0056] In some implementations, during the initialization phase, the virtual machine monitor allocates a contiguous and isolated physical memory region in the host physical memory for each virtual machine instance, and constructs a strictly separated two-level nested page table structure within this region. The first-level page table is used to map guest virtual addresses to guest physical addresses, and the second-level page table is used to map guest physical addresses to host physical addresses. The two-level mapping is defined semantically as a deterministic composite address resolution function, expressed as follows: (2); in, This represents the guest virtual address, the virtual memory address generated by programs running inside the virtual machine. This address space is managed by the guest operating system and appears as a contiguous linear address space to applications. This represents the linear address resolution operator determined by the base address pointer of the first-level page table. This represents the physical address resolution operator determined by the base address pointer of the second-level page table. This is the final host physical address.

[0057] In some implementations, the first-level page table can be managed by the guest operating system, while the second-level page table is configured by the virtual machine monitor.

[0058] In some implementations, the two-level page tables can use page sizes of different granularities (such as 4KB, 2MB, 1GB) to accommodate different memory access patterns and performance requirements. For example, in I / O-intensive scenarios, larger pages can be used to reduce the number of page table traversals; while in high-concurrency computing scenarios, smaller pages may be used to improve address mapping flexibility.

[0059] An address translation unit is a hardware component in a memory access device that performs a two-stage translation process from a target virtual address to a host physical address.

[0060] In some implementations, the address translation unit receives an authorization verification request. Based on the target virtual address included in the authorization verification request, it initiates a first-level page table traversal state machine. The first-level page table traversal state machine parses the high-order index field of the client virtual address level by level, searching for the corresponding page table entry, thereby mapping the client virtual address to an intermediate physical address. After completing the first-level page table translation, the address translation unit uses the obtained intermediate physical address as input to initiate a second-level page table traversal state machine. The second-level page table traversal state machine continues to parse the high-order index of the intermediate physical address, searching for the corresponding page table entry in the second-level page table, ultimately mapping the intermediate physical address to the host physical address.

[0061] In some implementations, during the first-level page table traversal and the second-level page table traversal, the address translation unit simultaneously detects abnormal situations such as missing page table entries, permission errors, and address out-of-bounds errors.

[0062] In some implementations, the address translation unit generates an address translation result including the host physical address if it successfully obtains the host physical address; and generates an address translation result including the page table entry missing error if it detects a missing page table entry error that prevents it from obtaining the host physical address.

[0063] In some implementations, if the address translation unit detects a page table entry missing error at any stage, it uses the page table entry missing error and the context information of the current memory access instruction instance (such as the fault address, operation type, etc.) as the address translation result.

[0064] For example, when the guest operating system accesses an unmapped memory region, the address translation unit cannot find a corresponding entry in the second-level page table, so it returns a page table entry missing error and sends it to the exception aggregation module; after receiving the page table entry missing error, the exception aggregation module immediately starts the page fault preloading process.

[0065] In some implementations, the address translation unit sends the address translation result to the anomaly aggregation module.

[0066] In this embodiment, the two-level page table includes a first-level page table and a second-level page table. The address translation unit traverses the first-level page table based on the target virtual address to obtain an intermediate physical address. Based on the intermediate physical address, it traverses the second-level page table to obtain the host physical address. The address translation unit is also used to send the address translation result to the anomaly aggregation module. The address translation result includes either the host physical address or a page table entry missing error. In this way, the address translation unit converts the target virtual address to the host physical address by traversing the two-level page tables, and generates an address translation result including either the host physical address or a page table entry missing error during the traversal process, and sends it to the anomaly aggregation module, thereby providing a consistent context for subsequent anomaly handling.

[0067] In some implementations, the address translation unit first receives the target virtual address, i.e., the client virtual address, and starts the first-level page table traversal state machine based on the first-level page table base address pointer stored in the nested page table base address register group. The first-level page table traversal state machine parses the high-order index field of the client virtual address level by level, finds the corresponding page table entry, and thus maps the client virtual address to an intermediate physical address. During the traversal, the address translation unit synchronously checks whether the page table entry exists, whether the access permissions match, and whether the address is out of bounds. If a page table entry is missing or the permissions are incorrect, a corresponding exception flag is generated and passed to the exception aggregation module. The above address translation process does not rely on the intervention of the virtual machine monitor and is executed entirely in parallel by the hardware pipeline, which significantly improves the address translation efficiency. For example, when processing the client virtual address of a 4KB page, the address translation unit only needs to complete the first-level mapping through two indexing operations, and the entire process can be completed within a single clock cycle.

[0068] In some implementations, the exception aggregation module receives parallel outputs from the permission prediction unit and the address translation unit, completes a comprehensive judgment of the exception state within a single clock cycle, and performs non-blocking page fault preloading or submits exception encoding information to the exception handling queue according to preset rules. For example, when a page table entry is detected as missing but there is no permission violation, the exception aggregation module will directly initiate a hardware prefetch operation to avoid triggering a trapout operation of the virtual machine monitor; only when there is a permission error or preloading failure will the exception be submitted to the virtual machine monitor for processing. The existence of the exception aggregation module transforms the originally serial exception processing mechanism into a hardware-driven batch processing mode, significantly reducing the performance overhead caused by frequent context switching.

[0069] In some implementations, the permission prediction unit and the address translation unit operate in parallel under identical input conditions and timing constraints. Both units receive permission verification request vectors from the pre-decoding module and start within the same hardware clock cycle. The permission prediction unit focuses on global permission pruning, without accessing any specific page table entries, and only determines whether the current operation is within the scope allowed by the global permission policy through bitmask comparison logic. The address translation unit focuses on fine-grained address resolution, accessing page table entries level by level through a two-level page table traversal state machine to generate the final host physical address or exception state. The permission prediction unit and the address translation unit have strictly separate functions and do not block each other; the permission prediction unit is responsible for pre-filtering, and the address translation unit is responsible for precise conversion. At the end of the same hardware clock cycle, the permission prediction unit outputs the permission prediction result, and the address translation unit outputs the address translation result and traversal status flag. The permission prediction unit and the address translation unit simultaneously submit the results to the exception aggregation module through a hardware-aligned result bus. This parallel mechanism ensures strict synchronization between permission judgment and address translation in time, avoiding the structural waiting in the traditional serial mode, making the entire memory access process more efficient and deterministic.

[0070] In some implementations, the relationship between the permission prediction unit and the address translation unit is reflected in their sharing of the same input (permission verification request vector) and the same timing constraints (synchronous startup, synchronous output), but they each perform different functions. The result of the permission prediction unit provides pre-constraints for the address translation unit; if the permission prediction result is a violation, the access will be judged as illegal regardless of whether the address translation is successful. Conversely, the result of the address translation unit provides supplementary information for the permission prediction unit, such as missing page table entries potentially preventing subsequent permission verification. The outputs of the permission prediction unit and the address translation unit together constitute the input basis of the exception aggregation module, ensuring the integrity of exception handling.

[0071] In this embodiment, the parallel execution of the permission prediction unit and the address translation unit transforms the critical path of memory access from serial to parallel, greatly improving processing speed. By outputting results within the same clock cycle, it is possible to quickly proceed to the next stage of exception handling, reducing pipeline bubbling and waiting time. This not only improves performance but also enhances system determinism, as all operations related to permission prediction and address translation are completed in the same context, reducing data inconsistency issues across clock cycles.

[0072] In some embodiments, such as Figure 4As shown, the memory access device 100 further includes a page table base address register group 160, which includes a first-level page table base address pointer 162 and a second-level page table base address pointer 163. The address translation unit 120 is further configured to traverse the first-level page table 141 level by level with the first-level page table base address pointer 162 as the root node, and convert the target virtual address into an intermediate physical address; and query the second-level page table 142 level by level with the second-level page table base address pointer 163 as the root node, and convert the intermediate physical address into the host physical address.

[0073] Here, the first-level page table base address pointer is a hardware register value in the two-level page table that points to the starting position of the first-level page table. The first-level page table base address pointer serves as the entry point for the address translation unit to perform the translation of the target virtual address into the intermediate physical address.

[0074] The first-level page table base address pointer is stored in a dedicated page table base address register set. It is written and bound by the virtual machine monitor once during the virtual machine initialization phase using privileged instructions to ensure that the translation process has a deterministic context.

[0075] The second-level page table base pointer is a hardware register value in the two-level page table that points to the starting location of the second-level page table. The second-level page table base pointer serves as the entry point for the address translation unit to perform intermediate physical address to host physical address translation.

[0076] The second-level page table base address pointer is also stored in a dedicated page table base address register set. It is written and bound by the virtual machine monitor once during the virtual machine initialization phase using privileged instructions to ensure that the translation process has a deterministic context.

[0077] In some implementations, the address translation unit starts from the base address pointer of the first-level page table and accesses the page table entries in the first-level page table level by level according to the high-order index field of the target virtual address until the corresponding client physical address (i.e., intermediate physical address) is resolved. The first-level page table traversal process usually involves the advancement of a multi-level page table traversal state machine, and each step checks the validity bits, permission bits, and address legality of the page table entries.

[0078] In some implementations, the address translation unit starts from the base address pointer of the second-level page table and accesses the page table entries in the second-level page table level by level according to the high-order index field of the intermediate physical address until the final host physical address is resolved. The second-level page table traversal process continues the first-level page table traversal mechanism, but it is for the mapping from the client physical address to the host physical address.

[0079] In some implementations, the first-level page table base address pointer and the second-level page table base address pointer serve as the two-stage entry points for the two-level page tables, corresponding to the two translation stages: from the target virtual address to the intermediate physical address and from the intermediate physical address to the host physical address, respectively. During the hardware execution flow, the output of the first-level page table base address pointer (i.e., the intermediate physical address) is directly used as the input address of the second-level page table base address pointer, forming a chained translation path.

[0080] In this embodiment, the first-level page table base address pointer and the second-level page table base address pointer in the page table base address register group are used as the root nodes for traversing the two-level page tables, respectively. This enables a phased and step-by-step conversion from the target virtual address to the host physical address, allowing the hardware to obtain a stable conversion context and preventing frequent updates and state switching.

[0081] In some embodiments, the anomaly aggregation module is configured to receive the permission prediction result and the address translation result in the same clock cycle, and if the permission prediction result indicates that the permission verification fails and / or the address translation result indicates that the page table entry is missing or misaligned, suspend the address translation process corresponding to the memory access instruction and generate anomaly encoding information; the permission prediction result and the address translation result are sent by the permission prediction unit and the address translation unit in the same clock cycle.

[0082] In some implementations, the exception aggregation module performs non-blocking page fault preloading. If the permission prediction unit returns a permission violation or the address translation unit detects a missing page table entry, the exception aggregation module immediately freezes the current pipeline and generates exception encoding information. This encoding integrates the permission error type, the missing page table level, and the target address information. For page table entry missing exceptions, the hardware directly pre-reads the missing page table entry from the host physical memory to a dedicated cache based on the missing level and the target address, and updates the page table traversal state machine at the corresponding level. If the pre-read is successful, the address translation process is automatically restarted without triggering a machine mode exception trap. The exception encoding information is submitted to the exception handling queue only when there is a permission error or preloading failure.

[0083] In some implementations, after the permission prediction unit and the address translation unit output their results in parallel within the same hardware clock cycle, the exception aggregation module receives the permission prediction result and address translation status result bound to the same instruction instance, and performs unified trimming of exception types based on hard-wired judgment logic. When the permission prediction result indicates the current operation vector... Beyond the global permission bitmap When the defined access threshold is reached, or when the address translation unit detects a missing page table entry during a two-level page table traversal, the exception aggregation module immediately implements a targeted freeze on the pipeline stage related to the memory access instruction, thereby preventing subsequent instructions from entering an execution path that conflicts with the current address resolution context. Within the same clock domain where the freeze takes effect, the exception aggregation module generates a unique exception encoding information.

[0084] In some implementations, the anomaly-encoded information is presented as a permission verification request vector. As the indexing benchmark, it integrates permission violation flags, missing page table entry flags, the hierarchy of the missing page table, and the target client's virtual address. This, along with the current intermediate physical address index state, forms a hardware-resolvable exception entity that can fully describe the exception semantics and recovery conditions. When the exception type represented by the exception encoding information is a missing page table entry and does not contain a permission violation flag, the exception aggregation module does not trigger a machine-mode exception trap. Instead, it directly initiates a hardware prefetch operation on the corresponding page table entry from the host physical memory based on the missing page table level and the resolved address index state. The prefetch result is written to a dedicated page table cache structure, and at the same time, it drives the page table traversal state machine at the corresponding level in the address translation unit to complete the state update, restoring it to an intermediate state that can continue to be resolved. After the prefetch operation is successfully completed, the exception aggregation module releases the pipeline freeze control for the current instruction and sends a restart signal to the address translation unit, so that the two-level page table traversal process can automatically continue to execute on the updated state and the whole process does not produce machine mode exception traps. The exception aggregation module submits the exception encoding information to the exception handling queue only when the exception encoding information contains a permission violation flag or the page table entry prefetch operation returns to a failed state. This allows subsequent steps to sort the exceptions according to priority rules and trigger aggregation traps, thereby achieving priority self-healing of page fault exceptions and strict isolation of permission exceptions on the hardware side.

[0085] In this embodiment, the anomaly aggregation module receives permission prediction results and address translation results within the same clock cycle. If the permission prediction result indicates that the permission verification failed and / or the address translation result indicates that a page table entry is missing or misaligned, the address translation process corresponding to the memory access instruction is paused, and an anomaly encoding information is generated. The permission prediction result and the address translation result are sent by the permission prediction unit and the address translation unit within the same clock cycle. Thus, the anomaly aggregation module only aggregates the same instruction instance and its derived address resolution context, enabling the handling of anomalies for the same memory access instruction.

[0086] In some embodiments, the exception encoding information includes an exception type and exception information corresponding to the exception type; the exception aggregation module is further configured to, when the exception type includes a page table entry missing error, pre-read the missing page table entry from the host physical memory to the target cache based on the missing page table level included in the exception information and the parsed address index state; the exception aggregation module is further configured to, if the pre-reading of the missing page table entry is successful, send a pre-reading success signal to the address translation unit; the address translation unit is further configured to, in response to the pre-reading success signal, restart the address translation process corresponding to the memory access instruction, and, based on the parsed address index state and the target cache, convert the target virtual address to the host physical address.

[0087] Here, the exception encoding information is a unified data structure used by the hardware during address translation to describe the occurrence of faults or errors.

[0088] In some implementations, the exception coding information includes the exception type and the exception information corresponding to the exception type.

[0089] The exception type is used to identify the category of the error, such as a missing page table entry error, a permission violation error, or an out-of-bounds address error; the exception information contains specific parameters related to the exception type, such as the level of the missing page table, the target virtual address, and the current address index status.

[0090] In some implementations, the exception encoding information uses a structured encoding method to identify error types and extract necessary contextual information, facilitating subsequent exception handling. The exception encoding information exists in the form of fixed-width hardware-encoded fields, ensuring consistent formatting and efficient parsing when transmitted between different modules.

[0091] In some implementations, the address translation unit sends the address translation result to the anomaly aggregation module; the anomaly aggregation module receives the address translation result, and when the address translation result indicates that a page table entry is missing, the anomaly encoding information includes the level of the missing page table (such as L1, L2), the target virtual address, and the status of the resolved address index (such as the first-level page table traversal is complete but the second-level page table is not complete).

[0092] In some implementations, when the exception type is a missing page table entry, the exception aggregation module pre-reads the missing page table entry from the host physical memory to a dedicated cache according to the missing level and target address, and updates the page table traversal state machine at the corresponding level; if the pre-read is successful, the address translation process is automatically restarted without triggering a machine mode exception trap; only when there is a permission error or preloading failure is the exception encoding information submitted to the exception handling queue.

[0093] In this embodiment, the exception encoding information is structured into a combination of exception type and exception information. This allows for clear differentiation of different types of exception events, enabling the targeted triggering of corresponding hardware recovery mechanisms, thereby improving the efficiency and determinism of exception handling.

[0094] In some embodiments, the exception aggregation module is further configured to submit the exception encoding information to the exception handling queue in the event that the pre-reading of the missing page table entry fails.

[0095] Here, the exception handling queue is a dedicated queue structure in the hardware used to temporarily store and manage pending exception events.

[0096] The anomaly aggregation module is a hardware module that integrates permission prediction results and address translation results. It is used to uniformly trim and process the address translation results and permission verification results. In some implementations, if the anomaly aggregation module fails to pre-read a missing page table entry from the host physical memory due to reasons such as memory inaccessibility, non-existent page table entry, or insufficient cache resources, it immediately stops the self-healing process and submits the currently generated anomaly encoding information to the anomaly handling queue.

[0097] In some implementations, if prefetching a missing page table entry fails, the virtual machine monitor is allowed to intervene and repair the issue via a one-time machine mode exception handler.

[0098] In some implementations, the exception aggregation module receives permission prediction results and address translation results. If either result indicates an exception, the current pipeline is frozen and exception encoding information is generated. For page table entry missing exceptions, the hardware directly pre-reads the missing page table entry into a dedicated page table cache structure and updates the state machine. The exception encoding information is submitted to the exception handling queue only when there is a permission error or preloading failure.

[0099] When the permission prediction result indicates that the current operation exceeds the global permission threshold, or the address translation unit detects a missing page table entry, the exception aggregation module immediately implements a targeted freeze on the pipeline stage related to the current memory access instruction to prevent subsequent instructions from entering the conflict path. Simultaneously with the freeze taking effect, the exception aggregation module generates unique exception encoding information. This information integrates permission violation flags, missing page table entry flags, the level of the missing page table, the target virtual address, and the current client physical address index, forming a complete exception semantic description. For page table entry missing exceptions, if no permission violation flag is included, the exception aggregation module does not trigger a machine-mode exception trap. Instead, it directly initiates a hardware prefetch operation from the host physical memory based on the missing page table level and the resolved address index state, writing the missing page table entry into a dedicated page table cache structure and driving the corresponding level's page table traversal state machine in the address translation unit to complete the state update. After successful prefetching, the exception aggregation module unfreezes the pipeline and sends a restart signal to the address translation unit, allowing the two-level page table traversal process to automatically continue execution based on the updated state. The entire process does not generate a machine-mode exception trap. The exception aggregation module submits the exception code information to the hierarchical exception queue for processing by subsequent steps only when the exception code information contains a permission violation flag or when the page table entry prefetch operation returns a failure status.

[0100] The exception encoding information is a fixed-width hardware code generated by the exception aggregation module. This encoding uniquely describes the semantics and recovery conditions of a memory access exception, serving as the basis for subsequent hierarchical exception queue sorting and trap-out decisions. The exception encoding information includes key information such as exception type flags, page table level identifiers, and target virtual address indexes, ensuring the accuracy and efficiency of exception handling. For example, in one scenario, the address translation unit detects a missing first-level page table; the exception aggregation module generates exception encoding information with the page table missing flag set, the missing level set to 1, and the target virtual address set to 0x8000_0000. In another scenario, the permission prediction unit determines an operation violation; the exception aggregation module generates exception encoding information with the permission violation flag set and the target virtual address set to 0x7000_0000. These two scenarios demonstrate how exception encoding information generates different encoding values ​​based on different types of exceptions, thereby supporting differentiated processing strategies.

[0101] In some implementations, the exception aggregation module significantly reduces the frequency of virtual machine monitor intervention through a non-blocking page fault preloading mechanism. For common page table entry missing exceptions, the hardware can self-heal without software intervention, thereby reducing system overhead and latency. Exception traps are only triggered in cases of permission errors or preloading failures that truly require software processing, ensuring the efficient operation of the virtual machine monitor.

[0102] In some implementations, by synchronously extracting the address and permission information of memory access instructions during the decoding stage of the instruction execution pipeline, and triggering permission prediction and address translation in parallel, combined with an exception aggregation module to achieve page fault preloading and hierarchical exception priority handling, the serial process in related technologies is transformed into a deterministic path of hardware parallel execution and software batch repair. The pre-decoding module, permission prediction unit, address translation unit, and exception aggregation module work together to achieve synchronous completion of permission verification and address translation, effectively reducing structural latency; the exception aggregation module performs non-blocking preloading of page table missing data, significantly reducing the intervention frequency of the virtual machine monitor; the hierarchical exception queue submits aggregated trap events according to priority, ensuring that the virtual machine monitor only needs to process multiple related errors once. Overall, the memory access device provided in this application embodiment constructs an efficient, deterministic, and autonomous hardware virtualization execution environment, which significantly improves the memory access performance and response determinism of the virtualization system while ensuring security isolation.

[0103] In this embodiment of the application, when the pre-read fails, the exception aggregation module submits the exception encoding information to the exception handling queue so that the virtual machine monitor can perform subsequent processing, preventing indefinite waiting or error retries due to pre-read failure, thereby enabling exceptions to be reported in a timely manner and enter a unified processing flow.

[0104] In some embodiments, the exception encoding information includes the exception type. The exception aggregation module is further configured to submit the exception encoding information to the exception processing queue when the exception type includes permission verification failure.

[0105] In some implementations, when the permission prediction unit detects that the operation type exceeds the access threshold defined by the global permission bitmap, the exception aggregation module generates exception encoding information including permission error identifier, records the corresponding operation type, virtual address and address space identifier, and submits the exception encoding information to the exception handling queue.

[0106] In some implementations, when the permission prediction unit determines that the current memory access operation type fails the permission verification predefined by the global permission bitmap, the exception aggregation module will not attempt self-healing (such as page fault preloading), but will directly submit the exception encoding information to the exception handling queue so that it can be uniformly processed by the virtual machine monitor later.

[0107] In some implementations, after receiving the exception encoding information, the exception handling queue sorts the events according to a preset priority rule, with permission errors taking precedence over address translation errors, and errors at the same level arranged in virtual address order. After sorting, the exception handling queue submits only a single aggregated trap signal to the virtual machine monitor. This signal carries a complete context snapshot of the highest priority exception, including the fault address, operation type, and intermediate states of the two-level page table traversal. The virtual machine monitor parses and repairs all associated errors through a single machine mode exception handler, and the hardware automatically restores the guest execution flow after repair.

[0108] In some implementations, after receiving exception encoding information, the exception handling queue first performs hierarchical reception and orderly storage based on its embedded exception type flag and page table hierarchy information. This queue does not perform further parsing of exception semantics, but directly utilizes the fault address and operation vector already embedded in the exception encoding information. Client virtual address Furthermore, the intermediate states of the two-level page table traversal establish a one-to-one correspondence between exception instances and address translation contexts, thereby ensuring a complete and consistent context foundation for subsequent sorting and submission processes. Based on this, the exception handling queue stably sorts all pending exception instances according to a preset and immutable priority pruning rule. The sorting logic explicitly stipulates that permission violation exceptions take precedence over address translation exceptions, and within the same exception category, the order is determined by the page table missing level and the client's virtual address. The exceptions are arranged in ascending order to ensure that the order of exception submissions matches the actual address resolution path, thus preventing the virtual machine monitor from processing exceptions across levels or in reverse order during the repair process. After the sorting process is completed, the hardware selects only the highest priority exception instance in the current queue to generate a single aggregated trap signal and submits it to the virtual machine monitor. This trap signal carries a complete snapshot of the exception context, which includes the fault address, operation vector, address space identifier, and intermediate state information of the two-level page table traversal. The remaining low-priority exceptions are resolved and repaired uniformly in the same machine mode exception handler through implicit association with this context. After the virtual machine monitor completes the permission status or page table content update, the exception handling queue automatically resumes the address translation process and continues the guest execution flow based on the repaired context, thereby achieving multiple exceptions trapped at once and deterministic recovery.

[0109] In this embodiment, when the exception type includes permission verification failure, the exception code information is submitted to the exception handling queue. This avoids permission violation exceptions being mishandled by the hardware self-healing mechanism, ensuring that all permission errors are reported to the virtual machine monitor for centralized inspection and repair, thereby improving system security and the determinism of permission control.

[0110] In some embodiments, the exception handling queue is used to process at least one of the exception codes according to a preset priority; the priority of the exception type being permission verification failure is higher than the priority of the exception type being page table entry missing error.

[0111] Here, preset priorities refer to a set of immutable exception handling order rules fixed during the hardware design phase, used to guide the exception handling queue in sorting multiple concurrent exceptions. Preset priorities are set based on the severity and urgency of different exception types. For example, permission errors must be handled first due to security policy violations, while page table missing exceptions can be self-healed through hardware preloading mechanisms and therefore have lower priorities. Preset priorities are stored in the hardware control logic and implemented through hard-wired combinational logic, ensuring stable execution under any operating state and avoiding uncertainties introduced by software intervention.

[0112] In some implementations, the exception handling queue categorizes exceptions based on exception type flags embedded in the exception encoding information and sorts multiple exceptions generated at the same time according to a preset priority rule. For example, during a client machine execution, if both a permission failure exception and a page table entry missing exception occur simultaneously, the exception handling queue will prioritize the permission failure exception, ensuring that it is submitted to the virtual machine monitor first. This mechanism significantly reduces the virtual machine monitor's response latency in exception handling and improves the overall system determinism.

[0113] In some embodiments, the permission verification request further includes an address space identifier, which is used to identify the address space corresponding to different virtual machine instances; the pre-decoding module is further used to determine the target virtual address, the operation type, the memory domain identifier, and the address space identifier based on the memory access instruction; and to generate the permission verification request based on the target virtual address, the operation type, the memory domain identifier, and the address space identifier.

[0114] Here, the address space identifier is a context identifier maintained by the processor hardware to distinguish the address spaces used by different virtual machines or different processes.

[0115] In some implementations, under the RISC-V architecture, the address space identifier can be uniformly allocated by the virtual machine monitor and written to the hardware status register via privileged instructions during the virtual machine initialization phase.

[0116] In some implementations, the permission verification request includes an address space identifier, enabling the permission prediction unit and the address translation unit to determine which virtual machine instance's address space the current operation belongs to when processing memory access instructions, thereby achieving secure isolation in a multi-virtual machine parallel operation environment. For example, when multiple virtual machines (such as VM1 and VM2) are running on a host machine, each virtual machine is assigned a unique address space identifier (such as AS1 and AS2). When a virtual machine executes a memory access instruction, the pre-decoding module includes the address space identifier of the corresponding virtual machine in the permission verification request, so that subsequent permission judgment and address translation are only performed on the two-level page table of the corresponding virtual machine.

[0117] In some implementations, when the virtual machine monitor configures the runtime environment for a newly created virtual machine, it assigns a unique address space identifier to the new virtual machine and binds this address space identifier to the page table base address register set of the new virtual machine. In guest mode, whenever the newly created virtual machine executes a memory access instruction, the pre-decoding module automatically extracts the address space identifier and generates a permission verification request based on the target virtual address, operation type, memory domain identifier, and address space identifier.

[0118] In some implementations, the permission prediction unit queries the global permission bitmap based on the address space identifier, operation type, and memory domain identifier. The address space identifier enables the permission prediction unit to query the global permission bitmap of the corresponding virtual machine, while the address translation unit selects the correct first-level and second-level page table base address pointers based on the address space identifier, thereby achieving precise processing of the specific virtual machine's address space. For example, in a multi-virtual machine environment, if two virtual machines share the same physical memory region but have different address space identifiers, their respective memory access requests will be routed to each virtual machine's independent page table structure, ensuring that address translation does not interfere with each other.

[0119] In some implementations, the lower-level characteristics of the address space identifier include: a unique identifier based on the virtual machine ID, suitable for standard virtualization scenarios; and a fine-grained identifier based on the process ID (such as in a containerized environment where each container uses an independent address space identifier), suitable for lightweight virtualization scenarios.

[0120] In this embodiment, by introducing an address space identifier into the permission verification request, and having the pre-decoding module synchronously extract the target virtual address, operation type, memory domain identifier, and address space identifier to generate the permission verification request, this approach supports multi-virtual machine parallel scenarios. It enables accurate identification and isolation of address spaces in a multi-virtual machine environment, allowing permission prediction and address translation operations to be performed within the virtual machine context, thereby improving the security and concurrent processing capabilities of the virtualization system.

[0121] This application provides a memory access method. Figure 5 This is a schematic diagram illustrating the implementation flow of a memory access method provided in an embodiment of this application, as shown below. Figure 5 As shown, the method is applied to a memory access device, which includes a permission prediction unit, an address translation unit, and a pre-decoding module. The method may include the following steps S501 to S503: Step S501: The pre-decoding module synchronously acquires memory access instructions during the decoding stage of the instruction execution pipeline; determines the target virtual address and operation type based on the memory access instructions; determines the memory domain identifier based on the target virtual address and the operation type; generates a permission verification request based on the target virtual address, the operation type, and the memory domain identifier and sends it to the permission prediction unit and the address translation unit; Step S502: The permission prediction unit determines whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and generates a permission prediction result based on the determination result; Step S503: The address translation unit traverses the two-level page table based on the target virtual address to obtain the host physical address, and generates the address translation result based on the host physical address.

[0122] In some embodiments, step S501 above may include the following step S511: Step S511: The pre-decoding module determines the memory domain identifier based on the operation type and the high-order domain of the target virtual address; the memory domain identifier is used to identify different address regions in the virtual address space.

[0123] In some embodiments, the memory access device further includes an exception aggregation module and a page table base address register group, wherein the page table base address register group includes a global permission bitmap, and step S502 above may include the following step S521: Step S521: The permission prediction unit queries the global permission bitmap based on the operation type and the memory domain identifier to determine whether the memory access instruction meets the access conditions and generates a permission prediction result; the permission prediction result is sent to the exception aggregation module; the global permission bitmap uses a bitmask to describe the mapping relationship between the operation type, memory domain identifier and address region; the permission prediction result includes permission verification passed or permission verification failed.

[0124] In some embodiments, the memory access device further includes an exception aggregation module, and the two-level page table includes a first-level page table and a second-level page table. Step S503 may include the following steps S531 and S532: Step S531: The address translation unit traverses the first-level page table based on the target virtual address to obtain the intermediate physical address; based on the intermediate physical address, it traverses the second-level page table to obtain the host physical address; Step S532: The address translation unit sends the address translation result to the anomaly aggregation module. The address translation result includes a host physical address or a page table entry missing error.

[0125] In some embodiments, the memory access device further includes a page table base address register group, the page table base address register group including a first-level page table base address pointer and a second-level page table base address pointer; the above step S531 may include the following step S541: Step S541: The address translation unit uses the first-level page table base address pointer as the root node, traverses the first-level page table level by level, and converts the target virtual address into an intermediate physical address; it uses the second-level page table base address pointer as the root node, queries the second-level page table level by level, and converts the intermediate physical address into the host physical address.

[0126] In some embodiments, the above method may further include the following step S551: Step S551: The anomaly aggregation module receives the permission prediction result and the address translation result in the same clock cycle. If the permission prediction result indicates that the permission verification fails and / or the address translation result indicates that the page table entry is missing or misaligned, the address translation process corresponding to the memory access instruction is paused, and an anomaly encoding information is generated. The permission prediction result and the address translation result are sent by the permission prediction unit and the address translation unit in the same clock cycle.

[0127] In some embodiments, the exception encoding information includes an exception type and exception information corresponding to the exception type; the above method may further include the following steps S561 to S563: Step S561: When the exception type includes a page table entry missing error, the exception aggregation module pre-reads the missing page table entry from the host physical memory to the target cache based on the missing page table level and the parsed address index status included in the exception information; Step S562: If the anomaly aggregation module successfully pre-reads the missing page table entry, it sends a pre-read success signal to the address translation unit. Step S563: In response to the pre-fetch success signal, the address translation unit restarts the address translation process corresponding to the memory access instruction, and converts the target virtual address into the host physical address based on the parsed address index state and the target cache.

[0128] In some embodiments, the above method may further include the following step S571: Step S571: In the event that the pre-reading of the missing page table entry fails, the exception aggregation module submits the exception encoding information to the exception handling queue.

[0129] In some embodiments, the above method may further include the following step S572: Step S572: If the exception type includes permission verification failure, the exception aggregation module submits the exception encoding information to the exception processing queue.

[0130] In some embodiments, the above method may further include the following step S581: Step S581: The exception handling queue processes at least one of the exception codes according to a preset priority; the priority of the exception type "permission verification failure" is higher than the priority of the exception type "page table entry missing error".

[0131] In some embodiments, step S501 above may include the following step S591: Step S591: The pre-decoding module determines the target virtual address, the operation type, the memory domain identifier, and the address space identifier based on the memory access instruction; and generates the permission verification request based on the target virtual address, the operation type, the memory domain identifier, and the address space identifier.

[0132] The following describes the application of the embodiments of this application in a real-world scenario.

[0133] Hardware virtualization technology is a core supporting technology for computing systems in related technologies. It achieves efficient and secure sharing of computing resources by creating multiple isolated virtual machine instances on physical hardware. In processor architectures such as RISC-V, memory virtualization is a key technology, its core being the implementation of two-level address translation: the first level translates the guest virtual address (GVA) to the guest physical address (GPA), and the second level translates the GPA to the host physical address (HPA). This process is typically completed jointly by the memory management unit (MMU) and the hypervisor.

[0134] Hardware virtualization solutions in related technologies typically employ mechanisms based on shadow page tables or hardware-assisted nested page tables (NPT). In the H extension of the RISC-V architecture, implementation relies on two independent page table traversal processes: the guest MMU handles the GVA to GPA translation, and the host MMU handles the GPA to HPA translation. When a page table is missing or a permission violation occurs, the hardware triggers an exception and traps the virtual machine monitor, which then handles the issue recursively. The entire process exhibits a strictly serial characteristic: address translation and permission verification are performed sequentially, and each page table traversal requires waiting for the result of the previous level; exception handling uses an immediate trap mode, triggering a context switch for each detected fault. While this approach guarantees correctness, it introduces significant performance overhead.

[0135] In related technologies, serial processing leads to structural latency. The sequential execution of permission checks and multi-level page table traversals causes cumulative latency on the critical path, failing to fully utilize hardware parallelism. Secondly, recursive trap mechanisms trigger trap storms; each missing page table can trigger multiple traps from the guest machine to the host machine, with frequent context switching and privilege boundary crossings incurring significant overhead. Finally, deep software involvement in the critical path, requiring the virtual machine monitor to participate in every exception handling, leads to reduced determinism and performance fluctuations. These shortcomings are particularly prominent in I / O-intensive or real-time-critical virtualization scenarios, becoming major bottlenecks restricting virtualization performance improvement.

[0136] Based on the above description, this application provides a hardware virtualization implementation method under the RISC-V architecture, which significantly reduces the nested exception latency in two-level address translation through hardware prediction and parallel processing mechanisms, including the following sequentially executed steps S11 to S15: Step S11: The virtual machine monitor configures a dedicated nested page table structure in the host physical memory, such as... Figure 6 As shown, the steps S601 to S603 are as follows: Step S601: Virtual machine monitoring 61 allocates a host physical memory region 63 for each virtual machine instance during the initialization phase; Steps S602 and S603: Construct the first-level page table and construct the second-level page table; Construct a two-level nested page table structure (such as a first-level page table and a second-level page table). The first-level page table maps the client's virtual address to the client's physical address, and the second-level page table maps the client's physical address to the host's physical address.

[0137] Step S604: Configure a dedicated nested page table base address register group 62 at the hardware level.

[0138] The nested page table base address register group contains the base address pointers of the first-level page table and the second-level page table, as well as a global permission bitmap for both levels of page tables. The global permission bitmap predefines the memory access permission thresholds in guest mode and host mode (triggered when the guest executes sensitive instructions, page faults / exceptions occur, interrupts, etc.) in the form of a bitmask. The nested page table base address register group is directly managed by the hardware, and the virtual machine monitor completes the initialization binding only through a single privileged instruction write.

[0139] During the initialization phase, the virtual machine monitor allocates a contiguous and isolated physical memory region in the host physical memory for each virtual machine instance. Within this region, it constructs a strictly separated two-level nested page table structure. The first-level page table is used to map guest virtual addresses to guest physical addresses, and the second-level page table is used to map guest physical addresses to host physical addresses. The two-level mapping is defined semantically as a deterministic composite address resolution function, expressed as follows: (1); in, This represents the guest virtual address, the virtual memory address generated by programs running inside the virtual machine. This address space is managed by the guest operating system and appears as a contiguous linear address space to applications. This represents the linear address resolution operator determined by the first-level page table base address pointer, using the first-level page table base address register. As the root node, it performs the mapping operation from client virtual addresses to intermediate physical addresses. In hardware, this operator corresponds to a state machine that traverses the client page table (used to translate client virtual addresses to client physical addresses). This represents the physical address resolution operator determined by the base address pointer of the second-level page table. The purpose of this composite function is to provide a unified and unambiguous address translation target for subsequent hardware parallel traversal, so as to obtain the final host physical address.

[0140] Meanwhile, the virtual machine monitor configures a dedicated nested page table base address register set at the hardware level, which includes the first-level page table base address pointer. Second-level page table base address pointer and global permission bitmap , This indicates the sequential combination of two mapping operators, i.e., executing them first. Map, then execute Mapping; For conditional binding symbols, where Memory access permissions are pre-encoded using bitmasks, and the permission determination rules are formalized as follows: ,in This represents the vector of read and write operations carried by memory access instructions. This represents the memory domain identifier to which the target virtual address belongs. It is the result of a static range partitioning of the guest virtual address space by the virtual machine monitor during the initialization phase. It is used to distinguish between code segments, data segments, device-mapped segments, or restricted shared segments. Its encoding method is an N-bit fixed field, which is used as an index input for permission prediction in the hardware. Represents the address space identifier, address space identifier Address space context identifiers maintained by the processor hardware are used to distinguish the address spaces of different virtual machines or different processes. In guest mode, they are uniformly allocated by the virtual machine monitor and written to the hardware status register. The calculation result is the minimum decision set required by the hardware permission prediction unit. The purpose of this formula is to complete a global permission threshold pruning without accessing specific page table entries, thereby reducing the probability of triggering subsequent fine-grained checks. The above-mentioned base address register group is bound through an indivisible privilege write instruction, and the state update process of the base address register group satisfies: (2); in Represents at discrete time points Below is the set of observable states of all hardware registers and caches related to nested address translation. This represents the stable state of the hardware after the state update at the next discrete time point. This refers to privileged write operations. This is the base address pointer of the first-level page table. This serves as the base address pointer to the second-level page table, describing the atomic update process of the nested address translation hardware context in the form of discrete-time state transitions. At time... The virtual machine monitor executes a privileged write instruction. Configure triple parameters Write to the dedicated hardware register set in a one-time, indivisible manner; at time... Hardware status Update complete. The new address translation context is now in effect.

[0141] Global Permission Bitmap It is a three-dimensional logical bitmap, whose index dimension includes at least the memory domain identifier. With operation vector Address space identifier As an optional extension dimension, used to support multi-virtual machine parallel scenarios, the operation vector It is a multi-bit operation attribute encoding generated by the instruction decoding stage, which includes at least three basic access attributes: read, write, and execute, and can be extended to include atomic access or device access flags; This state remains stable during virtual machine operation and is directly managed by the hardware. Its purpose is to eliminate or reduce the frequency of the virtual machine monitor's involvement in the address translation critical path, thereby laying a deterministic and low-latency hardware state foundation for the subsequent synchronous extraction of address and permission information and the triggering of parallel processing during the instruction decoding stage.

[0142] Step S12: The hardware memory management unit embeds a pre-decoding module in the instruction execution pipeline. When the processor executes a memory access instruction for a guest virtual address, the hard-wired pre-decoding module synchronously extracts the target virtual address and operation type during the instruction decoding stage, and generates a corresponding permission verification request vector based on the operation type. This vector contains the memory domain identifier of the virtual address (whether this address belongs to the user area or the kernel area, and whether it can be read / written / executed), the read / write execution permission identifier, and the address space identifier. At the same time, the pre-decoding module sends the permission verification request vector in parallel to the permission prediction unit and the address translation unit, and the generation of the permission verification request and the instruction decoding are completed synchronously within a single clock cycle.

[0143] The specific process of parallel extraction and request vector generation during the instruction decoding stage is as follows: Figure 7 As shown, the process includes the following steps S701 to S705: Step S701: Extract the client virtual address; Step S702: Extract the address space identifier; Step S703: Extract the address space identifier; Step S704: Extract the operation vector; Step S705: Generate a permission verification request vector, and send the permission verification request vector to the address translation unit and the permission prediction unit in parallel. Steps S701 to S703 can be executed in parallel.

[0144] When the processor enters guest mode and obtains the memory access instruction to be executed during the instruction fetch stage, the pre-decoding module embedded in the instruction decoding pipeline performs parallel semantic expansion of the instruction. Within the same clock cycle, the pre-decoding module synchronously extracts the guest virtual address from the instruction operand segment and the address generation logic. Operation vectors and address space identifiers Based on the global hardware state already fixed in step S11, the access semantics are structured and encoded, and the generated permission verification request vector is defined as: (3); in For vector constructors, For permission verification request vector, For operation vector The memory domain identifier, determined jointly with the high-order domain of the virtual address, is constructed with the aim of moving and compressing the permission and address information, which was originally scattered at the back end of instruction execution, into a unified hardware-transferable entity. Memory domain identification function The specific calculations are as follows: (4); This refers to the access type classification extracted from the operation vector O. This refers to the classification of memory regions based on the high-order bits of the client's virtual address. A hardwired combinational logic function maps operation types to address regions as elements in a finite set of field identifiers.

[0145] The above mapping relationships are illustrated in Table 1: Table 1 shows the mapping relationship between operation type, address region, and domain identifier.

[0146] Table 1 shows the mapping relationship table illustrating the memory domain identification function. The mapping logic uses hard-wired combinations to uniquely map the binary input of operation type and address region to a finite field identifier output, thereby providing an efficient index for the global permission bitmap. For example, instruction fetch operations in the user code area are mapped to field identifier 0x1, read and write operations in the user data area are mapped to 0x2, any operation in the device mapping area is mapped to 0x3, and code and data access in the kernel space are mapped to 0x4 and 0x5 respectively. This allows the hardware to complete the semantic classification of memory access during the instruction decoding stage and provide a coarse-grained but fast pre-access control basis for the subsequent permission prediction unit, effectively isolating access behaviors of different security levels such as user mode and kernel mode, and ordinary memory and device mapping area.

[0147] After completion During construction, the pre-decoding module uses the register state from step S11 as a reference. Pre-binding is performed on the address resolution path, and the binding relationship is achieved through the address expansion operator. Expressed as intermediate physical index prediction value ,in This is the base address pointer for the first-level page table. The purpose of this operator is not to generate the final address result, but rather to provide an initial index context aligned with the page table traversal state machine for subsequent address translation units, thereby shortening the startup latency of the actual traversal. Subsequently, the pre-decoding module, without introducing additional pipeline stages, will... The signal is broadcast in parallel to the permission prediction unit and the address translation unit, and synchronized with the valid flag. Complete timing alignment of the two hardware paths, where To ensure that the permission prediction result and the two-level address translation result belong to the same instruction instance and the same address resolution context, the synchronization mechanism is designed to reduce the structural wait introduced by serial permission verification in the two-level address translation, so that permission judgment and page table traversal are strictly parallel in time.

[0148] Step S13: The permission prediction unit and the address translation unit perform real-time verification in parallel.

[0149] The specific process of the parallel execution of the permission prediction unit and the address translation unit can be as follows: Figure 8 As shown, the execution flow of the permission prediction unit may include the following steps S811 to S814: Step S811: Query the global permission bitmap; Step S812: Bitmask comparison; Step S813: Generate permission prediction result; Step S814: Send the permission prediction result to the anomaly aggregation module.

[0150] The execution flow of the address translation unit may include the following steps S821 to S826: Step S821: Traverse the first-level page table from GVA to GPA; Step S822: Detect missing / permission / out-of-bounds errors; Step S823: Traverse the second-level page table from GPA to HPA; Step S824: Detect missing / permission / out-of-bounds errors; Step S825: Generate address translation results; Step S826: Send the address translation results to the exception aggregation module.

[0151] In this embodiment, after receiving the permission verification request vector, the permission prediction unit immediately queries the global permission bitmap in the nested page table base address register group and determines whether the current operation exceeds the predefined permission threshold by comparing the bitmask. At the same time, the address translation unit starts a two-level page table hardware traversal, sequentially resolving the client virtual address to the intermediate physical address using the first-level page table base address pointer, and then resolving the intermediate physical address to the host physical address using the second-level page table base address pointer. During the traversal, page table entries are simultaneously detected for missing entries, permission errors, and address out-of-bounds conditions. The permission prediction result and the address translation result are output to the anomaly aggregation module in parallel within the same hardware clock cycle. After receiving the permission verification request vector synchronously broadcast from the pre-decoding module, the permission prediction unit and the address translation unit enter a parallel working state within the same hardware clock domain. The permission prediction unit, based on the memory domain identifier, operation vector, and address space identifier carried in the request vector, directly accesses the fixed global permission bitmap in the nested page table base address register group and completes a deterministic permission threshold pruning through hard-wired bitmask comparison logic. This pruning process does not involve any page table entry reading; its output only indicates whether the current memory access is within the range allowed by the global permission policy, thus forming a pre-constraint in time before the fine-grained page table permission judgment. Simultaneously, the address translation unit, within the same clock cycle, starts a two-level page table traversal state machine based on the client virtual address carried in the request vector. It first completes the client virtual address traversal using the first-level page table base address pointer as the starting point. The process involves a step-by-step resolution from the address to the intermediate physical address, with simultaneous checks of page table entry presence bits, access permission bits, and address validity flags at each level. If no termination condition is triggered, the resolution continues from the second-level page table base address pointer to the host physical address, maintaining error detection semantics consistent with the first-level traversal. The permission prediction result output by the permission prediction unit and the traversal status result output by the address translation unit are submitted to the exception aggregation module on the same clock edge via a hardware-aligned result bus. Both results share the same instruction instance identifier and address resolution context, ensuring that subsequent exception handling logic can directly perform comprehensive judgment without cross-cycle correlation or result rearrangement, and naturally connects to the non-blocking page fault preloading and exception integration processing flow triggered by the exception aggregation module in the next step S14.

[0152] The comparison of the parallel execution of the permission prediction unit and the address translation unit is as follows: The input source of the permission prediction unit is the permission verification request vector, and the input source of the address translation unit is the permission verification request vector; the key input fields of the permission prediction unit are memory domain identifier, operation vector, and address space identifier, while the key input field of the address translation unit is the guest virtual address; the hardware dependency state of the permission prediction unit is the global permission bitmap in the nested page table base address register group, while the hardware dependency state of the address translation unit is the first-level page table base address pointer and the second-level page table base address pointer; the startup timing of the permission prediction unit is the same hardware clock cycle synchronized with the instruction decoding completion, while the startup timing of the address translation unit is the same hardware clock cycle completely synchronized with the permission prediction unit; the core execution mechanism of the permission prediction unit is the bitmask comparison logic for global permission threshold pruning, while the core execution mechanism of the address translation unit is... The execution mechanism employs a two-level page table traversal state machine that operates in parallel. The permission prediction unit does not access any specific page table entries, while the address translation unit accesses page table entries level by level. The permission prediction unit checks whether the operation exceeds the predefined global permission policy, while the address translation unit checks for missing page table entries, page-level permission errors, and address out-of-bounds errors. The permission prediction unit does not maintain the page table traversal state, while the address translation unit maintains the current level and index of the two-level page table traversal. The output of the permission prediction unit is a permission prediction result flag, and the output of the address translation unit is an address translation result and a traversal state flag. The output timing of both the permission prediction unit and the address translation unit is fixed at the end of the current clock cycle. The outputs of both the permission prediction unit and the address translation unit are directed to the exception aggregation module. Both the permission prediction unit and the address translation unit are bound to the current instruction instance and the address resolution context.

[0153] In this embodiment, the permission prediction unit is a hardware deterministic logic module. Its prediction result is not allowed to result in authorization expansion. It is only used as a pre-pruning condition and does not replace page table permission verification. The exception aggregation module only aggregates the same instruction instance and its derived address resolution context, without crossing instructions or address spaces. The exception encoding information is a fixed-width hardware encoding field, which includes exception type flags, page table level identifiers, and target address index information. Through the above comparison, it can be seen that: First, the permission prediction unit and the address translation unit work in parallel under the same input conditions and timing constraints; Second, the two have strict division of labor in terms of function and do not block each other. One focuses on global permission pruning, and the other focuses on fine address resolution; Third, the two align their output results within the same hardware clock cycle and send them directly to the exception aggregation module.

[0154] Step S14: The exception aggregation module implements non-blocking page fault preloading.

[0155] If the permission prediction unit returns a permission violation or the address translation unit detects a missing page table entry, the exception aggregation module immediately freezes the current pipeline and generates exception encoding information. This encoding integrates the permission error type, the missing page table level, and the target address information. For page table entry missing exceptions, the hardware directly pre-reads the missing page table entry from the host physical memory to a dedicated cache based on the missing level and target address, and updates the page table traversal state machine at the corresponding level. If the pre-read is successful, the address translation process is automatically restarted without triggering a machine mode exception trap. The exception encoding information is only submitted to the exception handling queue when there is a permission error or pre-loading failure.

[0156] Exception aggregation and page fault preloading can be handled as follows: Figure 9 As shown, the process includes the following steps S901 to S909: Step S901: Exception type determination; if the exception type is a missing page table entry, proceed to step S902; if the exception type is a permission violation, proceed to step S908; Step S902: Freeze the pipeline; Step S903: Start page fault preloading; Step S904: Determine if preloading was successful; if yes, proceed to step S905; if no, proceed to step S908; Step S905: Update the page table cache; Step S906: Restart address translation; Step S907: Resume execution flow; Step S908: Generate exception encoding information; Step S909: Send the exception encoding information to the exception handling queue.

[0157] In step S13, after the permission prediction unit and the address translation unit output their results in parallel within the same hardware clock cycle, the exception aggregation module receives the permission prediction result and address translation status result bound to the same instruction instance, and performs unified trimming of exception types according to the hard-wired judgment logic. When the permission prediction result indicates the current operation vector... Beyond the global permission bitmap When the defined access threshold is reached, or when the address translation unit detects a missing page table entry during a two-level page table traversal, the exception aggregation module immediately implements a targeted freeze on the pipeline stage related to the memory access instruction, thereby preventing subsequent instructions from entering an execution path that conflicts with the current address resolution context. Within the same clock domain where the freeze takes effect, the exception aggregation module generates a unique exception encoding information, which is expressed as a request vector. As the indexing benchmark, it integrates permission violation flags, missing page table entry flags, the hierarchy of the missing page table, and the target client's virtual address. This, along with the current intermediate physical address index state, forms a hardware-resolvable exception entity that can fully describe the exception semantics and recovery conditions. When the exception type represented by the exception encoding information is a missing page table entry and does not contain a permission violation flag, the exception aggregation module does not trigger a machine-mode exception trap. Instead, it directly initiates a hardware prefetch operation on the corresponding page table entry from the host physical memory based on the missing page table level and the resolved address index state. The prefetch result is written to a dedicated page table cache structure, and at the same time, it drives the page table traversal state machine at the corresponding level in the address translation unit to complete the state update, restoring it to an intermediate state that can continue to be resolved. After the prefetch operation is successfully completed, the exception aggregation module releases the pipeline freeze control for the current instruction and sends a restart signal to the address translation unit, so that the two-level page table traversal process can automatically continue to execute on the updated state and the whole process does not produce machine mode exception traps. The exception aggregation module submits the exception encoding information to the exception handling queue only when the exception encoding information contains a permission violation flag or the page table entry prefetch operation returns to a failed state. This allows subsequent steps to sort the exceptions according to priority rules and trigger aggregation traps, thereby achieving priority self-healing of page fault exceptions and strict isolation of permission exceptions on the hardware side.

[0158] Step S15: The hierarchical exception queue submits trap events according to priority. After receiving the exception encoding information, the exception handling queue sorts the events according to the preset priority rules. Permission errors take precedence over address translation errors, and errors at the same level are arranged in virtual address order. After sorting, the hardware submits a single aggregated trap signal to the virtual machine monitor. This signal carries a complete context snapshot of the highest priority exception, including the fault address, operation type, and intermediate states of the two-level page table traversal. The virtual machine monitor parses and repairs all associated errors through the single machine mode exception handler. After repair, the hardware automatically restores the guest execution flow.

[0159] After receiving the exception encoding information submitted in step S14, the exception handling queue first performs hierarchical reception and orderly storage based on its embedded exception type flag and page table hierarchy information. This queue does not perform further parsing of the exception semantics, but directly utilizes the fault address and operation vector already embedded in the exception encoding information. Client virtual address Furthermore, the intermediate states of the two-level page table traversal establish a one-to-one correspondence between exception instances and address translation contexts, thereby ensuring a complete and consistent context foundation for subsequent sorting and submission processes. Based on this, the exception handling queue stably sorts all pending exception instances according to a preset and immutable priority pruning rule. The sorting logic explicitly stipulates that permission violation exceptions take precedence over address translation exceptions, and within the same exception category, the order is determined by the page table missing level and the client's virtual address. The exceptions are arranged in ascending order to ensure that the submission order matches the actual address resolution path, thus preventing the virtual machine monitor from processing exceptions across levels or in reverse order during the repair process. After the sorting process is complete, the hardware selects only the highest priority exception instance in the current queue to generate a single aggregated trap signal and submits it to the virtual machine monitor. This trap signal carries a complete snapshot of the exception context, which includes the fault address, operation vector, address space identifier, and intermediate state information of the two-level page table traversal. The remaining low-priority exceptions are resolved and repaired uniformly in the same machine mode exception handler through implicit association with this context. After the virtual machine monitor completes the permission status or page table content update, the hardware automatically resumes the address translation process and continues the guest execution flow based on the repaired context, thereby achieving one-time trapping of multiple exceptions and deterministic recovery.

[0160] This application's embodiments fundamentally eliminate the serial latency and recursive trap overhead in the two-level address translation of related technologies through hardware prediction and parallel processing mechanisms. Specifically, the hardware synchronously extracts address and permission information during the instruction decoding stage and broadcasts it to the parallel unit, enabling global permission pruning and page table traversal to start simultaneously; non-blocking page fault preloading is implemented through an exception aggregation module, allowing most page table missing exceptions to self-heal at the hardware level; finally, a hierarchical exception queue is used to prioritize and trap the remaining exceptions at once, enabling the virtual machine monitor to repair all associated errors with only a single privileged intervention. Through the above hardware and software co-design, key steps such as permission checks, page table traversals, and exception handling on the nested address translation path are transformed from serial to parallel, and from recursive traps to batch repair, significantly reducing the latency and uncertainty of guest memory access.

[0161] This application constructs a deterministic and autonomous hardware virtualization execution environment, significantly reducing the frequency of the virtual machine monitor's involvement in the critical path of address translation. Through a single binding of a dedicated nested page table base address register group, the hardware obtains a stable translation context; the permission prediction unit, based on rapid screening of the global permission bitmap, pre-filters accesses that violate global policies; the address translation unit synchronously detects errors during traversal and aligns the output with the permission prediction results; the exception handling queue aggregates trap events by priority, ensuring the efficiency and correct sequence of the virtual machine monitor's repair actions. Overall, this application's solution transforms nested address translation—a process heavily reliant on software recursion in related technologies—into a deterministic process primarily based on hardware parallel processing and supplemented by software batch repair, thereby achieving virtualized memory access performance approaching that of a physical machine while maintaining security isolation.

[0162] This application provides a processor, such as... Figure 10 As shown, the processor 1000 includes the memory access device 100 described above.

[0163] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0164] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0165] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0166] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the embodiments of this application may all be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the integrated unit may be implemented in hardware or in a combination of hardware and software functional units.

[0167] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0168] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0169] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A memory access device, characterized in that, The memory access device includes a permission prediction unit, an address translation unit, a two-level page table, and a pre-decoding module, wherein: The pre-decoding module is used to synchronously acquire memory access instructions during the decoding stage of the instruction execution pipeline; determine the target virtual address and operation type based on the memory access instructions; determine the memory domain identifier based on the target virtual address and the operation type; and generate a permission verification request based on the target virtual address, the operation type, and the memory domain identifier and send it to the permission prediction unit and the address translation unit. The permission prediction unit is used to determine whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and to generate a permission prediction result based on the determination result. The address translation unit is used to traverse the two-level page table based on the target virtual address to obtain the host physical address, and generate an address translation result based on the host physical address.

2. The apparatus according to claim 1, characterized in that, The pre-decoding module is further configured to determine the memory domain identifier based on the operation type and the high-order domain of the target virtual address; the memory domain identifier is used to identify different address regions in the virtual address space.

3. The apparatus according to claim 1, characterized in that, The memory access device further includes an exception aggregation module and a page table base address register group, wherein the page table base address register group includes a global permission bitmap; The permission prediction unit is used to query the global permission bitmap based on the operation type and the memory domain identifier, determine whether the memory access instruction meets the access conditions, and generate a permission prediction result. Send the permission prediction result to the anomaly aggregation module; The global permission bitmap uses a bitmask to describe the mapping relationship between operation type, memory domain identifier, and address region; the permission prediction result includes permission verification passing or permission verification failing.

4. The apparatus according to claim 1, characterized in that, The memory access device further includes an exception aggregation module, and the two-level page table includes a first-level page table and a second-level page table. The address translation unit is further configured to traverse the first-level page table based on the target virtual address to obtain the intermediate physical address; and traverse the second-level page table based on the intermediate physical address to obtain the host physical address. The address translation unit is further configured to send the address translation result to the anomaly aggregation module, wherein the address translation result includes a host physical address or a page table entry missing error.

5. The apparatus according to claim 4, characterized in that, The memory access device further includes a page table base address register group, which includes a first-level page table base address pointer and a second-level page table base address pointer. The address translation unit is further configured to traverse the first-level page table level by level with the first-level page table base address pointer as the root node, and convert the target virtual address into an intermediate physical address; and query the second-level page table level by level with the second-level page table base address pointer as the root node, and convert the intermediate physical address into the host physical address.

6. The apparatus according to claim 3 or 4, characterized in that, The anomaly aggregation module is used to receive permission prediction results and address translation results in the same clock cycle. If the permission prediction result indicates that the permission verification fails and / or the address translation result indicates that the page table entry is missing or misaligned, the module suspends the address translation process corresponding to the memory access instruction and generates anomaly encoding information. The permission prediction result and the address translation result are sent by the permission prediction unit and the address translation unit in the same clock cycle.

7. The apparatus according to claim 6, characterized in that, The anomaly coding information includes the anomaly type and the anomaly information corresponding to the anomaly type; The exception aggregation module is further configured to, when the exception type includes a page table entry missing error, pre-read missing page table entries from the host physical memory to the target cache based on the missing page table level and the parsed address index status included in the exception information; The anomaly aggregation module is also used to send a pre-read success signal to the address translation unit if the pre-read of the missing page table entry is successful. The address translation unit is further configured to, in response to the pre-fetch success signal, restart the address translation process corresponding to the memory access instruction, and, based on the parsed address index state and the target cache, convert the target virtual address into the host physical address.

8. The apparatus according to claim 7, characterized in that, The exception aggregation module is further configured to submit the exception encoding information to the exception handling queue in the event that the pre-reading of the missing page table entry fails.

9. The apparatus according to claim 6, characterized in that, The exception encoding information includes the exception type; The exception aggregation module is also used to submit the exception encoding information to the exception processing queue when the exception type includes permission verification failure.

10. The apparatus according to claim 8 or 9, characterized in that, The exception handling queue is used to process at least one of the exception codes according to a preset priority; the priority of the exception type "permission verification failure" is higher than the priority of the exception type "page table entry missing error".

11. The apparatus according to claim 1, characterized in that, The permission verification request also includes an address space identifier, which is used to identify the address space corresponding to different virtual machine instances; The pre-decoding module is further configured to determine the target virtual address, the operation type, the memory domain identifier, and the address space identifier based on the memory access instruction; The permission verification request is generated based on the target virtual address, the operation type, the memory domain identifier, and the address space identifier.

12. A memory access method, characterized in that, Applied to a memory access device, the memory access device including a permission prediction unit, an address translation unit, a pre-decoding module, and a two-level page table, the method includes: The pre-decoding module synchronously acquires memory access instructions during the decoding stage of the instruction execution pipeline; determines the target virtual address and operation type based on the memory access instructions; determines the memory domain identifier based on the target virtual address and the operation type; and generates a permission verification request based on the target virtual address, the operation type, and the memory domain identifier and sends it to the permission prediction unit and the address translation unit. The permission prediction unit determines whether the memory access instruction meets the access conditions based on the operation type and the memory domain identifier, and generates a permission prediction result based on the determination result. The address translation unit traverses the two-level page table based on the target virtual address to obtain the host physical address, and generates an address translation result based on the host physical address.

13. A processor, characterized in that, Includes the memory access device as described in any one of claims 1 to 11 above.

Images