Data cache hardware prefetching device and method
By combining a secure caching module, a page information propagation module, a secure filter, and a hardware prefetcher, the limitation of the data caching hardware prefetcher crossing the 4KB physical page boundary is solved, improving prefetching capabilities, reducing latency and power consumption, and defending against side-channel attacks and information leakage.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING YINGQI INTELLIGENT TECH CO LTD
- Filing Date
- 2025-12-25
- Publication Date
- 2026-05-08
AI Technical Summary
Existing data cache hardware prefetchers cannot perform secure prefetching across 4KB physical page boundaries, resulting in high latency and high power consumption, and are vulnerable to side-channel attacks and cache information leakage.
A combination of a secure caching module, a page information propagation module, a security filter, and a hardware prefetcher is adopted. By dynamically adjusting the prefetch boundary, direct access to the TLB is avoided, speculative data and architectural state are isolated, information leakage caused by unauthorized access is prevented, and unnecessary cache access is reduced.
It achieves secure prefetching across 4KB physical page boundaries, improves the prefetching capability of long memory access streams, reduces latency and power consumption, and effectively defends against side-channel attacks and cache information leakage.
Smart Images
Figure CN121996582A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of hardware prefetching technology, and in particular to a data caching hardware prefetching device and method. Background Technology
[0002] CPUs employ paging for memory management. Each program or task running on the CPU has its own segment, defined by segment descriptors. As a program executes, when it needs to access memory, it uses the segment address plus an offset, and the segment unit outputs a linear address. In simple segmentation mode, the linear address is the physical address. In paging memory management, the memory space (e.g., 4GB) is divided into pages of equal size, with the smallest unit of a page typically being 4KB.
[0003] However, existing data cache hardware prefetchers generally do not allow prefetching beyond the 4KB physical page boundary because the continuity of physical addresses cannot be guaranteed; that is, contiguous addresses in the virtual address space may be far apart in the physical address space. Restricting data cache hardware prefetchers to prefetching only within the 4KB physical page space also limits their ability to infer long memory access flows. To achieve secure prefetching beyond the 4KB physical page boundary, direct access to the Translation Lookaside Buffer (TLB) and reverse address translation are required, which incurs high latency and power consumption, hindering the implementation of secure prefetching across the 4KB physical page boundary in CPU microarchitecture design. Furthermore, prefetching across the 4KB physical page boundary is vulnerable to security issues, as attackers could exploit it to create side-channel attacks. Prefetchers are unaware of access permissions for specific pages, so cross-page prefetching could allow data to be loaded from pages that the prefetcher cache would otherwise not be able to access. Transient execution attacks such as Spectre / Meltdown and its variants can lead to information leakage within the cache hierarchy. Summary of the Invention
[0004] Purpose of the invention: The purpose of this invention is to provide a data caching hardware prefetching device and method that enables long memory access stream prefetching across 4KB physical page boundaries, avoids the high latency and high energy consumption overhead caused by direct access to the TLB, and effectively defends against side-channel attacks and cache information leakage caused by cross-page prefetching.
[0005] Technical Solution: To achieve the above objectives, the present invention provides a data caching hardware prefetching device, comprising a secure cache module, a page information propagation module, a secure filter, and a hardware prefetcher. The secure cache module is connected in parallel with the L1 data cache and simultaneously receives memory access requests from the CPU core. The page information propagation module is connected between the TLB and the MSHR of the L1 data cache, used to extract page size information from the TLB and transmit it to the L1 data cache MSHR. The secure filter is connected between the secure cache module and the L1 data cache, monitoring the data flow related to memory access within the CPU core during submission. The hardware prefetcher is connected to the output of the L1 data cache MSHR, receives miss request information marked with page size, and dynamically adjusts the prefetch boundary according to the page size information.
[0006] Preferably, during the CPU speculative execution phase, the security cache module creates a timestamp for each speculatively executed instruction data, and the instruction data of different time windows are isolated from each other to prevent data leakage across time windows.
[0007] Preferably, the encoder inside the page information propagation module encodes the page size of the "page size information" according to the TLB information, writes the edited page size information into the MSHR extension bit, updates the MSHR page size validity and MSHR page size data, sets the validity bit of the corresponding entry, calculates the allowed prefetch boundary of the page size flag in the MSHR entry according to the page size, and finally propagates the page size information and prefetch boundary to the hardware prefetcher to transmit complete prefetch control information.
[0008] Preferably, when a speculative load command is submitted, the security filter checks the hit level field stored in the load queue: if the hit level is 00, the security filter directly discards the re-fetch request or the write request at the time of submission; if the hit level is not 00, the re-fetch or write operation at the time of submission is allowed to proceed normally, and the data is transferred from the security cache to the L1 data cache; wherein, a level of 00 indicates that the data comes from the L1 data cache.
[0009] Preferably, the security filter adds an L2 write-back bit to each cache line in the L1 data cache. When data moves from the security cache to the L1 data cache, the value of the write-back bit is set according to the original hit level. Subsequently, when the cache line is removed from the L1 data cache, the security filter determines whether the data needs to be propagated to the L2 cache based on the write-back bit, thereby avoiding sending redundant write-back requests to the cache level where the data already exists.
[0010] Preferably, the prefetch generation unit in the hardware prefetcher generates prefetch requests based on the increment and confidence obtained from training, including calculating the confidence, selecting the target cache, and adaptively adjusting the prefetch distance; wherein, the adaptive adjustment of the prefetch distance includes: monitoring the latency prefetch rate, increasing the prefetch distance if it exceeds a threshold, and generating multiple prefetch requests with incremental addresses.
[0011] Preferably, when a load instruction is submitted, the hardware prefetcher executes a training process, using a search window calculation based on extraction latency, so that the training at submission time can learn timely increments comparable to the training at access time. After training is completed, the instruction pointer information in the history table is updated, including recording new submission time and address, updating incremental history, refreshing coverage statistics, and simultaneously clearing load queue entries and releasing resources.
[0012] A hardware prefetching method applied to the aforementioned data cache hardware prefetching device includes: when a speculative load request is generated, the CPU core simultaneously accesses the secure cache module and the L1 data cache; if the secure cache module misses, the regular cache levels are queried sequentially, and the data response is directly filled into the secure cache module, bypassing the L1 data cache; simultaneously, a security filter records the cache level of the data source; if the L1 data cache also misses, the page information propagation module obtains page size information from the TLB and stores it in the MSHR extension bit, and the page size information is then passed to the hardware prefetcher; the hardware prefetcher dynamically adjusts the prefetch boundary according to the page size information; when a speculative instruction is submitted, the security filter determines whether to filter redundant commit write operations based on the previously recorded hit level, reducing unnecessary access to the cache levels.
[0013] Preferably, when the instruction to be executed is submitted, if the security cache module hits, the data of the submitted memory access instruction will be transferred from the security cache module to the L1 data cache through the write operation at the time of submission.
[0014] Beneficial effects: This invention has the following advantages: By dynamically adjusting the prefetch boundary using TLB page information, it breaks through the limitation of 4KB physical pages and effectively improves the prefetch capability of long memory access streams; by using secure cache and secure filter to isolate speculative data and architectural state, it prevents information leakage caused by illegal access and effectively resists instantaneous execution attacks such as Spectre; the secure filter reduces unnecessary cache access by filtering redundant commit write operations; and by passing page information through the MSHR extension bit, it avoids direct access to the TLB for reverse address translation, eliminating the high latency and high energy consumption overhead caused by cross-page prefetching. Attached Figure Description
[0015] Figure 1 Microarchitecture diagram of hardware prefetching device for data caching;
[0016] Figure 2 This is a sequence diagram of the operation of the page information dissemination module;
[0017] Figure 3 A flowchart for performing filtering for a security filter;
[0018] Figure 4 This is a diagram of the internal structure of a hardware prefetcher.
[0019] Figure 5 This is a flowchart of the core training algorithm for the prefetcher. Detailed Implementation
[0020] The technical solution of the present invention will be described in detail below with reference to the embodiments and accompanying drawings.
[0021] like Figure 1 As shown, a data cache hardware prefetching device includes a secure cache module, a page information propagation module, a secure filter, and a hardware prefetcher. The secure cache module is connected in parallel with the L1 data cache (Level 1 data cache), and both simultaneously receive memory access requests from the CPU core. The page information propagation module is connected between the TLB (Translation Back Buffer) and the MSHR (Miss Handling Register) of the L1 data cache, used to extract page size information from the TLB and pass it to the L1 data cache MSHR. The secure filter is connected between the secure cache module and the L1 data cache, monitoring the data flow related to memory access within the CPU core during submission. The hardware prefetcher is connected to the output of the L1 data cache MSHR, receiving miss request information marked with page size, and dynamically adjusting the prefetch boundary based on the page size information.
[0022] The hardware prefetching method based on the data cache hardware prefetching device works as follows: When a speculative load request is generated, the CPU core simultaneously accesses the secure cache module and the L1 data cache. If the secure cache module misses, the regular cache levels are queried sequentially, and the data response is directly filled into the secure cache module, bypassing the L1 data cache. Simultaneously, the security filter records the cache level of the data source. Meanwhile, if the L1 data cache also misses, the page information propagation module obtains the page size information from the TLB and stores it in the MSHR extension bit. This information is then passed to the hardware prefetcher. The hardware prefetcher dynamically adjusts the prefetch boundary based on the page size information—if the page size is 2MB, secure prefetching across the 4KB physical page boundary is allowed; otherwise, it is limited to within the 4KB boundary. When a speculative instruction is submitted, the security filter determines whether to filter redundant commit-time write operations based on the previously recorded hit level, reducing unnecessary access to the cache levels.
[0023] The secure cache module defends against speculative execution attacks (such as Spectre and Meltdown) while maintaining high processor performance. Accessed concurrently with the L1 data cache, the secure cache module stores speculative instruction data issued by the CPU core until the instruction data is committed (or exits). During the CPU speculative execution phase, the secure cache module creates a timestamp for each speculative instruction data, isolating instruction data from different time windows to prevent data leakage across time windows. When a speculative instruction data miss occurs in the secure cache, the CPU core searches for the data in the regular caches (L1, L2, and L3 data caches). If a regular cache hit occurs, the secure cache module's cache state is not updated; if a regular cache miss occurs, the response directly populates the secure cache module with the data.
[0024] When a presumed instruction is committed, if the security cache module hits, the data of the committed memory access instruction will be transferred from the security cache module to the L1 data cache through a commit-time write operation.
[0025] If the data for the memory access instruction is subsequently evicted from the L1 data cache, it is moved to the L2 cache. Further evictions in the L2 cache prompt the CPU core to access the L3 cache. If a safe cache miss occurs, the data for the memory access instruction is fetched back into the regular cache level.
[0026] The page information propagation module propagates page size information from the TLB to the hardware prefetcher, enabling safe prefetching across 4KB boundaries. In this invention, a page size flag (e.g., 0 = 4KB, 1 = 2MB; this can be extended to various page sizes, requiring an additional log2N bits) is added to each entry in the L1 data cache MSHR. MSHR is essentially a fixed-size array used to store missed requests for requested data that have not yet been returned to the L1 data cache. Once the data is returned to the L1 data cache, the corresponding missed request is removed from the MSHR. When an L1 data cache miss occurs, the L1 data cache retrieves the page size information from the TLB and stores it in the MSHR; this page size information is then propagated to the main hardware prefetcher along with the request flow.
[0027] like Figure 2 As shown, the operation sequence steps of the page information propagation module are as follows:
[0028] L1 data cache miss detection (T0): When an L1 data cache miss is detected, an L1 data cache miss valid signal is generated, an MSHR entry is allocated, the L1 data cache MSHR id is obtained, and the state machine transitions from IDLE to FETCH state.
[0029] TLB Query (T1): The page information propagation module uses the virtual address to query the TLB. The TLB returns the physical address to the page information propagation module, which then extracts the page size information.
[0030] Page size encoding (T2-T3): The encoder inside the page information propagation module encodes the page size of the "page size information" according to the TLB information, and the state machine transitions to the ENCODE state.
[0031] MSHR Update (T3-T4): Write the edited page size information to the MSHR extension bits, update the MSHR page size validity and MSHR page size data, and set the validity bits for the corresponding entries.
[0032] Boundary Calculation (T4): Calculates the allowed prefetch boundaries in the MSHR entry based on the page size flag. For example, a 4KB page is limited to a 12-bit address range; a 2MB page is allowed to cross the 4KB boundary, limited to a 21-bit address range.
[0033] L2C propagation (T5): Propagates page size information and prefetch boundaries to the hardware prefetcher, transmits complete prefetch control information, and the state machine transitions to the PROP state.
[0034] Complete return (T6): The state machine returns to the IDLE state, ready to handle the next cache miss.
[0035] like Figure 3 As shown, the working principle of the safety filter is as follows:
[0036] 1. Hit Level Recording: When a speculative load request is issued, the security filter allocates an entry for the request in the load queue of the hardware prefetcher and records the cache level provided by the data using a 2-bit code (00=L1 data cache or security cache, 01=L2 cache, 10=L3 cache, 11=DRAM). This hit level information is returned along with the data response and stored in the load queue entry.
[0037] 2. On-commit Filtering Decision: When a speculative load command is committed, the security filter checks the hit level field stored in the load queue. If the hit level is 00 (indicating data comes from the L1 data cache), the security filter directly discards the re-fetch request or write request at the time of commit, avoiding unnecessary L1 data cache access and LRU replacement policy updates. If the hit level is not 00, the re-fetch or write operation at the time of commit is allowed to proceed normally, transferring data from the security cache to the L1 data cache.
[0038] 3. Write-back propagation control: The safety filter adds a 1-bit L2 write-back bit to each cache line in the L1 data cache. When data moves from the safety cache to the L1 data cache, the value of this write-back bit is set according to the original hit level. Subsequently, when the cache line is evicted from the L1 data cache, the safety filter determines whether the data needs to be propagated to the L2 cache based on the write-back bit, thereby avoiding sending redundant write-back requests to cache levels where the data already exists.
[0039] 4. Streamlined filtering and propagation: The same mechanism is applied to the L2 cache. When a cache line is removed from L2, the corresponding write-back bit determines whether to propagate the data to the L3 cache.
[0040] The internal structure of the hardware prefetcher includes a loading queue, a history table, a prefetch interval predictor, a search window calculation, and modules such as a training unit, a security verification unit, and a prefetch generation unit. Figure 4 As shown.
[0041] The hardware prefetcher works closely with the secure caching module, page information propagation module, and security filter to achieve secure and timely prefetching functionality, such as... Figure 5 As shown, the hardware prefetcher data stream processing steps are as follows:
[0042] 1. Load Instruction Access and Information Recording: The load instruction first accesses the security cache (interacting with the security cache module), while the hardware prefetcher allocates an entry in the load queue, recording the access timestamp, load address, instruction pointer (PC), and speculative status flag. During this stage, the security filter synchronously records the cache level information of subsequent data responses in the load queue.
[0043] 2. Fill Latency Calculation and Storage: After the safety cache is filled, the hardware prefetcher calculates the fetch latency (latency = fill time - access time) and stores the latency in the corresponding load queue entry. If the fill hits a prefetch row, a hit flag is set. This latency information is a key input for subsequent timely training, used to compensate for the time difference between training at submission time and training at access time.
[0044] 3. Training upon submission (in conjunction with the page information propagation module): When the loading command is submitted, the hardware prefetcher executes the training process, such as... Figure 5As shown. At this point, the page information propagation module has stored the page size information in the MSHR extension bits, and the training unit determines the allowed prefetch boundaries accordingly. The training process includes: a) Search window calculation: window center = access time - fetch latency; search range = window center ± margin (margin is a preset custom value); b) Historical search: search for commit records with the same instruction pointer in the history table, and filter commits that fall within the search window; c) Increment calculation: calculate the address increment (current address - historical address) for each matching record, and evaluate the coverage of each increment. By adopting search window calculation based on fetch latency, training at submission time can learn timely increments comparable to training at access time, overcoming the latency problem of traditional prefetching at submission time.
[0045] 4. Secure Prefetch Generation (in conjunction with a secure filter): The hardware prefetch generation unit generates prefetch requests based on the increments and confidence levels obtained during training. Specifically, this includes: a) Calculating confidence levels: Calculated statistically based on the coverage of the increments; b) Target cache selection: High confidence corresponds to L1 data cache, medium confidence to L2 cache, and low confidence to L3 cache, dynamically adjusted based on MSHR occupancy; c) Adaptive prefetch distance adjustment: Monitoring the delayed prefetch rate (the proportion of late prefetch requests to active prefetch requests), increasing the prefetch distance if it exceeds a threshold, and generating multiple prefetch requests with incrementing addresses. Since training and triggering both occur during the commit phase, the secure filter ensures that these prefetch requests are not generated based on revoked speculative instructions, thus guaranteeing the security of prefetching.
[0046] 5. History table update and resource release: After training is completed, update the instruction pointer information in the history table, including recording the new submission time and address, updating the incremental history, and refreshing the coverage statistics; at the same time, clean up the loading queue entries and release resources for subsequent requests.
Claims
1. A data caching hardware prefetching device, characterized in that, The system includes a security cache module, a page information propagation module, a security filter, and a hardware prefetcher. The security cache module is connected in parallel with the L1 data cache and simultaneously receives memory access requests from the CPU core. The page information propagation module is connected between the TLB and the MSHR of the L1 data cache, used to extract page size information from the TLB and pass it to the L1 data cache MSHR. The security filter is connected between the security cache module and the L1 data cache, monitoring the data flow related to memory access within the CPU core during submission. The hardware prefetcher is connected to the output of the L1 data cache MSHR, receives miss request information marked with page size, and dynamically adjusts the prefetch boundary according to the page size information.
2. The data caching hardware prefetching device according to claim 1, characterized in that, During the CPU speculative execution phase, the secure cache module creates a timestamp for each speculatively executed instruction data, and the instruction data in different time windows are isolated from each other to prevent data leakage across time windows.
3. The data caching hardware prefetching device according to claim 1, characterized in that, The internal encoder of the page information propagation module encodes the page size of "page size information" according to the TLB information, writes the edited page size information into the MSHR extension bit, updates the MSHR page size validity and MSHR page size data, sets the validity bit of the corresponding entry, calculates the allowed prefetch boundary of the page size flag in the MSHR entry according to the page size, and finally propagates the page size information and prefetch boundary to the hardware prefetcher to transmit complete prefetch control information.
4. The data caching hardware prefetching device according to claim 1, characterized in that, When a speculative load command is submitted, the security filter checks the hit level field stored in the load queue: if the hit level is 00, the security filter directly discards the re-fetch request or the write request at the time of submission; if the hit level is not 00, the re-fetch or write operation at the time of submission is allowed to proceed normally, and the data is transferred from the security cache to the L1 data cache; where a level of 00 indicates that the data comes from the L1 data cache.
5. The data caching hardware prefetching device according to claim 1, characterized in that, The security filter adds an L2 write-back bit to each cache line in the L1 data cache. When data moves from the security cache to the L1 data cache, the value of the write-back bit is set according to the original hit level. Subsequently, when the cache line is removed from the L1 data cache, the security filter determines whether the data needs to be propagated to the L2 cache based on the write-back bit, thereby avoiding sending redundant write-back requests to cache levels where the data already exists.
6. The data caching hardware prefetching device according to claim 1, characterized in that, The hardware prefetcher hardware prefetch generation unit generates prefetch requests based on the increment and confidence obtained from training, including calculating the confidence, selecting the target cache, and adaptively adjusting the prefetch distance; wherein, the adaptive adjustment of the prefetch distance includes: monitoring the latency prefetch rate, increasing the prefetch distance if it exceeds a threshold, and generating multiple prefetch requests with incrementing addresses.
7. The data caching hardware prefetching device according to claim 1, characterized in that, When a load instruction is submitted, the hardware prefetcher executes a training process, using a search window calculation based on the extraction latency, so that the training at the time of submission can learn an incremental time comparable to the training at the time of access. After training is completed, the instruction pointer information in the history table is updated, including recording the new submission time and address, updating the incremental history, refreshing the coverage statistics, and at the same time clearing the load queue entries and releasing resources.
8. A hardware prefetching method applied to the data cache hardware prefetching apparatus of claim 1, characterized in that, When a speculative load request is generated, the CPU core simultaneously accesses the secure cache module and the L1 data cache. If the secure cache module misses, the regular cache levels are queried sequentially, and the data response is directly filled into the secure cache module, bypassing the L1 data cache. At the same time, the security filter records the cache level of the data source. If the L1 data cache also misses, the page information propagation module obtains the page size information from the TLB and stores it in the MSHR extension bit. The page size information is then passed to the hardware prefetcher. The hardware prefetcher dynamically adjusts the prefetch boundary based on the page size information. When a speculative instruction is submitted, the security filter decides whether to filter redundant commit write operations based on the previously recorded hit level, reducing unnecessary access to the cache levels.
9. The data caching hardware prefetching method according to claim 8, characterized in that, When a presumed instruction is committed, if the security cache module hits, the data of the committed memory access instruction will be transferred from the security cache module to the L1 data cache through a commit-time write operation.