A page table request processing method and device, a storage medium and an electronic device

Abstract

The application discloses a page table request processing method and device, a storage medium and an electronic equipment, and relates to the technical field of computers. The method comprises the following steps: obtaining a first page table request and a second page table request; performing request coding processing on the first page table request and the second page table request respectively according to missing request identification information in the first page table request and pre-fetch request identification information in the second page table request, obtaining page table traversal requests corresponding to the first page table request and the second page table request respectively, and sending the page table traversal requests into the same target page table traversal queue; reading a target page table traversal request from the target page table traversal queue, performing page table traversal processing on a target virtual page corresponding to the target page table traversal request, and performing differential processing on an abnormal result of the page table traversal processing according to target request type identification information in the target page table traversal request. The application can reduce hardware resource consumption and simplify control logic.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and electronic device for processing page table requests. Background Technology

[0002] In the Memory Management Unit (MMU) subsystem of high-performance processors and artificial intelligence accelerators, the Translation Lookaside Buffer (TLB) is used to implement fast address translation from Virtual Page Numbers (VPNs) to Physical Page Numbers. When a TLB miss occurs at L1 level, the Hardware Page Walker (HPW) needs to be invoked to access page table entries in memory to complete the address translation. To reduce the probability of subsequent TLB misses, a TLB prefetch request is generated based on the access characteristics, and page table traversal is performed on adjacent virtual pages in advance to pre-fill the TLB with the translation results, thereby reducing access latency.

[0003] In MMU system architectures with multiple L1 TLBs sharing an L2 TLB, existing implementations typically isolate TLB miss requests from TLB prefetch requests, using independent request queues and page table traversal paths to process the two types of requests separately. This architecture requires dedicated queue storage, scheduling arbitration, and path control hardware resources for the prefetch logic, directly increasing chip area overhead. Furthermore, the separate processing of the two types of requests necessitates the implementation of differentiated handling logic, further complicating hardware design and verification. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, storage medium and electronic device for processing page table requests. The main purpose is to solve the technical problems of large hardware area overhead and complex processing logic in the existing schemes that separate TLB missing requests and TLB prefetch requests by using independent queues and independent page table traversal paths.

[0005] Firstly, this application provides a method for processing page table requests, including: Obtain the first page table request and the second page table request. The first page table request is a page table request generated when the virtual page access operation misses in the Translate Back Buffer (TLB), and the second page table request is a page table request generated when the virtual page prefetch operation misses in the TLB.

[0006] Based on the missing request identifier and first request context information in the first page table request, and the prefetch request identifier and second request context information in the second page table request, the first page table request and the second page table request are processed by request encoding according to the field structure of the target page table traversal queue, respectively, to obtain the page table traversal requests corresponding to the first page table request and the second page table request, and the page table traversal requests obtained after request encoding are sent to the target page table traversal queue.

[0007] Read the target page table traversal request from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differentiated processing on abnormal results of page table traversal processing according to the target request type identification information in the target page table traversal request.

[0008] Secondly, this application provides a page table request processing apparatus, comprising: The acquisition module is configured to acquire a first page table request and a second page table request. The first page table request is a page table request generated when a virtual page access operation misses in the Translate Back Buffer (TLB), and the second page table request is a page table request generated when a virtual page prefetch operation misses in the TLB.

[0009] The encoding module is configured to perform request encoding processing on the first page table request and the second page table request respectively, according to the field structure of the target page table traversal queue, based on the missing request identifier information and the first request context information in the first page table request, and the prefetch request identifier information and the second request context information in the second page table request, to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and send the page table traversal requests obtained after request encoding processing into the target page table traversal queue.

[0010] The processing module is configured to read target page table traversal requests from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differentiated processing on abnormal results of page table traversal processing based on the target request type identifier information in the target page table traversal request.

[0011] Thirdly, this application provides a computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the page table request processing method as described in the first aspect above.

[0012] Fourthly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the page table request processing method described in the first aspect.

[0013] By employing the above technical solutions, this application provides a page table request processing method, apparatus, storage medium, and electronic device. Compared with existing technologies, this application encodes the first page table request generated by TLB missing and the second page table request generated by prefetching and sends them into the same target page table traversal queue, reusing the same queue and page table traversal processing link, thereby reducing hardware resource consumption and chip area overhead. Furthermore, in a unified page table traversal processing flow, this application completes differentiated abnormal result processing based on the target request type identification information carried by the page table traversal request, simplifying control logic and reducing the difficulty of hardware design and verification. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a page table request processing method provided in an embodiment of this application is shown. Figure 2 This illustration shows a flowchart of a page table traversal and differential processing of abnormal results provided in an embodiment of this application; Figure 3 This illustration shows a schematic diagram of the framework of a page table traversal request processing system provided in an embodiment of this application; Figure 4 This illustration shows a schematic diagram of a parent directory boundary splitting process for a continuous virtual page range provided in an embodiment of this application; Figure 5 A schematic diagram of a page table request processing apparatus provided in an embodiment of this application is shown. Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0017] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0018] The embodiments of this application can be applied to page table request processing scenarios in processors or AI accelerators configured with MMUs. They are particularly suitable for page table request processing scenarios where multiple L1 TLBs share an L2 TLB, and where both TLB miss requests and TLB prefetch requests exist simultaneously.

[0019] The Memory Management Unit (MMU) is a hardware submodule within the processor and AI accelerator responsible for translating virtual memory addresses into physical memory addresses. The virtual memory space is divided into several fixed-size virtual pages, identified by virtual page numbers (VPNs); virtual memory addresses belong to their corresponding virtual pages. The MMU maintains page tables to store the mapping relationship between virtual pages and physical pages.

[0020] A TLB access request is an access request generated when the arithmetic unit initiates a memory access. It is used to query the virtual page-to-physical page mapping entries within the TLB. This request carries the virtual page information to be translated and is handed over to the TLB to perform the mapping lookup. The TLB caches a portion of the virtual page-to-physical page mapping to accelerate address translation. For this TLB access request, if the TLB contains a mapping entry for the corresponding virtual page, a direct hit occurs, and the physical address is quickly output; if the TLB does not contain a mapping entry for the virtual page, a TLB miss is triggered, thus generating a corresponding page table request within the MMU.

[0021] Depending on the source of the request, the page table request is divided into TLB miss requests triggered by actual memory access of the arithmetic unit, and TLB prefetch requests actively generated by the prefetch logic. Among them: A TLB miss request is a page table request generated when a TLB miss occurs during a real read, write, or memory access operation by the arithmetic unit, corresponding to the actual data access behavior. A TLB prefetch request is a page table request generated when the prefetch logic predicts the virtual pages to be accessed based on access flow characteristics, actively initiates a TLB query, and a miss occurs; it belongs to the performance optimization category. In this embodiment, when a real TLB miss occurs and generates a TLB miss request, the prefetch logic often identifies that the current access has continuous access characteristics. While processing the current miss request, it generates prefetch behavior for several adjacent virtual pages, thus generating corresponding TLB prefetch requests. Therefore, there will be a TLB miss request corresponding to the real access, and multiple TLB prefetch requests for adjacent virtual pages derived from the miss. Although the two types of requests are generated at similar times, their business semantics are not the same: a TLB miss request originates from a real access, and a traversal failure requires reporting an exception; while the TLB prefetch requests corresponding to adjacent pages only perform performance optimization, and traversal failures do not trigger synchronization exceptions. Existing solutions set up separate queues and traversal paths for these two types of requests, which leads to problems such as large hardware area overhead and complex control logic.

[0022] To address the issues of high hardware footprint and complex processing logic in existing schemes that separate TLB miss requests and TLB prefetch requests using independent queues and page table traversal paths, this embodiment provides a method for processing page table requests, such as... Figure 1 The diagram shows a flowchart of a page table request processing method, which includes: S101, Obtain the first page table request and the second page table request.

[0023] The first page table request is generated when a virtual page access operation misses a request in the Translated Back Buffer (TLB), and the second page table request is generated when a virtual page prefetch operation misses a request in the TLB. For example, the first page table request is also a TLB miss request, and the second page table request is also a TLB prefetch request.

[0024] In this embodiment, the arithmetic unit initiates a real memory access and performs a TLB query. When the TLB query fails, a first page table request is generated. The prefetch logic predicts the virtual pages to be accessed and actively initiates a TLB query. When the TLB query fails, a second page table request is generated. For example, in a hardware implementation of a multi-level TLB architecture, the TLB query request sequentially passes through the L1 TLB and the shared L2 TLB. If both the L1 TLB and L2 TLB fail, a corresponding page table request is generated.

[0025] For example, requests that fail to hit at both levels are output to the request unification unit via the shared L2 TLB within the MMU, thereby completing the acquisition of the first and second page table requests. For example, the arithmetic unit issues a virtual page query request. The L1 TLB cluster receives and responds to this query. If the L1 TLB query hits, the L1 TLB directly returns the address translation result and does not pass the request further. If the L1 TLB query fails, the query request is received and responded to by the shared L2 TLB. If the shared L2 TLB query hits, the L2 TLB directly returns the address translation result and does not output the request further. If the shared L2 TLB query fails, the shared L2 TLB sends the request (first page table request) to the request unification unit. Furthermore, when the current access is identified as having continuous access characteristics, the prefetch logic generates a prefetch query request for the adjacent virtual page of the first page table request virtual page. This prefetch query request is also queried sequentially through the L1 TLB cluster and the shared L2 TLB. If the query fails in both L1 TLB and the shared L2 TLB, a second page table request is formed and sent to the request normalization unit.

[0026] In one example, where a real access has already resulted in both L1 TLB and shared L2 TLB misses, and the prefetch logic identifies that the access has consecutive access characteristics, the prefetch query request can bypass the L1 TLB cluster and shared L2 TLB lookups and be directly sent as a second page table request along with the first page table request to the request normalization unit. This approach eliminates the need for repeated TLB lookups on adjacent virtual pages, further reducing path power consumption and latency.

[0027] S102. Based on the missing request identifier and first request context information in the first page table request, and the prefetch request identifier and second request context information in the second page table request, according to the field structure of the target page table traversal queue, the first page table request and the second page table request are processed by request encoding respectively to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and the page table traversal requests obtained after request encoding are sent to the target page table traversal queue.

[0028] In this embodiment, the missing request identifier information is used to characterize that the page table request originates from a TLB missing due to a real memory access; the prefetch request identifier information is used to characterize that the page table request originates from a prefetch operation initiated by prefetch logic. For example, the missing request identifier information and the prefetch request identifier information can be category flag bits recorded in specific fields within the request (e.g., the service_class field). Different values ​​of these flag bits distinguish whether the request belongs to a real missing request or a prefetch request. For example, service_class=1 indicates that the request is a TLB missing request, corresponding to a first page table request originating from a real TLB missing request. service_class=0 indicates that the request is a TLB prefetch request, corresponding to a second page table request originating from a prefetch operation.

[0029] In this embodiment, the first request context information includes the virtual page number, access attributes, request source identifier, address space identifier, and number of consecutive pages corresponding to the first page table request. The second request context information includes the virtual page number, access attributes, request source identifier, address space identifier, and number of consecutive pages corresponding to the second page table request.

[0030] In this embodiment, when encoding the first page table request, the missing request identifier information and the first request context are encoded into the corresponding page table traversal request. When encoding the second page table request, the prefetch request identifier information and the second request context are encoded into the corresponding page table traversal request. After encoding, the first and second page table requests generate page table traversal requests with the same format, and the two are distinguished by the identifier information carried within the request.

[0031] In this embodiment, after obtaining the first page table request and the second page table request, the request normalization unit inside the MMU performs request encoding processing based on the missing request identifier information, the first request context, the prefetch request identifier information, and the second request context. For example, the request normalization unit encodes the page table request according to a unified HPW request format (i.e., the field structure of the target page table traversal queue). This unified HPW request format is the input format adapted to the target page table traversal queue, and the encoded page table traversal request can be directly written into the queue item of the unified HPW request queue.

[0032] S103. Read the target page table traversal request from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differentiated processing on the abnormal results of the page table traversal processing according to the target request type identification information in the target page table traversal request.

[0033] In this embodiment, the HPW inside the MMU reads target page table traversal requests from the target page table traversal queue (unified HPW request queue) and performs page table traversal processing. The HPW reads target page table traversal requests in the ready state in the queue, initiates a page table memory read operation, traverses the page table level by level, and parses out the page table entries corresponding to the target virtual page. For example, based on the multi-level page table index field within the target virtual page, the HPW starts from the root page table base address and sequentially reads page table entries at each level, extracting the physical base address of the next level page table until it reads the lowest level page table, thus parsing out the physical address and page table attributes corresponding to the target virtual page.

[0034] In this embodiment, HPW distinguishes request types based on the target request type identifier information carried in the target page table traversal request and performs differentiated processing on abnormal results. Specifically, for TLB missing requests, when an abnormal page table traversal occurs, the abnormal context information is saved and a page fault is reported, which is then handled by the host. For TLB prefetch requests, when an abnormal page table traversal occurs, no page fault is reported to the host, and the prefetch result is directly discarded. The abnormal context information includes, for example, the virtual page address corresponding to the time of the abnormality, the current level of the page table traversal, and the abnormality type flag.

[0035] Compared to existing technologies, this application encodes the first page table request generated by TLB missing and the second page table request generated by prefetching and sends them to the same target page table traversal queue, reusing the same queue and page table traversal processing link. This avoids configuring separate queues and separate traversal paths for the two types of requests, reducing hardware resource consumption and chip area overhead. Furthermore, within a unified page table traversal processing flow, this application completes differentiated exception result processing based on the target request type identifier information carried by the page table traversal request, eliminating the need to maintain two independent sets of complete processing logic, simplifying control logic, and reducing the difficulty of hardware design and verification.

[0036] The page table request processing method provided in the embodiments of this application will now be described in detail.

[0037] Optionally, this application also provides an embodiment of request encoding processing. In this embodiment, first request context information of the first page table request and second request context information of the second page table request are extracted; based on the first request context information and missing request identifier information, and according to the corresponding field structure of the page table traversal queue, the first page table request is processed by request encoding to obtain the page table traversal request corresponding to the first page table request; based on the second request context information and prefetch request identifier information, and according to the corresponding field structure of the page table traversal queue, the second page table request is processed by request encoding to obtain the page table traversal request corresponding to the second page table request.

[0038] In this embodiment, the request normalization unit within the MMU parses and extracts the first request context information from the received first page table request. Similarly, the request normalization unit parses and extracts the second request context information from the received second page table request.

[0039] In this embodiment, the field structure corresponding to the page table traversal queue is a unified HPW request format. This field structure is a predefined data structure that matches the queue item storage format of the unified HPW request queue, and includes fields such as virtual page number, access attribute, request source identifier, address space identifier, number of consecutive pages, and request category flag. The request normalization unit fills the extracted first request context information and missing request identifier information into the corresponding field positions of this field structure to generate the page table traversal request corresponding to the first page table request; similarly, it fills the second request context information and prefetch request identifier information into the corresponding field positions of this field structure to generate the page table traversal request corresponding to the second page table request.

[0040] This application embodiment maps the context information of TLB missing requests and TLB prefetch requests to the same set of HPW request field structures, enabling the two types of requests to reuse the same page table traversal queue and HPW hardware traversal path. This eliminates the need to design a dedicated data format and storage structure for prefetch requests, reducing hardware resource overhead. At the same time, it fully preserves the context and request category semantics of the two types of requests, facilitating subsequent HPW to execute differentiated traversal results and exception handling based on the request category.

[0041] Optionally, before sending page table traversal requests into the same target page table traversal queue, this application also provides an embodiment for merging page table traversal requests. In this embodiment, based on the request context information and request type identifier information in each page table traversal request, it is determined whether each page table traversal request meets the merging conditions from the dimensions of address contiguity, attribute matching, and request type; the page table traversal requests that meet the merging conditions are then processed by request merging to obtain the merged page table traversal request.

[0042] In this embodiment of the application, the merging conditions must simultaneously meet the requirements of the address continuation dimension, attribute matching dimension, and request type dimension. Wherein: Satisfying the address continuation dimension means that the virtual page addresses of the two page table traversal requests to be merged are consecutive, that is, the ending virtual page number of one request is equal to the starting virtual page number of the other request.

[0043] Satisfying the attribute matching dimension means that the access attributes, address space identifiers, and target L1 TLB sets of the two page table traversal requests to be merged are all the same; among them, the access attributes include read, write, execute, and privileged access attributes, and the target L1 TLB set represents the L1 TLB cluster unit that the request needs to backfill.

[0044] Meeting the request type dimension means that the two page table traversal requests to be merged must include TLB missing requests and TLB prefetch requests, and the TLB missing requests must be at the beginning of the address sequence, with all subsequent requests being TLB prefetch requests.

[0045] In this embodiment, when two or more page table traversal requests simultaneously meet all the above merging conditions, the normalization request unit performs request merging processing. For example, request A is a TLB missing request, starting virtual page is VPN0, and the number of consecutive pages is 1; request B is a pure prefetch request, starting virtual page is VPN1, and the number of consecutive pages is M; request C is a pure prefetch request, starting virtual page is VPN1+M, and the number of consecutive pages is N. The three requests have consecutive virtual pages, identical access attributes, address space identifiers, and target L1 TLB sets, and only the first request A is a TLB missing request, while requests B and C are both prefetch requests. Therefore, the three requests are merged to generate a merged page table traversal request: the starting virtual page of the merged request is VPN0, the number of consecutive pages is updated to 1+M+N, the request category marker is set to the request category carried by the request page for subsequent prefetching (DEMAND_WITH_PREFETCH), and it inherits the access attributes, address space identifier, and target L1 TLB set information of the TLB missing request. After the merge is completed, only the merged page table traversal request is output, and the original multiple independent requests are no longer passed on. If any condition is not met, the merge is not performed, and each request continues to be processed in its original form.

[0046] This embodiment of the application reduces the number of request entries sent to the unified HPW request queue by merging a single TLB missing request that meets the conditions with one or more subsequent consecutive prefetch requests into a single page table traversal request. This reduces the overhead of queue entry allocation, release, and hardware arbitration. After merging, only one queue entry is needed to describe [the actual missing page + multiple consecutive prefetch pages]. After processing the first actual missing page, HPW automatically switches to prefetch semantic processing for subsequent pages, reducing the number of hardware state machine switches and saving hardware storage and control logic resources.

[0047] In some implementations, when merging page table traversal requests, this application can also support other combinations under the request type dimension. Provided that address contiguousness and attribute matching are satisfied, it can extend to various mixed combinations that simultaneously include TLB missing requests and TLB prefetch requests, and also supports merging requests of the same type: for example, merging multiple consecutive TLB prefetch requests; or a combination where the TLB missing request comes first and the TLB prefetch request comes second; or a combination where the prefetch request comes first and the TLB missing request immediately follows; or merging mixed requests that simultaneously contain multiple TLB missing segments and multiple TLB prefetch segments arranged alternately.

[0048] Optionally, before sending page table traversal requests into the same target page table traversal queue, this application also provides an embodiment for splitting page table traversal requests. In this embodiment, based on the request context information in each page table traversal request, page table traversal requests whose virtual page address range belongs to multiple parent directories are determined from each page table traversal request; the page table traversal requests to be split are split based on the address boundaries of the parent directories to obtain multiple sub-page table traversal requests.

[0049] In this embodiment, the parent directory is an intermediate-level page table in a multi-level page table structure, excluding the leaf page tables. It stores the physical base address of the next-level page table but does not store the physical page mapping corresponding to the final virtual page. The address boundary of the parent directory is the end point of the virtual address range that the same parent directory can govern. When a virtual page number crosses this boundary, the virtual page needs to query another parent directory. For example, for a four-level page table, the second-level page table is the parent directory relative to the leaf page table. A parent directory entry governs a fixed number of consecutive virtual pages. When the requested virtual page range crosses the end point of this governed range, that is, crosses the address boundary of the parent directory.

[0050] In this embodiment, the splitting process is performed by the directory boundary splitting unit within the MMU. Specifically, the directory boundary splitting unit reads the starting virtual page number and the number of consecutive pages from the page table traversal request, and calculates the ending virtual page number covered by the request; it combines the starting traversal level corresponding to the current page table traversal request to calculate the address boundary corresponding to the parent directory of that level; it determines whether the virtual page range of the request crosses the parent directory address boundary. If it does, the original request is split into two sub-page table traversal requests, using the parent directory address boundary as the splitting point; the cross-boundary judgment is recursively performed on the split sub-page table traversal requests until the virtual page range covered by each sub-page table traversal request falls entirely within the jurisdiction of the same parent directory; each split sub-page table traversal request inherits all context information of the original request, including the request category marker, access attributes, address space identifier, and target L1 TLB set. If the virtual page range of the request does not cross the parent directory address boundary, the splitting is not performed, and the original page table traversal request is directly passed forward (merged with other page table traversal requests or enqueued).

[0051] This application embodiment ensures that the virtual page range corresponding to each subpage table traversal request sent to the unified HPW request queue does not cross the parent directory boundary by performing pre-splitting based on the parent directory boundary before enqueuing; during the processing of requests in the queue, the serial HPW traverser does not need to split the requests again or switch the parent directory context midway, simplifying the internal state machine logic of HPW, reducing the context switching overhead during traversal, and improving the timing stability of page table traversal processing.

[0052] Optionally, this application also provides an embodiment for performing page table traversal processing and applying differentiated processing to abnormal results of page table traversal processing based on the target request type identifier information in the target page table traversal request. For example... Figure 2 The flowchart shown illustrates a process for differentiated handling of page table traversal and exception results, including: S201. Based on the virtual page address of the target virtual page in the target page table traversal request, access the page table in memory to perform a page table traversal lookup and obtain the page table traversal result corresponding to the target virtual page.

[0053] In this embodiment, HPW, based on the target virtual page address, starts from the root page table at the memory location pointed to by the physical base address of the root page table stored in the configuration register, and reads the intermediate page tables and leaf page table entries at each level in memory step by step to obtain the page table traversal result. For example, the page table traversal result includes information on each level of intermediate page tables, the leaf page table entry corresponding to the target virtual page, and a status flag indicating whether an error occurred during the page table read.

[0054] For example, for unprocessed single page table traversal requests, there are two scenarios: unsplit single requests and split subpage table traversal requests. For a single page table traversal request that is not split, the request carries the current unprocessed virtual page number (curr_vpn) and the remaining number of unprocessed pages (len_remain). The request contains one or more consecutive virtual page numbers (VPNs), and the overall address range of the request does not cross the parent directory boundary. HPW reads curr_vpn from the request and uses this virtual page number as input to start the complete page table traversal process. After completing the translation of the current virtual page, it updates curr_vpn and len_remain inside the request and continues to process the next virtual page in the request, repeating the process until all virtual pages in the current request have been processed.

[0055] For subpage table traversal requests obtained after splitting, each subpage table traversal request also maintains curr_vpn and len_remain. All virtual page numbers in the subpage request are constrained within the same parent directory. Within this subpage request, HPW advances the page table traversal page by page based on curr_vpn. During processing, there is no need to perform parent directory boundary checks or switch to other parent directories. When the len_remain of this subpage request decreases to 0, it means that all virtual pages of the subpage request have been processed, and HPW then schedules the next subpage table traversal request.

[0056] In another example, the merged page table traversal request is obtained by merging a TLB missing request with one or more prefetch requests. Internally, the request maintains `curr_vpn`, `len_remain`, and a true missing flag (`is_demand`), carrying a range of consecutive virtual page numbers (VPNs). HPW reads `curr_vpn` from the merge request and first performs a full page table traversal on the virtual pages corresponding to the true missing headers. After processing the true missing header virtual pages, the hardware automatically clears `is_demand`, and subsequent virtual pages for this request automatically switch to prefetch processing semantics. Then, `curr_vpn` and `len_remain` are continuously updated, and the page table traversal of the remaining virtual pages is completed sequentially within this merge request until `len_remain` decreases to 0, ending the processing of this merge request. The entire process reuses the same root page table base address context, eliminating the need to reread the root page table configuration register.

[0057] S202. Perform integrity checks on the leaf page table entries in the page table traversal results.

[0058] In this embodiment, integrity verification is an HPW-based process that checks the legality and permissions of leaf page table entries returned by page table traversal to determine whether the leaf page table entry is valid and matches the access requirements of the current page table traversal request. For example, integrity verification includes, but is not limited to, the following checks: 1. Valid Bit Check: Checks whether the valid bit of a leaf page table entry is set to determine if the entry is a valid mapping. For example, if the valid bit of a leaf page table entry is 0, it means that the virtual page has not been mapped to physical memory, and the check fails.

[0059] 2. Page Table Entry Format Validation: This function validates the format fields of leaf page table entries to confirm that the entry is a leaf page table entry and not an intermediate parent directory page table entry. It also verifies whether the page size field conforms to the page table format specifications supported by the hardware. For example, in a four-level page table mechanism, if a leaf page table entry should be parsed, but the read entry still points to a lower-level page table directory, the format validation fails. Similarly, if the page size field encoding is a reserved encoding not supported by the hardware, the validation also fails.

[0060] 3. Access Permission Verification: The read, write, and execute access permissions recorded in the leaf page table entry are compared with the access attributes carried in the page table traversal request to determine whether the current access operation is permitted. For example, if the leaf page table entry is only configured with read permission, but the current page table traversal request is for write access, the permission comparison will fail, and the integrity verification will fail.

[0061] 4. Privilege Level Verification: This function verifies whether the privilege access level of the page table traversal request matches the permission attributes of the leaf page table entry to prevent unauthorized access. For example, if a leaf page table entry restricts access only to kernel privileged mode, and the request originates from a user in non-privileged mode, the privilege level verification will fail.

[0062] If any of the above checks fails, the integrity check is deemed to have failed; if all checks pass, the integrity check is deemed to have passed.

[0063] S203. If the integrity check fails, determine that there is an anomaly in the page table traversal result, and perform differentiated processing on the abnormal result of the page table traversal based on the target request type identifier information in the target page table traversal request.

[0064] In this embodiment, HPW reads the request type identifier information inside the target page table traversal request and distinguishes between TLB missing requests and TLB prefetch requests to execute different exception handling logic. If the target request type identifier is DEMAND_WITH_PREFETCH, HPW saves the exception context information corresponding to this exception. The exception context information includes the curr_vpn corresponding to the exception, the page table traversal level, the exception failure type flag, etc.; sets the status of the corresponding queue entry in the unified HPW request queue to the exception status (EXCEP), stops the subsequent VPN traversal processing of the queue entry; reports the page failure exception to the host, waits for the host to read the exception context and complete the exception recovery processing, and the queue entry can only be released and reused after the host clears the exception status.

[0065] If the target request type identifier is a prefetch request type identifier (PREFETCH), HPW does not report a page fault exception to the host and does not trigger the host's exception handling process. Instead, it executes one of two optional processing branches: first, it directly discards the traversal results of the current leaf page table entry without backfilling any entries to the TLB; second, it generates an invalid page table entry with a valid bit of 0 and backfills it to the L1 TLB. When subsequent real-world business access hits this TLB entry with valid=0, a new TLB missing request is initiated, and a complete page table traversal and permission verification are performed again.

[0066] This application embodiment performs differentiated exception routing for leaf page table entry verification failures based on request type identifiers. For real access scenarios with missing TLBs, a complete exception reporting mechanism is retained to ensure that errors in business access can be captured and processed by the host. In prefetch scenarios, verification exceptions are silently digested to avoid false exception reports generated by prefetching interfering with the operation of the operating system. At the same time, retry capability is retained through invalid TLB entries with valid=0, balancing system reliability and prefetch performance benefits.

[0067] Optionally, this application also provides a specific embodiment for performing differentiated processing on abnormal results of page table traversal processing. In this embodiment, based on the target request type identifier information in the target page table traversal request, the access type of the target virtual page that failed the integrity check is determined; if the access type of the target virtual page is a missing request, the abnormal context information is saved, and page table traversal processing for other virtual pages in the target page table traversal request is stopped; if the access type of the target virtual page is a prefetch request, an invalid prefetch identifier is generated or the page table traversal result is discarded; and page table traversal processing continues for the unprocessed virtual pages in the target page table traversal request.

[0068] In this embodiment, the logic is executed by HPW. When the integrity check fails, HPW parses the request type identifier within the target page table traversal request to distinguish between TLB missing requests and TLB prefetch requests. When the access type is a TLB missing request: the exception context information is saved, for example, the exception context information includes the curr_vpn where the exception occurred, the current page table traversal level, and the exception failure type flag; at the same time, the status of the corresponding queue item is set to EXCEP, directly terminating the traversal process of the remaining virtual pages for this request, and no longer advancing curr_vpn and len_remain, waiting for the host to read the exception information and clear the exception status before the queue item can be released.

[0069] When the access type is a TLB prefetch request: HPW generates an invalid prefetch flag with valid=0 to fill the TLB, or directly discards the results of this page table traversal. Then, it continues to process the remaining unprocessed virtual pages in this request until all VPNs in this request have been processed.

[0070] For example, the merged target page table traversal request includes TLB missing requests and TLB prefetch requests. If the integrity check of the target virtual page with a header belonging to the TLB missing type passes, the address translation result corresponding to the page is backfilled into the TLB, and the is_demand flag inside the queue item is cleared. After the flag is cleared, all unprocessed virtual pages following this request are automatically identified as prefetch access types. After each subsequent virtual page traversal check passes, a corresponding prefetch TLB item is generated and written to the TLB, continuously updating curr_vpn and len_remain, and processing all remaining virtual pages in sequence.

[0071] If the integrity check of the target virtual page with a header belonging to the TLB missing type fails, the exception context is saved, the queue item status is set to EXCEP, the entire merge request is terminated directly, and the virtual pages of the subsequent prefetched segment will no longer be traversed.

[0072] If the missing pages in the header TLB have been processed, and upon entering the prefetch section, if the integrity check of a prefetched virtual page passes, a prefetch TLB entry is generated normally to complete the backfilling, and processing continues. If the integrity check of a virtual page in the prefetch section fails, an invalid prefetch flag is generated or the traversal result is discarded directly. This does not trigger a host exception or stop the entire request; the remaining virtual pages within this request are then processed.

[0073] This application's embodiments distinguish between the abnormal subsequent behaviors of missing requests and prefetch requests. When a true missing request fails, the entire request is immediately stopped to prevent erroneous memory translation behavior from continuing to execute, thus ensuring the security of business access. When a prefetch fails, only the currently erroneous page is processed, without interrupting the execution of the entire request, fully leveraging the performance benefits of continuous range prefetching and achieving isolation between the two types of abnormal request behaviors.

[0074] Optionally, this application also provides an embodiment for differentiated processing of page table traversal results that have passed integrity verification. In this embodiment, if the integrity verification passes, the address translation result corresponding to the leaf page table entry is obtained; the access type of the target virtual page is determined according to the target request type identifier information in the target page table traversal request; if the access type of the target virtual page is a missing request, the address translation result is written to the TLB; if the access type of the target virtual page is a prefetch request, a prefetch TLB entry is generated based on the address translation result, and page table traversal processing continues to be performed on the unprocessed virtual pages in the target page table traversal request.

[0075] In this embodiment, this step is performed collaboratively by the HPW and the TLB backfilling path. After the integrity check passes, the HPW parses the address translation result from the leaf page table entry. The address translation result includes information such as virtual page number, physical page number, page granularity, and access permissions.

[0076] Afterwards, HPW reads the access type identifier corresponding to the current virtual page. When the access type is a missing request, it writes the address translation result as a formal TLB entry into the target L1 TLB. After the backfill is completed, the original memory access request blocked due to the TLB missing is released.

[0077] For page table traversal requests of the merge type, after the missing pages in the header are filled, the hardware automatically clears the is_demand flag in the queue entry, and subsequent virtual pages automatically switch to the prefetch type. When the access type is a prefetch request, a prefetch TLB entry is generated based on the address translation result and written to the target L1 TLB. The prefetch TLB entry is used to cache address mapping relationships in advance. The hardware updates curr_vpn and len_remain in the queue entry, and continues to traverse and process the remaining unprocessed virtual pages in this request without waiting for blocked access requests.

[0078] For example, the merged target page table traversal request includes TLB missing requests and TLB prefetch requests. If the integrity check of the target virtual page with a header belonging to the TLB missing type passes, the address translation result corresponding to the page is backfilled into the TLB, and the is_demand flag inside the queue item is cleared. After the flag is cleared, all unprocessed virtual pages following this request are automatically identified as prefetch access types. After each subsequent virtual page traversal check passes, a corresponding prefetch TLB item is generated and written to the TLB, continuously updating curr_vpn and len_remain, and processing all remaining virtual pages in sequence.

[0079] This application implements differentiated TLB backfilling logic based on access type for verified page table traversal results. For missing requests, it wakes up blocked real memory access requests while backfilling the TLB, ensuring timely response to business accesses. For prefetch requests, it prefills the TLB in batches, reducing the probability of TLB missing in subsequent real accesses and improving system memory access throughput. In this way, missing requests and prefetch requests reuse the same HPW traversal and TLB backfilling hardware path, reducing the design overhead of independent hardware paths and saving chip area.

[0080] Referring to the above embodiments, this application also provides a page table traversal request processing system. For example... Figure 3 The diagram illustrates the framework of a page table traversal request processing system. The system includes a request normalization unit, a directory pre-splitting unit, a unified HPW request queue (i.e., a target page table traversal queue), and a serial HPW traverser (hardware page table traverser HPW). The system is connected to an L1TLB cluster, a shared L2TLB / PTECache (secondary page table entry cache), and a page table memory AXI read interface.

[0081] The request normalization unit receives unified requests output from the shared L2TLB / PTECache. These unified requests are generated when the L1TLB cluster (L1TLB-0, L1TLB-1...L1TLB-N) initiates a TLB miss request or a TLB prefetch request, and both the L1TLB and the shared L2TLB / PTECache caches fail. The unit uniformly encodes the received raw requests, converting them into page table traversal requests with a uniform format. Based on the request context and request type, the request normalization unit comprehensively determines the request merging conditions from the dimensions of address continuity, access attribute consistency, and request type. It merges single-page true TLB miss requests with consecutive addresses and matching attributes with subsequent adjacent pure prefetch requests into a single DEMAND_WITH_PREFETCH type page table traversal request. Requests that do not meet the merging conditions are output independently. Finally, the normalized and merged unified page table traversal request is output to the directory pre-splitting unit.

[0082] The directory pre-splitting unit is connected to the request normalization unit. It receives page table traversal requests after normalization and determines whether the current request crosses the intermediate directory address boundary of a multi-level page table based on the virtual page range carried in the request and the parent directory boundary information corresponding to the page table level. For cross-boundary requests, the directory pre-splitting unit recursively splits the request using the parent directory address boundary as the dividing point, generating multiple sub-page table traversal requests. This ensures that the VPN scope of each sub-request strictly belongs to the jurisdiction of a single parent directory, and the sub-request fully inherits all context information of the original request, including access attributes, address space identifier, request type, and target L1TLB set. For requests that do not cross boundaries, the request is directly passed through.

[0083] like Figure 4 This diagram illustrates a process for splitting the parent directory boundary of a continuous virtual page range. The directory pre-splitting unit receives a unified HPW request from the request normalization unit, reads the starting virtual page number V and the range length N of the request. The continuous VPN range of this request is starting VPN = V, containing a total of N continuous virtual pages. The endpoint of the virtual page range, vpn_end = V + N, is calculated. The starting VPN and endpoint VPN are shifted right by a directory shift amount (dir_shift), and their parent directory indices are compared, i.e., (vpn_start >> dir_shift) and (vpn_end >> dir_shift) are checked for equality. This determines whether the VPN range of the current request crosses the parent directory boundary. If they are equal, it means that all virtual pages in the request fall within the jurisdiction of the same parent directory and do not cross the parent directory boundary. A single queue request (entry) is generated, the ending virtual page number (range_end_vpn) of the virtual page range corresponding to this queue entry is set, and it is directly sent to the unified HPW request queue. If the two are not equal, it means that the request crosses the parent directory boundary. Then, calculate the maximum continuous virtual page length k1 that can be accommodated in the current parent directory and generate two sub-requests: sub-request 0 covers the range [V, V+k1], and sub-request 1 covers the remaining range [V+k1, V+N]. Sub-request 1 recursively executes the above boundary judgment logic and continues to split until all sub-requests satisfy the condition that a single entry belongs to only one parent directory. All processed sub-requests are sent to the unified HPW request queue.

[0084] The splitting logic for the directory pre-splitting unit is calculated in real-time using virtual page numbers during the enqueue phase. Based on the fixed directory shift amount (dir_shift) of the page table architecture, it is independent of the 4KB, 2MB, and 1GB physical page granularity ultimately mapped by the leaf page table. The splitting behavior is not affected by the large page or small page mapping type. By comparing the parent directory index corresponding to the request's starting and ending virtual page numbers, cross-boundary scenarios can be accurately identified and the splitting can be completed. After splitting, each queue entry in the unified HPW request queue corresponds to only a single parent directory range. During the traversal of a single entry, the serial Walker does not need to perform boundary judgment again, dynamically split requests, or switch parent directory contexts, effectively simplifying the backend traversal hardware logic.

[0085] The unified HPW request queue is connected to the directory pre-splitting unit. It is used to cache various page table traversal requests to be processed and to complete hardware arbitration scheduling. It can simultaneously accept unsplit independent requests, sub-requests generated by splitting, and DEMAND_WITH_PREFETCH mixed requests generated by normalization and merging. Each queue entry within the unified HPW request queue maintains the hardware status fields required for the entire page table traversal process, including the currently processed virtual page number (curr_vpn), the number of remaining virtual pages to be processed (len_remain), the current page table level (pgl), the physical page number of the current level page table (walk_ppn), the address space identifier (asid_or_vmid), the target L1TLB bitmap (l1_vec), the lookup access attribute (attr), the true missing flag (is_demand), and the queue status flag (status). The queue entry status includes four categories: FREE, READY, BUSY, and EXCEP, which respectively represent the working status of the entry being allocable, waiting for scheduling, traversing, and suspended due to a true missing exception.

[0086] The physical base address of the root page table is uniformly stored in the MMU shared configuration register and is not duplicated in queue entries. Queue entries are indexed by asid_or_vmid to the root page table configuration of the corresponding address space. When an address space or root page table context switch occurs, the hardware must complete, cancel, or invalidate the in-transit queue entries of the old context to prevent translation errors caused by page table context confusion. Relying on the boundary constraints of directory pre-splitting, the same queue entry only covers a single parent directory range and is processed by only a single serial Walker at any given time. Therefore, each entry only needs to maintain a single set of walk_ppn and pgl states, without needing to store multiple sets of intermediate directory page table information. The serial Walker can update walk_ppn and pgl in real time each time it obtains a valid intermediate page table entry, completing the page table addressing traversal step by step.

[0087] Queue entries uniformly adopt 4KB granular virtual page numbers as the sole measurement benchmark. The counting semantics of curr_vpn and len_remain are fixed and independent of the actual mapping size of the final leaf page table. During entry initialization, curr_vpn is assigned the request's starting VPN, and len_remain is assigned the total request length, dynamically updated during page traversal. For DEMAND_WITH_PREFETCH type entries, is_demand is set to valid during initialization, indicating that the home page is a genuine missing access. After home page verification and backfilling are completed, the hardware automatically clears is_demand, and all subsequent virtual pages are uniformly switched to prefetch semantic processing. Simultaneously, for requests from different L1TLB clusters with completely identical lookup and access attributes, multi-source requests can be merged through the l1_vec bitmap, achieving unified backfilling across multiple TLB clusters in a single traversal.

[0088] The queue entry status is used to manage the entry's lifecycle and traversal process. The idle state is used for new request allocation; the ready state awaits hardware arbitration scheduling; the busy state locks the entry, prohibiting rewriting and merging operations; the abnormal state is only triggered by a failed real missing page check and locks the abnormal context, requiring the host to read and clear the abnormal before returning to the idle state. For traversal errors in the prefetch interval, only an invalid prefetch result is silently generated, and the remaining traversal continues. When the PTE valid bit is 0, it indicates that the current address translation result is invalid; subsequent real accesses hitting the TLB entry will re-trigger a complete TLB missing traversal. The system supports a continuous prefetch scheduling mode, which can maintain a busy state for continuous traversal within a pure prefetch interval, reducing the performance overhead caused by frequent scheduling.

[0089] This system supports a large-page accelerated traversal mechanism. While maintaining the fixed 4KB metering semantics of curr_vpn and len_remain, when the serial Walker reads a valid 2MB or 1GB large-page leaf table entry, it uses skip_pages=min(len_remain,leaf_end_vpn) to achieve this. The `curr_vpn` function calculates the number of remaining 4KB virtual pages that can be continuously covered by the current large page, and skips the coverage area of ​​the same large page in one batch. For truly missing large pages, the hardware performs integrity verification and fills in the valid large page TLB entry. For subsequent prefetch intervals, the large page mapping relationship is directly reused, without having to repeatedly traverse the page table 4KB by KB. Among them, a 2MB large page can skip up to 512 4KB virtual pages at a time, and a 1GB large page can skip up to 512×512 4KB virtual pages at a time, effectively eliminating the overhead of repeated page table reads within the large page interval and improving the efficiency of large-range continuous prefetching and traversal.

[0090] The serial HPW traverser (serial Walker) receives page table traversal requests after scheduling from a unified HPW request queue. Based on the queue entry `asid_or_vmid`, it reads the physical base address of the corresponding root page table, completing page table traversal and addressing level by level from the root level. The serial Walker prioritizes querying the L2PTECache for page table reads. If the cache is hit, the page table data is directly retrieved; otherwise, the system memory is accessed through the page table memory AXI read interface. The serial Walker performs integrity checks on the final leaf page table entries, including valid bit verification, format verification, read / write execution permission verification, and privilege level verification. It also distinguishes between actual missing access and prefetch access based on the `is_demand` flag, performing differentiated verification processing and exception isolation. For `DEMAND_WITH_PREFETCH` type entries, if the first page's actual missing check fails, the `EXCEP` flag is set directly, and subsequent traversal is terminated. If the prefetch interval check fails, silent fault tolerance is maintained, and traversal continues, achieving a decoupled design between actual access security verification and prefetch performance optimization. After the traversal is complete, the serial Walker outputs the address translation result to the L1 / L2TLB backfill interface.

[0091] The page table memory AXI read interface connects to the serial Walker, serving as the sole hardware path for system memory access during page table traversal. In the event of an L2PTECache miss, the root page table, intermediate parent directory page table, and leaf page table entries are read via the AXI bus. The page table data is returned to the serial Walker while simultaneously writing back to the cache and reporting the page table read error status synchronously.

[0092] In one embodiment, the complete processing flow of the page table traversal request handling system is as follows: When an L1TLB cluster generates a TLB miss request or a TLB prefetch request, and both the L1TLB and the shared L2TLB / PTECache are hit, a unified request is generated and sent to the request unification unit. The request unification unit performs unified encoding on the original request to generate a page table traversal request with a unified format; at the same time, it determines whether the merging conditions are met based on the request context information, and merges single-page TLB miss requests with consecutive addresses and matching attributes with subsequent TLB prefetch requests into a merged page table traversal request that carries the subsequent prefetch (DEMAND_WITH_PREFETCH) for the required page; requests that do not meet the merging conditions are output independently.

[0093] The page table traversal request output by the request normalization unit is sent to the directory pre-splitting unit. The directory pre-splitting unit reads the starting virtual page number and the length of consecutive pages of the request, calculates the endpoint of the virtual page range, and makes a judgment based on the parent directory boundary corresponding to the current page table level. If the requested virtual page range crosses the parent directory boundary, it recursively splits the request using the parent directory address boundary as the split point, generating multiple sub-page table traversal requests, ensuring that the VPN range of each sub-page table traversal request falls within the jurisdiction of the same parent directory; if no splitting is required, the original request is directly passed through. The request allocation queue item after splitting or passing through is sent to the unified HPW request queue.

[0094] The unified HPW request queue performs hardware arbitration scheduling on its internal queue entries. Target page table traversal requests with a READY status are output to the serial Walker. The serial Walker changes the queue entry status to BUSY, reads the address space identifier to obtain the corresponding root page table base address, and initiates page table traversal. The serial Walker retrieves page table entries through local lookup; if a local miss occurs, it initiates a PTE read request to the page table memory via the AXI read interface and receives the returned data to obtain the page table traversal result.

[0095] The serial Walker performs integrity checks on the leaf page table entries in the page table traversal results. If the integrity check fails, differentiated processing is performed based on the request semantics. When the current virtual page is a true missing access, the exception context is saved, the queue entry status is set to exception (EXCEP), subsequent virtual page processing for this request is stopped, and the host waits to read and clear the exception. When the current virtual page is a prefetch access, an invalid prefetch flag is generated or the traversal result is discarded directly without reporting a page fault to the host, curr_vpn and len_remain are updated, and the remaining virtual pages are processed.

[0096] If the integrity check passes, the address translation result and exception information are returned to the shared L2TLB / PTECache as a backfill / exception path. For missing requests, valid TLB entries are backfilled and blocked access is resumed. The is_demand flag is automatically cleared after the missing page in the DEMAND_WITH_PREFETCH request header is processed. For prefetch requests, prefetch TLB entries are generated and backfilling is completed. After processing the current virtual page, curr_vpn and len_remain are updated.

[0097] After processing each virtual page, if len_remain is not 0, the queue entry status is set back to READY, waiting for the next scheduling; if len_remain decreases to 0, the queue entry status is set to FREE, the queue entry is released, and all page table traversal requests are completed.

[0098] In this embodiment, the page table traversal request processing system reuses the same queue, serial Walker, page table read path, and TLB backfill path after TLB missing requests and TLB prefetch requests are normalized. The request normalization unit merges requests, reducing the overhead of queue entry allocation, release, and arbitration; the directory pre-splitting unit splits the parent directory boundary before enqueuing, simplifying the internal boundary judgment and dynamic split request logic of the serial Walker; the serial Walker uses the is_demand flag to distinguish between missing and prefetch semantics, achieving unified traversal, differentiated exception handling, and differentiated TLB backfilling. The entire system does not require a separate hardware state machine and queue resources for the prefetch path, reducing chip hardware area overhead, while reducing repeated page table reads, simplifying the MMU system control logic, and reducing the difficulty of hardware design and verification.

[0099] Furthermore, as Figures 1 to 2 The specific implementation of the method shown in this embodiment provides a page table request processing apparatus, such as... Figure 5 The diagram shows a structural schematic of a page table request processing apparatus 300, which includes an acquisition module 310, an encoding module 320, and a processing module 330, wherein: The acquisition module 310 is configured to acquire a first page table request and a second page table request. The first page table request is a page table request generated when the virtual page access operation misses in the translation back buffer (TLB), and the second page table request is a page table request generated when the virtual page prefetch operation misses in the TLB.

[0100] The encoding module 320 is configured to perform request encoding processing on the first page table request and the second page table request according to the missing request identifier information and the first request context information in the first page table request, and the prefetch request identifier information and the second request context information in the second page table request, and according to the field structure of the target page table traversal queue, to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and send the page table traversal requests obtained after request encoding processing into the target page table traversal queue.

[0101] The processing module 330 is configured to read target page table traversal requests from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differentiated processing on abnormal results of page table traversal processing according to the target request type identification information in the target page table traversal request.

[0102] Optionally, the encoding module 320 is also configured to extract first request context information of the first page table request and second request context information of the second page table request.

[0103] Based on the context information of the first request and the missing request identifier information, and according to the corresponding field structure of the page table traversal queue, the first page table request is processed by request encoding to obtain the page table traversal request corresponding to the first page table request.

[0104] Based on the second request context information and prefetch request identifier information, and according to the corresponding field structure of the page table traversal queue, the second page table request is processed by request encoding to obtain the page table traversal request corresponding to the second page table request.

[0105] Optionally, the encoding module 320 is also configured to determine whether each page table traversal request meets the merging conditions based on the request context information and request type identification information in each page table traversal request, from the dimensions of address continuity, attribute matching, and request type.

[0106] Page table traversal requests that meet the merging conditions are processed by request merging to obtain merged page table traversal requests.

[0107] Optionally, the encoding module 320 is also configured to determine whether each page table traversal request meets the merging conditions based on the request context information and request type identification information in each page table traversal request, from the dimensions of address continuity, attribute matching, and request type.

[0108] Page table traversal requests that meet the merging conditions are processed by request merging to obtain merged page table traversal requests.

[0109] Optionally, the processing module 330 is also configured to access the page table in memory to perform a page table traversal lookup based on the virtual page address of the target virtual page in the target page table traversal request, and obtain the page table traversal result corresponding to the target virtual page.

[0110] Perform integrity checks on the leaf page table entries in the page table traversal results.

[0111] If the integrity check fails, it is determined that there is an anomaly in the page table traversal result, and differential processing is performed on the abnormal result of the page table traversal based on the target request type identifier information in the target page table traversal request.

[0112] Optionally, the processing module 330 is also configured to determine the access type of the target virtual page that failed the integrity check based on the target request type identification information in the target page table traversal request.

[0113] If the access type of the target virtual page is a missing request, save the exception context information and stop performing page table traversal processing on other virtual pages in the target page table traversal request.

[0114] If the access type of the target virtual page is a prefetch request, generate an invalid prefetch flag or discard the page table traversal result; and continue to perform page table traversal processing on the unprocessed virtual pages in the target page table traversal request.

[0115] Optionally, the processing module 330 is also configured to obtain the address translation result corresponding to the leaf page table entry if the integrity check passes.

[0116] The access type of the target virtual page is determined based on the target request type identifier information in the target page table traversal request.

[0117] If the access type of the target virtual page is a missing request, the address translation result is written to the TLB.

[0118] If the access type of the target virtual page is a prefetch request, a prefetch TLB entry is generated based on the address translation result, and page table traversal processing is continued for the unprocessed virtual pages in the target page table traversal request.

[0119] It should be noted that other corresponding descriptions of the functional units involved in the page table request processing apparatus provided in this embodiment can be found in [reference needed]. Figures 1 to 2 The corresponding descriptions in [the document] will not be repeated here.

[0120] Based on the above, Figures 1 to 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figures 1 to 2 The method shown.

[0121] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0122] like Figure 6 The diagram shown is a schematic of a cache unit structure for an electronic device according to the present invention, comprising: At least one processor 401; and, A memory 402 is communicatively connected to at least one of the processors 401; wherein, The memory 402 stores instructions that can be executed by at least one of the processors to enable the at least one of the processors to perform the page table request processing method as described above.

[0123] Figure 6 Take a processor 401 as an example.

[0124] The electronic device may also include an input device 403 and an output device 404.

[0125] The processor 401, memory 402, input device 403, and output device 404 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0126] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the page table request processing method in the embodiments of this application, for example, Figures 1 to 2 The method flow is shown. The processor 401 executes various functional applications and data processing by running non-volatile software programs, instructions, and modules stored in the memory 402, thereby implementing the page table request processing method in the above embodiments.

[0127] Memory 402 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function. The data storage area may store data created by the use of the page table request processing method. Furthermore, memory 402 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 402 may optionally include memory remotely located relative to processor 401, and these remote memories may be connected via a network to means of performing the page table request processing method. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0128] Input device 403 can receive user clicks and generate signal inputs related to user settings and function control for page table request processing methods. Output device 404 may include display devices such as a display screen.

[0129] When one or more modules are stored in the memory 402, and are run by one or more processors 401, the page table request processing method in any of the above method embodiments is executed.

[0130] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0131] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0132] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the cache units and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other cache units and software within the information processing physical device.

[0133] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose cache unit platform, or it can be implemented by cache unit. By applying the solution of this embodiment, compared with the prior art, this application encodes the first page table request generated by TLB missing and the second page table request generated by prefetching and sends them into the same target page table traversal queue, reusing the same set of queues and page table traversal processing links, avoiding the need to configure independent queues and independent traversal paths for the two types of requests, reducing hardware resource consumption and chip area overhead. Furthermore, in the unified page table traversal processing flow, this application completes differentiated abnormal result processing based on the target request type identification information carried by the page table traversal request, without needing to maintain two sets of independent complete processing logic, simplifying control logic and reducing the difficulty of hardware design and verification.

[0134] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, 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 said element.

[0135] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for processing page table requests, characterized in that, include: Obtain a first page table request and a second page table request. The first page table request is a page table request generated when the virtual page access operation misses in the Translate Back Buffer (TLB), and the second page table request is a page table request generated when the virtual page prefetch operation misses in the TLB. Based on the missing request identifier and first request context information in the first page table request, and the prefetch request identifier and second request context information in the second page table request, the first page table request and the second page table request are processed by request encoding according to the field structure of the target page table traversal queue to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and the page table traversal requests obtained after request encoding are sent to the target page table traversal queue. Read the target page table traversal request from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differential processing on the result of the page table traversal processing according to the target request type identification information in the target page table traversal request.

2. The method according to claim 1, characterized in that, The step of performing request encoding processing on the first page table request and the second page table request according to the missing request identifier information and first request context information in the first page table request, and the prefetch request identifier information and second request context information in the second page table request, and according to the field structure of the target page table traversal queue, to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and sending the page table traversal requests obtained after request encoding processing into the target page table traversal queue includes: Extract the first request context information of the first page table request and the second request context information of the second page table request; Based on the first request context information and the missing request identifier information, the first page table request is processed by request encoding according to the field structure of the target page table traversal queue to obtain the page table traversal request corresponding to the first page table request; Based on the second request context information and the prefetch request identifier information, and according to the field structure of the target page table traversal queue, the second page table request is processed by request encoding to obtain the page table traversal request corresponding to the second page table request.

3. The method according to claim 2, characterized in that, Before sending the page table traversal request into the same target page table traversal queue, the method further includes: Based on the request context information and request type identification information in each page table traversal request, determine whether each page table traversal request meets the merging condition from the dimensions of address continuity, attribute matching, and request type. Page table traversal requests that meet the merging conditions are processed by request merging to obtain merged page table traversal requests.

4. The method according to claim 2, characterized in that, The method further includes: Based on the request context information in each page table traversal request, determine from each page table traversal request the page table traversal request whose address range of the virtual page belongs to multiple parent directories and is to be split. Using the address boundaries of the parent directory as the basis for splitting, the page table traversal request to be split is split to obtain multiple sub-page table traversal requests.

5. The method according to any one of claims 1-4, characterized in that, The steps include: reading target page table traversal requests from the target page table traversal queue; performing page table traversal processing on the target virtual page corresponding to the target page table traversal request; and performing differentiated processing on abnormal results of the page table traversal processing based on the target request type identifier information in the target page table traversal request. Based on the virtual page address of the target virtual page in the target page table traversal request, access the page table in memory to perform a page table traversal lookup, and obtain the page table traversal result corresponding to the target virtual page; Perform integrity checks on the leaf page table entries in the page table traversal result; If the integrity check fails, it is determined that the page table traversal result is abnormal, and differential processing is performed on the abnormal result of the page table traversal based on the target request type identifier information in the target page table traversal request.

6. The method according to claim 5, characterized in that, The step of performing differentiated processing on abnormal results of the page table traversal process based on the target request type identifier information in the target page table traversal request includes: Based on the target request type identifier information in the target page table traversal request, determine the access type of the target virtual page that failed the integrity check; If the access type of the target virtual page is a missing request, save the exception context information and stop performing page table traversal processing on other virtual pages in the target page table traversal request; If the access type of the target virtual page is a prefetch request, an invalid prefetch flag is generated or the page table traversal result is discarded; and page table traversal processing continues for the unprocessed virtual pages in the target page table traversal request.

7. The method according to claim 5, characterized in that, The method further includes: If the integrity check passes, obtain the address translation result corresponding to the leaf page table entry; The access type of the target virtual page is determined based on the target request type identifier information in the target page table traversal request; If the access type of the target virtual page is a missing request, the address translation result is written to the TLB; If the access type of the target virtual page is a prefetch request, a prefetch TLB entry is generated based on the address translation result, and page table traversal processing is continued for the unprocessed virtual pages in the target page table traversal request.

8. A page table request processing apparatus, characterized in that, include: The acquisition module is configured to acquire a first page table request and a second page table request. The first page table request is a page table request generated when the access operation of a virtual page fails to hit the translation back buffer (TLB), and the second page table request is a page table request generated when the prefetch operation of a virtual page fails to hit the TLB. The encoding module is configured to perform request encoding processing on the first page table request and the second page table request respectively according to the field structure of the target page table traversal queue, based on the missing request identifier information and the first request context information in the first page table request, and the prefetch request identifier information and the second request context information in the second page table request, to obtain the page table traversal requests corresponding to the first page table request and the second page table request respectively, and send the page table traversal requests obtained after request encoding processing into the target page table traversal queue; The processing module is configured to read target page table traversal requests from the target page table traversal queue, perform page table traversal processing on the target virtual page corresponding to the target page table traversal request, and perform differentiated processing on abnormal results of the page table traversal processing according to the target request type identification information in the target page table traversal request.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

Images