A method and device for RISC-V nested virtualization-oriented address translation collaborative acceleration

Abstract

This application proposes a collaborative acceleration method and apparatus for address translation in RISC-V nested virtualization. The method introduces a Global Translation Arbitration (GTA) module and a shared secondary address translation cache (SLC) between the Memory Management Unit (MMU) and the Input / Output Memory Management Unit (IOMMU) to uniformly schedule and share address translation requests. When an address translation request misses its local cache, the SLC enables cross-unit translation result reuse. If the SLC also misses, the GTA further schedules the page table traverser resource pool to perform nested address translation, and the resulting translation is then filled back into the SLC and local cache, achieving translation result reuse. This application effectively reduces the redundant translation overhead between the MMU and IOMMU, lowers address translation latency in nested virtualization scenarios, and improves system resource utilization and overall performance.

Description

Technical Field

[0001] This application relates to the field of processor technology, and in particular to an address translation collaborative acceleration method and apparatus for RISC-V nested virtualization. Background Technology

[0002] In RISC-V-based virtualization systems, to support the efficient operation of multiple virtual machines and ensure isolation, the processor introduces a virtualization extension (H-extension). This extension uses two-stage address translation to achieve the first stage of translation from guest virtual address to guest physical address (GPA), and the second stage of translation from guest physical address (GPA) to system physical address (HPA). However, in nested virtualization scenarios (i.e., sub-virtual machines running within virtual machines), address translation needs to traverse multiple privilege levels and virtualization layers. This causes a single virtual address access to potentially trigger a physical memory access count that grows exponentially with the page table level, resulting in significant address translation latency and becoming a key bottleneck restricting processor performance.

[0003] Furthermore, in systems supporting device passthrough and high-performance I / O, direct memory access (DMA) initiated by peripherals through the Input / Output Memory Management Unit (IOMMU) also faces multi-level address translation issues. In existing technologies, the processor-side Memory Management Unit (MMU) and the device-side IOMMU are independent in hardware architecture and software control flow. Consequently, in nested virtualization environments, the MMU and IOMMU need to independently perform highly similar multi-level page table traversals, increasing access latency and causing redundant consumption of system bus bandwidth. When page table updates or context switches occur at the virtualization level, the system needs to perform complex refresh operations on the MMU's TLB and the IOMMU's IOTLB separately via software instructions, potentially causing unstable fluctuations in system performance. The MMU and IOMMU each maintain independent address translation caches, making it impossible to share and coordinate on-chip translation resources based on dynamic load, resulting in an imbalance in hardware resource utilization.

[0004] In summary, in RISC-V nested virtualization scenarios, how to achieve collaborative acceleration of address translation between the MMU and IOMMU while ensuring virtualization hierarchy isolation and security is a key technical problem that urgently needs to be solved. Summary of the Invention

[0005] This application provides a collaborative acceleration method for address translation in RISC-V nested virtualization. It unifies the management of processor-side and device-side translation requests through a global translation arbitration module, and combines a shared translation cache and page table traversal resource pool to achieve collaborative acceleration of address translation in nested virtualization. This solves the problems of high address translation latency and low resource utilization in related technologies. Furthermore, it achieves collaborative optimization of address translation performance and consistency in nested virtualization scenarios through a cross-MMU and IOMMU translation result sharing and consistency maintenance mechanism.

[0006] The second objective of this application is to propose a cooperative acceleration device for address translation in RISC-V nested virtualization.

[0007] The third objective of this application is to propose an electronic device.

[0008] The fourth objective of this application is to provide a non-transitory computer-readable storage medium.

[0009] The fifth objective of this application is to provide a computer program product.

[0010] To achieve the above objectives, the first aspect of this application proposes a collaborative acceleration method for address translation in RISC-V nested virtualization, comprising:

[0011] The MMU receives a first address translation request sent by the processor, the first address translation request including the client virtual address; The MMU obtains the associated first virtual machine identifier and first address space identifier based on the client virtual address, and obtains the first virtual page number by page granularity based on the client virtual address, and determines the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key; If the first index key is hit in the L1 TLB of the MMU, the first hit result is returned; if the first index key is not hit in the L1 TLB of the MMU, the MMU initiates a second address translation request to the Global Translation Arbitration Module (GTA), and the second address translation request includes the first index key. The GTA performs unified scheduling of the second address translation request and schedules the shared secondary address translation cache (SLC) for querying; If the first index key is hit in the SLC, a second hit result is returned, wherein the second hit result can be reused by the processor and the IOMMU; If the first index key is not found in the SLC, the GTA schedules the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain the first translation result, and writes the first translation result back to the SLC and the L1 TLB.

[0012] In one embodiment of this application, the method further includes: The IOMMU receives a DMA access request initiated by a peripheral device, wherein the DMA access request includes an I / O virtual address; The IOMMU obtains the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and obtains the second virtual page number by page granularity based on the I / O virtual address. The second virtual page number, the second virtual machine identifier, and the second address space identifier are determined as the second index key. If the second index key is matched in the L1 IOTLB of the IOMMU, a third match result is returned; if the second index key is not matched in the L1 IOTLB of the IOMMU, the IOMMU initiates a third address translation request to the GTA, and the third address translation request includes the second index key. The GTA schedules the SLC to perform a query. If the second index key is matched in the SLC, a fourth match result is returned. The fourth match result is derived from the first translation result or from an existing translation entry in the SLC. If the second index key is not found in the SLC, the GTA schedules the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the second translation result, and writes the second translation result back to the SLC and the L1 IOTLB.

[0013] In one embodiment of this application, the SLC includes a composite index field, a mapping data field, and attribute bits. The composite index field includes a virtual machine identifier, an address space identifier, and a virtual page number. The mapping data field stores the translated system physical page number, which is the physical page where the physical address after nested two-stage address translation is located. The attribute bits include read / write / execute permissions, a dirty bit, and an access bit.

[0014] In one embodiment of this application, the method further includes: The GTA encapsulates the second address translation request and / or the third address translation request into translation request descriptors, wherein the translation request descriptor includes a virtual machine identifier, a virtual page number, a client virtual address, an address space identifier, a request source type identifier, and a priority flag; Insert the translation request descriptor into the translation request queue; The translation request descriptors in the translation request queue are traversed, and based on the request source type identifier and the priority flag in the translation request descriptor, a corresponding scheduling priority is assigned to the translation request descriptor through a programmable priority mapping table.

[0015] In one embodiment of this application, the method further includes: The GTA monitors the running status parameters of at least one hardware resource instance in real time. The hardware resource instance includes at least one of page table traverser resource pool, cache structure and translation request queue. The running status parameters include at least one of page table traverser utilization, access conflict count of cache structure and queuing depth of translation request queue. When the running status parameters meet the preset load imbalance conditions, the GTA dynamically adjusts the distribution strategy of the translation request descriptors, and guides some of the translation request descriptors to hardware resource instances with loads below a preset threshold. When the operating status parameters meet the preset resource saturation conditions, a hardware-level backpressure signal is sent to at least one request source corresponding to the request source type identifier through on-chip interconnect to limit the request injection rate of the request source.

[0016] In one embodiment of this application, the GTA, based on the first index key, schedules the page table traverser resource pool to complete the nested virtualization two-stage address translation to obtain a first translation result, including: Based on the first index key, the page table traverser resource pool is scheduled, and the client virtual address stage translation and the host physical address stage translation are cascaded through a dual-state machine pipeline mechanism. After the page table entry access is completed and an intermediate physical address is generated in the client virtual address stage, the intermediate physical address is used as input to directly drive the address translation process in the host physical address stage. Through a pipeline scheduling mechanism, different translation requests are executed in an overlapping manner between the translation at the client virtual address stage and the translation at the host physical address stage, so as to construct a continuous nested translation pipeline structure. The translation of the client virtual address stage and the translation of the host physical address stage are cascaded without buffering between the stages by directly passing the intermediate physical address, thus obtaining the first translation result.

[0017] In one embodiment of this application, the method further includes: Based on the request source type identifier associated with each page table traversal, the page table traverser dynamically allocates the priority of the traversal channel through a priority arbiter; When performing page table traversal at the target level, in response to detecting a continuous virtual page number access pattern, the page table traverser prefetches adjacent page table entries through a spatial locality prefetcher and stores them in a prefetch buffer. In response to an exception occurring during page table traversal, the exception state is recorded and the exception handler is triggered through a non-blocking exception handling mechanism. At the same time, the intermediate translation state of the completed stages in the pipeline is preserved so that page table traversal can be resumed after the exception handling returns.

[0018] In one embodiment of this application, the method further includes: In response to the processor core detecting a consistency trigger event, and generating a failure message based on the consistency trigger event, wherein the failure message includes a virtual machine identifier, an address space identifier, a failure range field, and a request source type identifier; The processor core broadcasts the failure message to all cache controllers that subscribe to the failure distribution bus via the failure distribution bus in the on-chip interconnect, wherein the cache controllers include MMU cache controller, IOMMU cache controller, SLC cache controller and GTA cache controller; Each of the cache controllers receives the failure message, performs failure handling operation on the cache entry that hits the corresponding translation context, and returns an acknowledgment signal to the processor core after completing the failure handling; During the commit control phase of consistency-related instructions, the processor core synchronizes the acknowledgment signals and delays the commit of the architecture-visible state of the consistency-related instructions until it receives acknowledgment signals from all the cache controllers.

[0019] In one embodiment of this application, each of the cache controllers receives the invalidation message, performs invalidation processing on the cache entry that hits the corresponding translation context, and returns an acknowledgment signal to the processor core after completing the invalidation processing, including: The SLC cache controller invalidates the corresponding shared translation entry based on the failure message and returns an acknowledgment signal to the processor core. The GTA cache controller suspends translation scheduling and pauses the translation request queue, and returns an acknowledgment signal to the processor core; The MMU cache controller performs local cleaning based on the failure message and returns an acknowledgment signal to the processor core. The IOMMU cache controller determines whether the virtual machine identifier hits the active DMA stream / IOMMU stream status detection. If it does, it applies backpressure to restrict DMA request injection and performs consistency maintenance on the processing path involving the failure scope field. It cleans the L1 IOTLB based on the failure message, resumes DMA scheduling after cleaning, and returns an acknowledgment signal to the processor core. If it does not hit, it returns an acknowledgment signal to the processor core.

[0020] To achieve the above objectives, a second aspect of this application proposes an address translation co-acceleration device for RISC-V nested virtualization, the device comprising an MMU, a GTA, an SLC, and a page table traverser resource pool, wherein, The MMU is used to receive a first address translation request sent by the processor, the first address translation request including the client virtual address; The MMU is also used to obtain the associated first virtual machine identifier and first address space identifier based on the client virtual address, and to obtain the first virtual page number by page granularity based on the client virtual address, and to determine the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key; The MMU is also configured to return a first hit result if the first index key is hit in the L1 TLB of the MMU; and to initiate a second address translation request to the GTA if the first index key is not hit in the L1 TLB of the MMU, wherein the second address translation request includes the first index key. The GTA is used to uniformly schedule the second address translation request and schedule the SLC to perform queries; The GTA is also used to return a second hit result if the first index key is hit in the SLC, wherein the second hit result is configured to be reused by the processor and the IOMMU; The GTA is also used to schedule the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the first translation result if the first index key is not hit in the SLC. The SLC is used to store the address translation results corresponding to the composite index field constructed based on the virtual machine identifier, address space identifier, and virtual page number; The page table traverser resource pool is used to perform nested virtualization two-stage address translation based on the first index key under the GTA scheduling to obtain a first translation result, and write the first translation result back to the SLC and the L1TLB.

[0021] In one embodiment of this application, the device further includes an IOMMU. The IOMMU is used to receive DMA access requests initiated by peripherals, wherein the DMA access request includes an I / O virtual address; The IOMMU is also used to obtain the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and to obtain the second virtual page number by page granularity based on the I / O virtual address, and to determine the second virtual page number, the second virtual machine identifier and the second address space identifier as the second index key; The IOMMU is also configured to return a third hit result if the second index key is hit in the L1 IOTLB of the IOMMU; and to initiate a third address translation request to the GTA if the second index key is not hit in the L1 IOTLB of the IOMMU, wherein the third address translation request includes the second index key. The GTA is also used to schedule the SLC. If the second index key is hit in the SLC, a fourth hit result is returned. The fourth hit result comes from the first translation result or from an existing translation entry in the SLC. The GTA is also used to schedule the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain a second translation result if the second index key is not found in the SLC.

[0022] The page table traverser resource pool is also used to perform nested page table traversal based on the second index key under the GTA scheduling to obtain the second translation result, and write the second translation result back to the SLC and the L1 IOTLB.

[0023] To achieve the above objectives, a third aspect of this application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to implement the address translation co-acceleration method for RISC-V nested virtualization as described in the first aspect of this application.

[0024] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to implement the address translation cooperative acceleration method for RISC-V nested virtualization as described in the first aspect of this application.

[0025] To achieve the above objectives, a fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the address translation cooperative acceleration method for RISC-V nested virtualization as described in the first aspect of this application.

[0026] This application achieves at least the following beneficial effects: (1) By using SLC, the translation results across MMU and IOMMU can be reused, avoiding repeated nested page table traversal and reducing address translation overhead; (2) By using GTA to uniformly schedule and pool resources for translation requests, the utilization of page table traversers is improved, and the problem of resource fragmentation is solved. (3) By using the hardware-pipelined nested virtualization two-stage address translation execution mechanism, the latency caused by software participation and serial processing is reduced, and the overall system performance and predictability in the nested virtualization scenario are improved. Attached Figure Description

[0027] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating an address translation collaborative acceleration method for RISC-V nested virtualization, as shown in one embodiment of this application. Figure 2 This is a flowchart illustrating an address translation collaborative acceleration method for RISC-V nested virtualization, as shown in one embodiment of this application. Figure 3 This is a flowchart illustrating an address translation collaborative acceleration method for RISC-V nested virtualization, as shown in one embodiment of this application. Figure 4 This is a flowchart illustrating an address translation collaborative acceleration method for RISC-V nested virtualization, as shown in one embodiment of this application. Figure 5 This is a schematic diagram of the structure of an address translation co-acceleration device for RISC-V nested virtualization, as shown in one embodiment of this application; Figure 6 This is a schematic diagram of an electronic device according to one embodiment of this application. Detailed Implementation

[0028] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0029] To simplify the description and maintain consistency in technical terminology, the core terms involved in the embodiments of this application are defined as follows: Guest Virtual Address (GVA): refers to the raw logical address used by the software layer in a virtual machine.

[0030] Virtual Page Number (VPN): refers to the high-order part extracted from the GVA and used for page table indexing.

[0031] Guest Physical Address (GPA): refers to the result of the first-stage address translation, and is also called the intermediate physical address in the context of nested virtualization.

[0032] System Physical Address (HPA): refers to the final address that can directly access the host machine's physical memory after two-stage address translation.

[0033] System Physical Page Number (PPN): refers to the high-order part of HPA, that is, the final mapped page frame number stored in the secondary translation cache (SLC) or page table entry.

[0034] Virtual Machine Identifier (VMID): A label used to distinguish different virtual machines in the hardware.

[0035] Address Space Identifier (ASID): A label used to distinguish different processes or address spaces within a specific virtual machine.

[0036] Page Table Walker: A logic module implemented by a hardware finite state machine, used to automatically access memory page tables and perform address resolution.

[0037] Page table iterator resource pool: includes multiple page table iterator instances.

[0038] Level 1 Translation Look ASID eBuffer (L1 TLB / L1 IOTLB): Level 1 Translation Look ASID eBuffer.

[0039] Global Translation Arbiter (GTA)

[0040] Shared L2 Translation Cache (SLC).

[0041] In related technologies, on the processor side, the RISC-V architecture introduces a two-stage address translation mechanism through virtualization extension (H-extension). When software in the virtual machine initiates a memory access request, the processor first translates the guest virtual address into a GPA through the first-stage virtualization address translation mechanism in the guest virtual machine context (VS-Mode); subsequently, in the host context (HS-Mode), the GPA is further translated into HPA through the second-stage virtualization address translation mechanism.

[0042] In the aforementioned process, the processor relies on a page table traverser to access multi-level page tables in main memory step by step, based on the page table base address indicated by the virtualization address translation control register. Furthermore, in nested virtualization scenarios (such as an L1 hypervisor running on an L0 hypervisor), to support the operation of sub-virtual machines (L2 guests), it is typically necessary to process the multi-level virtualization address relationships through software-maintained address mapping mechanisms (such as shadow page table mechanisms) or by introducing additional virtualization level auxiliary translation logic. This results in a significant increase in the number of page table lookup steps triggered by a single memory access request as the number of virtualization levels and page table levels increases, and frequent privilege level switching (Trap-and-Emulate) significantly increases the synchronization overhead of address translation.

[0043] Furthermore, in systems that support device pass-through or high-performance I / O, peripherals initiate direct memory access (DMA) through the Input / Output Memory Management Unit (IOMMU). To ensure the security and isolation of DMA operations, the IOMMU needs to perform address translation on the I / O virtual address (IOVA) submitted by the device based on the device context.

[0044] In existing technologies, the IOMMU also adopts a multi-level page table structure similar to that on the processor side, and is configured with an independent page table traverser and I / O address translation cache (IOTLB). In nested virtualization environments, the IOMMU often needs to handle more complex mapping relationships (such as mapping IOVA to the address space of sub-virtual machines in the nested virtualization scenario). Since the IOMMU is usually located on the peripheral bus side of the on-chip system, its translation path and the processor's instruction fetch and memory access path are physically and logically independent, and its caching strategy is usually optimized for large-volume data transfers rather than frequent random memory accesses. When handling small-granularity page table updates in nested levels, it is difficult to balance translation latency and cache hit efficiency.

[0045] Furthermore, in the aforementioned related technologies, the processor-side MMU and the device-side IOMMU typically exist as independent hardware modules, lacking a unified hardware collaborative view in terms of address translation paths, page table traversal logic, and cache management mechanisms. Therefore, in nested virtualization applications of the RISC-V architecture, although the processor-side address translation mechanism and the device-side address translation mechanism can each perform their respective functions, they still have the following shortcomings at the overall system level: (i) Nested page table traversal significantly lengthens the address translation path, resulting in accumulated translation delays. In nested virtualization scenarios, address translation needs to traverse multiple layers, including L0, L1, and L2. Existing technologies typically achieve this translation through cascading two-stage page tables or software-simulated shadow page tables. Due to the lack of hardware pass-through support for nested levels, the number of page table lookups triggered by a single memory access request can increase significantly with the accumulation of virtualization layers in the worst case. This "long-path" translation logic causes address translation latency to change from linear growth to non-linear accumulation, significantly impacting the instruction throughput of the processor when running deeply nested virtual machines.

[0046] (ii) The translation views of MMU and IOMMU are independent of each other, and redundancy in table routing is difficult to avoid. In related technologies, the MMU and IOMMU employ independent hardware logic and data paths. When handling DMA access and CPU memory access within the same virtual machine environment, even if their conversion logic is highly similar, their respective page table traversers must be triggered to perform repetitive page lookup operations. This fragmented mechanism leads to the system bus being occupied by a large number of redundant page table lookup requests, increasing not only power consumption but also the main memory access bandwidth usage.

[0047] (iii) Cross-unit address translation cache synchronization relies on software triggering, which limits the system's latency stability. Due to the lack of hardware-level cross-unit consistency interconnects, fault maintenance of the processor-side TLB and device-side IOTLB heavily relies on explicit software triggering. In scenarios with frequent virtual machine switching or memory overcommitment, the hypervisor must execute a series of complex instruction sequences (such as HFENCE combined with IOMMU register operations) to ensure translation consistency. Therefore, this highly software-involved synchronization mode not only increases the frequency of privilege level switching (Trap-and-Emulate) but also affects the overall system latency stability when handling large-scale I / O interactions.

[0048] (iv) Static allocation of address translation hardware resources makes it difficult to adapt to changes in dynamic load. In existing technologies, the page table traversers and cache entries of the MMU and IOMMU are physically statically isolated. Under complex workloads of nested virtualization, situations may arise where the MMU faces immense translation pressure while the IOMMU resources are idle (or vice versa). However, due to the lack of hardware-level logical coupling and dynamic resource scheduling capabilities between the two, the overall resource utilization of the system is low. This resource allocation method, characterized by static isolation, limits the scalability of RISC-V systems when handling ultra-large-scale concurrent virtual machines to some extent.

[0049] Figure 1 This is a schematic diagram illustrating an exemplary implementation of an address translation cooperative acceleration method for RISC-V nested virtualization, as shown in this application. Figure 1 As shown, this address translation collaborative acceleration method for RISC-V nested virtualization includes the following steps: S101, the MMU receives a first address translation request sent by the processor, the first address translation request including the client virtual address.

[0050] S102, the MMU obtains the associated first virtual machine identifier and first address space identifier based on the client virtual address, and obtains the first virtual page number by page granularity based on the client virtual address, and determines the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key.

[0051] S103, if the first index key is hit in the L1 TLB of the MMU, then return the first hit result.

[0052] In some embodiments, after obtaining the first index key through the above steps, the MMU can query in the L1 TLB. If a hit is found in the L1 TLB, the first hit result is returned.

[0053] In some embodiments, the first hit result can be written back to the SLC via GTA coordination to achieve shared reuse of processor-side translation results to the device side.

[0054] In some embodiments, the first hit result may include the system physical page number corresponding to the first virtual page number and its attribute information.

[0055] S104, if the first index key is not hit in the L1 TLB of the MMU, the MMU initiates a second address translation request to the GTA (Global Translation Arbiter), wherein the second address translation request includes the first index key.

[0056] In some embodiments, if the first index key is not hit in the L1 TLB of the MMU, the MMU may initiate a second address translation request to the GTA to obtain the translation result through the GTA.

[0057] S105, GTA performs unified scheduling of second address translation requests and schedules SLC to perform queries.

[0058] In some embodiments, a shared SLC is established between the processor cluster and the IOMMU. This SLC is located after the L1 TLB / L1 IOTLB and before the main memory page table, acting as a "translation and exchange center" between the MMU and the IOMMU. The L1 IOTLB is a local cache within the IOMMU.

[0059] In some embodiments, the SLC described above may include a composite index field, a mapping data field, and attribute bits. The composite index field may include a virtual machine identifier, an address space identifier, and a virtual page number to ensure strict address space isolation between different virtual machines or different processes within the same virtual machine. The mapping data field stores the translated PPN. The attribute bits include read / write / execute permissions (R / W / X), a dirty bit, and an access bit to ensure that the IOMMU can perform permission checks without consulting main memory when reusing translation results and to support the IOMMU in directly updating the dirty bit in the SLC during write operations, maintaining synchronization with the main memory state.

[0060] In some embodiments, the SLC described above is equipped with a multi-port read / write interface or a high-bandwidth arbiter to support concurrent execution of MMU write-back requests and IOMMU query requests. Furthermore, in some embodiments, an "I / O latency-sensitive" arbitration strategy is employed when access conflicts occur, prioritizing responses to IOMMU real-time DMA translation requests to reduce the impact of I / O latency on system performance. This reduces memory access traffic generated by page table traversal under I / O-intensive nested virtualization loads.

[0061] In some embodiments, within a nested virtualization environment, address translation requests exhibit characteristics of multi-source concurrency, sudden load spikes, and high latency sensitivity. Furthermore, instruction fetching and memory access requests from the processor core, DMA access requests initiated by multiple passthrough devices, and page table backfilling operations caused by address consistency maintenance may all compete for limited hardware resource instances within the same time window. Without a unified scheduling and arbitration mechanism, resource starvation can easily occur on critical I / O paths, leading to system tail latency amplification or performance interference between virtual machines. Therefore, this invention achieves efficient utilization and quality of service assurance of hardware resource instances through centralized awareness and fine-grained allocation via GTA, thereby improving resource utilization.

[0062] In some embodiments, a hardware resource instance may include at least one of a page table traverser resource pool, a cache structure, and a translation request queue.

[0063] In some embodiments, page table traversal resources on the processor side (MMU) and device side (IOMMU) can be logically pooled to construct a unified page table traversal resource pool. Furthermore, in some embodiments, the GTA can be used to uniformly schedule second address translation requests and / or third address translation requests from the MMU and IOMMU, thereby enabling dynamic allocation and reuse of page table traversal resources among different translation sources.

[0064] In some embodiments, the cache structure may include SLC, L1 TLB, and L1 IOTLB.

[0065] In some embodiments, after receiving a second address translation request, the GTA can encapsulate the second address translation request into a translation request descriptor. In some embodiments, this translation request descriptor may include a virtual machine identifier, a virtual page number and its corresponding client virtual address, an address space identifier, a request source type identifier, and a priority flag. The request source type identifier is used to distinguish between processor memory access, DMA requests, or consistency maintenance operations; the priority flag indicates the quality of service level of the request, and this flag may be generated by hardware based on the request source type or preset by system software during the configuration phase.

[0066] In some embodiments, the GTA may insert translation request descriptors into the translation request queue.

[0067] In some embodiments, the GTA can traverse the translation request descriptors in the translation request queue and assign corresponding scheduling priorities to the translation request descriptors based on the request source type identifier and priority flag in the translation request descriptor through a programmable priority mapping table.

[0068] In some embodiments, different priority mapping tables can be configured to optimize for different application scenarios. For example, in compute-intensive scenarios, the priority of processor-side VS-Stage translation requests can be increased; in I / O-intensive or real-time communication scenarios, the priority of DMA translation requests initiated by the IOMMU can be increased to ensure low latency characteristics of the I / O path.

[0069] In some embodiments, GTA also has path-aware capabilities, enabling it to predict processing overhead based on the hit status of a request. Specifically, in some embodiments, if a lightweight request has already been hit in the SLC, GTA can directly guide it into the high-speed backfill path.

[0070] In some embodiments, the GTA also introduces a credit-based virtual machine fairness constraint mechanism. Specifically, in some embodiments, the GTA allocates dynamic credits to different virtual machine identifiers. If a virtual machine identifier continuously initiates address translation requests within a preset time period, the GTA can temporarily reduce the scheduling weight value of the corresponding request of that virtual machine by a preset step size, thereby suppressing the "noisy neighbor" effect and ensuring the translation service quality of other virtual machines. In some embodiments, the aforementioned preset time and preset step size can be set as needed.

[0071] Furthermore, in some embodiments, the GTA works closely with the SLC and the global consistency mechanism. In some embodiments, during scheduling, the GTA can guide address translation requests to enter the SLC listening path in advance based on historical access trajectories, thereby pre-warming the translation results and enhancing the collaborative effect of "processor first, device reuse".

[0072] S106, if the first index key is hit in SLC, then return the second hit result.

[0073] In one embodiment of the present invention, the second hit result described above can be reused by the processor and the IOMMU.

[0074] In one embodiment of the present invention, the second hit result may include the system physical page number and its attribute information corresponding to the first virtual page number.

[0075] S107, if the first index key is not found in the SLC, the GTA schedules the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain the first translation result, and writes the first translation result back to the SLC and L1TLB.

[0076] In some embodiments, if the first index key is not found in the SLC, the GTA needs to schedule the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain the first translation result. Furthermore, in some embodiments, if a heavyweight request needs to be triggered for nested virtualization two-stage address translation, the GTA allocates page table traverser resources in the page table traverser resource pool for execution, thereby achieving decoupling and parallelism of long and short tasks and preventing lightweight requests from being blocked by long paths.

[0077] In some embodiments, the method for obtaining a first translation result by performing nested virtualization two-stage address translation based on the first index key scheduling page table traverser resource pool in the GTA may include the following steps: S1071, based on the first index key, schedule the page table traverser resource pool, and through a dual-state machine pipeline mechanism, cascade the translation of the client virtual address stage and the translation of the host physical address stage. S1071 After the page table entry access is completed and an intermediate physical address is generated during the translation of the client virtual address stage, the intermediate physical address is used as input to directly drive the address translation process during the host physical address stage. S1071, through a pipeline scheduling mechanism, enables different translation requests to overlap between translation at the client virtual address stage and translation at the host physical address stage, in order to construct a continuous nested translation pipeline structure; S1071, between the client virtual address stage translation and the host physical address stage translation, the cascading execution without buffering between stages is achieved by directly passing the intermediate physical address, and the first translation result is obtained.

[0078] In some embodiments, the page table traverser uses dual-state machine logic to simultaneously resolve the guest root page table register (vsatp) and the host root page table register (hgatp), enabling direct physical memory access to the L2 Guest page table. Based on this, unlike traditional software simulation methods that rely on Trap-and-Emulate or shadow page tables, the page table traverser can automatically maintain the context states of the VS-Stage and G-Stage at the hardware level, thereby reducing the overhead of frequent privilege level switching during nested accesses.

[0079] In some embodiments, to reduce multi-stage translation latency, the page table lookups for VS-Stage address translation (client virtual address → GPA) and G-Stage address translation (host physical address → HPA) are merged into a single continuous hardware operation sequence. Specifically, after obtaining the page table entry (PTE) for the client virtual address stage translation (VS-Stage), the hardware does not need to fall back to the software layer but directly injects the GPA into the translation logic of the host physical address stage translation (G-Stage), forming a compact pipeline. This eliminates the context switching latency of intermediate states and achieves hardware acceleration for nested page table accesses.

[0080] In some embodiments, during the page table access process performed by the page table traverser, the method may further include the following steps: Step 1: Based on the request source type identifier associated with each page table traversal, the page table traverser dynamically allocates the priority of the traversal channel through the priority arbiter. Step 2: When performing page table traversal at the target level, in response to the detection of a continuous virtual page number access pattern, the page table traverser prefetches adjacent page table entries through the spatial locality prefetcher and stores them in the prefetch buffer. Step 3: In response to an exception occurring during page table traversal, the exception state is recorded and the exception handler is triggered through a non-blocking exception handling mechanism. At the same time, the intermediate translation state of the completed stages in the pipeline is preserved so that page table traversal can be resumed after the exception handling returns.

[0081] In some embodiments, the page table traverser has a built-in priority arbiter that can dynamically allocate traversal channel priorities based on the request source type identifier (such as instruction fetch (IFU), data load (LSU), or external IOMMU borrowing request). In some embodiments, address translation requests for critical paths are given the highest priority to ensure low-latency access and reduce the impact on processor instruction throughput (IPC).

[0082] In some embodiments, to address the non-contiguous distribution of nested page tables in memory, the page table traverser introduces a spatial locality prefetcher. Specifically, during the traversal of the current level page table, if a continuous virtual page number access pattern is detected, the hardware can preload adjacent page table entries into the internal prefetch buffer, thereby masking main memory access latency.

[0083] In some embodiments, if an exception occurs during page table traversal, such as a missing page table (Page Fault) or an access fault (Access Fault), the page table traverser uses a non-blocking mechanism to record the exception state and triggers the exception handler Hypervisor to process it. At the same time, the intermediate translation state of the pipeline, such as the completed G-Stage translation result, is preserved, which facilitates the rapid restoration of the state after the exception handling returns, avoids repeated translation, decouples the nested address translation process from the Hypervisor software logic, and eliminates the exception trap overhead during L2 Guest memory access.

[0084] In some embodiments, the scheduling process of hardware resource instances by the GTA may further include: the GTA monitoring the running status parameters of at least one hardware resource instance in real time, wherein the hardware resource instance includes at least one of a page table traverser resource pool, a cache structure, and a translation request queue, and the running status parameters include at least one of the utilization rate of each page table traverser, the number of access conflicts of each cache structure, and the queuing depth of the translation request queue; when the running status parameters meet a preset load imbalance condition, the GTA dynamically adjusts the distribution strategy of translation request descriptors, guiding some translation request descriptors to hardware resource instances with loads below a preset threshold; when the running status parameters meet a preset resource saturation condition, a hardware-level backpressure signal is sent to at least one request source type identifier corresponding to the request source through on-chip interconnect to limit the request injection rate of the request source. Based on this, load balancing of address translation requests across processor side and device side can be achieved.

[0085] In some embodiments, the preset load imbalance conditions may include: the utilization rate of a specific resource instance is consistently higher than a first threshold within a preset time window, while the utilization rate of at least one other resource instance of the same type is consistently lower than a second threshold; or, the access conflict frequency of a specific cache structure instance is higher than a preset conflict threshold, while the access conflict frequency of at least one other cache structure instance is lower than a preset conflict threshold. In some embodiments, the preset time window, the first threshold, the second threshold, and the preset conflict threshold can be set as needed.

[0086] In some embodiments, the preset resource saturation conditions may include: the average utilization of multiple page table traversers continuously exceeding a global threshold within a preset time window; or, the queuing depth of the translation request queue continuously exceeding a depth threshold, and the queue growth rate exceeding a rate threshold. In some embodiments, the global threshold, depth threshold, and rate threshold can be set as needed.

[0087] In some embodiments, the method of sending a hardware-level backpressure signal to at least one request source corresponding to a request source type identifier via on-chip interconnect may include: sending a first backpressure signal to the processor-side memory management unit request interface via on-chip interconnect network, indicating a reduction in the sending rate of virtualization stage translation requests; and / or sending a second backpressure signal to the input / output memory management unit request queue interface via on-chip interconnect network, indicating a reduction in the sending rate of direct memory access remapping requests.

[0088] In some embodiments, the aforementioned hardware-level backpressure signal is a backpressure signal transmitted step by step, which causes the request source to suspend or throttle the initiation of new requests at the hardware level after receiving the backpressure signal, until the backpressure signal is released.

[0089] In some embodiments, when the above-mentioned operating status parameters return to the preset normal range, the hardware-level backpressure signal is released, the normal injection rate of the request source is restored, and the distribution strategy of the translation request queue is restored to the default balancing strategy.

[0090] In some embodiments, the first translation result may include the system physical page number and its attribute information corresponding to the first virtual page number.

[0091] In some embodiments, after obtaining the first translation result through the above steps, the first translation result can be written back to the SLC and L1 TLB through the collaborative translation result export interface for reuse in subsequent address translation requests. In some embodiments, a nested translation acceleration channel is established within the processor core, including the collaborative translation result export interface. Specifically, after the MMU completes a complete guest virtual address → HPA nested translation, this interface captures the final mapping result and related attribute bits, and actively pushes it to the SLC through the on-chip interconnect network (NoC) or dedicated sideband signals, realizing multi-terminal reuse of the translation result, including immediate hits by the IOMMU, laying the foundation for multi-terminal reuse.

[0092] In this embodiment, the MMU receives a first address translation request sent by the processor, the first address translation request including the client virtual address; the MMU obtains the associated first virtual machine identifier and first address space identifier based on the client virtual address, and obtains a first virtual page number based on the client virtual address at the page granularity, and determines the first virtual page number, the first virtual machine identifier, and the first address space identifier as the first index key; if the first index key is hit in the MMU's L1 TLB, the first hit result is returned; if the first index key is not hit in the MMU's L1 TLB, the MMU initiates a second address translation request to the GTA, the second address translation request including the first index key; the GTA performs unified scheduling of the second address translation request and schedules the SLC to perform a query; if the first index key is hit in the SLC, the second hit result is returned; if the first index key is not hit in the SLC, the GTA schedules the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain the first translation result, and writes the first translation result back to the SLC and L1 TLB. Therefore, this application transforms multi-level address translation from software serial simulation to hardware pipelined execution through page table traversal resource pooling and SLC, reducing the overhead of redundant translation between MMU and IOMMU and lowering address translation latency in nested virtualization scenarios. Simultaneously, the Global Translation Arbitration (GTA) module pools and dynamically schedules MMU and IOMMU translation resources, enabling each virtual machine to obtain a more stable and predictable address translation service quality, thus improving resource utilization.

[0093] Figure 2 This is a schematic diagram illustrating an exemplary implementation of an address translation cooperative acceleration method for RISC-V nested virtualization, as shown in this application. Figure 2 As shown, this address translation collaborative acceleration method for RISC-V nested virtualization includes the following steps: S201, the IOMMU receives a DMA access request initiated by a peripheral device, wherein the DMA access request includes an I / O virtual address.

[0094] S202, the IOMMU obtains the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and obtains the second virtual page number by page granularity based on the I / O virtual address, and determines the second virtual page number, the second virtual machine identifier and the second address space identifier as the second index key.

[0095] In some embodiments, to adapt to the mapping requirements of multi-level address spaces in RISC-V nested virtualization scenarios, the IOMMU's context extraction mechanism and address translation pipeline have been extended.

[0096] In some embodiments, when the IOMMU receives a DMA access request initiated by a peripheral device, the IOMMU, while parsing the I / O virtual address, combines the virtualization context information to obtain the second virtual machine identifier and the second address space identifier associated with the request, thereby constructing a complete nested address translation context. The aforementioned second virtual machine identifier and second address space identifier can be obtained in at least one of the following ways: explicitly carried by the device in the DMA request; automatically injected by the IOMMU in the hardware context table according to the device-process binding relationship; or pre-configured in the IOMMU context register by the virtualization management layer during context switching.

[0097] In some embodiments, the aforementioned context identifier is consistent with the identifier used by the processor-side MMU in VS-Stage and G-Stage in terms of bit width, encoding method, and semantics, thereby ensuring that the IOMMU and the processor perform address resolution under the same nested virtualization view. Furthermore, with this hardware-level context awareness capability, the IOMMU can distinguish DMA requests from different virtual machines and their nesting levels at the entry stage, avoiding the insufficient isolation and frequent context switching problems caused by traditional single-level mapping or software intervention methods.

[0098] In some embodiments, the I / O virtual address can be an address configured into the device-side address space by the client software through an I / O virtualization mechanism, which is semantically related to the client virtual address in the address space.

[0099] S203, if the second index key is hit in L1 IOTLB in IOMMU, then return the third hit result.

[0100] In some embodiments, the IOMMU performs parallel matching with a second index key in its local L1 IOTLB. Furthermore, when the second index key is hit in the IOMMU's L1 IOTLB, the IOMMU can directly output the corresponding HPA from the third hit result for use by the DMA controller, thereby achieving low-latency local hit access for device-side address translation.

[0101] In some embodiments, the third hit result may include the system physical page number and its attribute information corresponding to the second virtual page number.

[0102] S204, if the second index key is not found in the L1 IOTLB of the IOMMU, the IOMMU initiates a third address translation request to the GTA, and the third address translation request includes the second index key.

[0103] S205, GTA schedules SLC to perform a query. If the second index key is found in SLC, the fourth hit result is returned. The fourth hit result comes from the first translation result or from an existing translation entry in SLC.

[0104] In some embodiments, the fourth hit result may include the system physical page number and its attribute information corresponding to the second virtual page number.

[0105] In some embodiments, before reusing the fourth hit result, the IOMMU may also perform access permission checks and consistency status checks based on the attribute information in the translation entry to ensure that the corresponding translation result is valid under the current device access semantics.

[0106] In some embodiments, when the second index key is not hit in the L1 IOTLB of the IOMMU, the IOMMU can initiate a collaborative query request through the GTA-scheduled SLC. Furthermore, if a corresponding entry exists in the SLC, the IOMMU can directly reuse the corresponding fourth hit result without repeatedly performing page table traversal, thereby significantly reducing translation latency and memory access overhead. Based on this, the aforementioned fourth hit result can originate from the first translation result generated by the processor-side MMU or from an existing translation entry in the SLC.

[0107] In some embodiments, the GTA can receive a second address translation request and / or a third address translation request sent by the MMU and / or IOMMU, and uniformly schedule the second address translation request and / or the third address translation request. The specific scheduling method is the same as the method described in the above embodiments, and will not be repeated here.

[0108] In some embodiments, the translation entries in the SLC described above are constructed using a composite index based on the virtual machine identifier, address space identifier, and virtual page number. This supports the isolation and reuse of translation results between different virtual machines and different address spaces. The composite index remains consistent across different translation request sources, thereby supporting the sharing of translation results between the MMU and IOMMU and preventing the IOMMU from triggering page table traversal operations again for address translations already completed by the MMU, thus reducing the storage access overhead caused by repeated table traversals.

[0109] S206, if the second index key is not found in the SLC, the GTA scheduler page table traverser resource pool performs nested virtualization two-stage address translation to obtain the second translation result, and writes the second translation result back to the SLC and L1 IOTLB.

[0110] In some embodiments, the second translation result may include the system physical page number and its attribute information corresponding to the second virtual page number.

[0111] In some embodiments, the second translation result can also be returned to the IOMMU for the DMA controller to perform subsequent memory access operations.

[0112] In some embodiments, GTA allocates available page table traverser resources from a unified page table traversal resource pool to support cross-source multiplexing and dynamic scheduling of address translation requests from the IOMMU and MMU.

[0113] In some embodiments, when the second index key is not hit in the SLC, the IOMMU schedules the page table traverser resource pool through the GTA to perform a nested virtualization two-stage address translation page table traversal process based on the nested context base address register, which is cascaded between VS-Stage and G-Stage, and obtains the second translation result after the traversal is completed.

[0114] In some embodiments, after obtaining the second translation result through the above steps, the second translation result can be simultaneously backfilled into the IOMMU's local L1 IOTLB and shared SLC for subsequent reuse by the device or other cooperating units. Unlike traditional device-side address translation or ATS mechanisms, the SLC in this embodiment reuses the translation result under fully nested virtualization semantics, rather than a single-level address mapping, thereby avoiding the problems of repeated traversal and semantic inconsistency in multi-level virtualization environments.

[0115] In some embodiments, the IOMMU interface can also introduce a translation result awareness and preloading mechanism. Specifically, the IOMMU can identify new nested translation results injected by the processor-side MMU by listening to translation entry write events or consistency directory update events on the SLC. Furthermore, for frequently accessed DMA address regions, the IOMMU can be configured in preloading mode to proactively fill the local L1 IOTLB with translation entries from the SLC before the corresponding DMA request arrives. Based on this, the translation overhead generated by the processor during data preparation or zero-copy structure access can be converted into reusable hardware acceleration resources on the device side, thereby further reducing device access latency.

[0116] In some embodiments, after the second translation result is written to the SLC, it can be reused by subsequent address translation requests from the processor-side MMU, thereby realizing a bidirectional translation result sharing mechanism across the processor side and the device side.

[0117] This embodiment focuses on describing the address translation coordination process of the device-side IOMMU in a nested virtualization scenario. It works in conjunction with the processor-side address translation process in the above embodiment to jointly realize a unified translation and resource scheduling mechanism across MMUs and IOMMUs.

[0118] In some embodiments, such as Figure 3 As shown, the above method may further include the following steps: S301 responds to the processor core detecting a consistency trigger event and generates a failure message based on the consistency trigger event. The failure message includes a virtual machine identifier, an address space identifier, a failure range field, and a request source type identifier.

[0119] In some embodiments, the consistency triggering event described above may include at least one of the following: Page table update instruction trap: When the processor executes privileged instructions related to address translation, the instructions directly generate an internal consistency request signal during the commit phase. These privileged instructions include, but are not limited to, HFENCE.GVMA, HFENCE.VVMA, and SFENCE.VMA. Nested context switching events: When a new value is written to the host root page table pointer register or the virtualization stage page table pointer register, the hardware context management unit automatically generates a global refresh signal to indicate that the corresponding nested address space has undergone a complete switch. When the software writes a failure instruction (such as IOTINVAL) to the IOMMU command queue, the front-end listening logic on the IOMMU side converts the failure instruction into a cross-unit collaborative failure request, so as to trigger the failure of the relevant translation entries in IOTLB and SLC at the same time. Exception and rollback triggering: When a permission exception, access exception, or illegal state of a page table entry is detected during the traversal of the nested page table, and the page table content is repaired by the Hypervisor, the hardware consistency unit will identify the exception recovery path as a consistency triggering event, ensuring that the translation results cached before the exception will not be reused.

[0120] In some embodiments, the virtual machine identifier and address space identifier can be used to accurately locate the affected virtual machine context; the failure scope field can be used to indicate the failure scope (single page, big page, range, or global); and the request source type identifier can be used to indicate the source of the failure.

[0121] In the S302, the processor core broadcasts failure messages to all cache controllers that subscribe to the failure distribution bus via the failure distribution bus in the on-chip interconnect.

[0122] In some embodiments, the cache controller may include an MMU cache controller, an IOMMU cache controller, an SLC cache controller, and a GTA cache controller. In some embodiments, the MMU cache controller controls the MMU's cache L1 TLB; the IOMMU cache controller controls the IOMMU's cache L1 IOTLB; the SLC cache controller controls the SLC; and the GTA cache controller controls the GTA.

[0123] S303, each cache controller receives a failure message, performs a failure handling operation on the cache entry that hits the corresponding translation context, and returns an acknowledgment signal to the processor core after completing the failure handling.

[0124] In some embodiments, the method by which each of the above-mentioned cache controllers receives a failure message, performs hardware filtering and corresponding failure handling operations based on the failure message, and returns an acknowledgment signal to the processor core may include: the SLC cache controller invalidates the corresponding shared translation entry based on the failure message and returns an acknowledgment signal to the processor core; the GTA cache controller suspends translation scheduling and pauses the translation request queue and returns an acknowledgment signal to the processor core; the MMU cache controller performs local L1 TLB cleaning based on the failure message and returns an acknowledgment signal to the processor core; the IOMMU cache controller determines whether the virtual machine identifier hits the active DMA stream / IOMMU stream status detection, and if it does, applies backpressure to limit DMA request injection, performs consistency maintenance processing on the processing path involving the failure scope, cleans the L1 IOTLB based on the failure message, resumes DMA scheduling after cleaning is completed, and returns an acknowledgment signal to the processor core; if it does not hit, it returns an acknowledgment signal to the processor core.

[0125] In some embodiments, when the GTA cache controller receives an invalidation message, the GTA cache controller can identify the affected virtual machine identifier, address space identifier, and the address range indicated by the invalidation range field, suspend translation scheduling and pause the translation request queue, and resume request scheduling after the cache state synchronization is completed, thereby ensuring the correctness of the scheduling process and consistency semantics.

[0126] In some embodiments, the SLC cache controller may invalidate the corresponding shared translation entry based on the virtual machine identifier and address space identifier in the invalidation message to ensure the consistency of the shared translation entry with the current address translation context.

[0127] In some embodiments, when the IOMMU cache controller receives a miss message, it uses internal snooping logic to parse the virtual machine identifier, address space identifier, and corresponding miss range field carried in the message, and performs precise misses only on the affected local L1 IOTLB entries to avoid accidental deletion of irrelevant entries. Furthermore, for ongoing DMA transfers involving miss address ranges, backpressure is applied to limit DMA request injection, and consistency maintenance is performed on processing paths involving miss range fields, with an acknowledgment signal returned to the processor core. If a miss occurs, an acknowledgment signal is returned to the processor core, and the block is unblocked after consistency maintenance is complete. This ensures the security and data consistency of device access in nested virtualization environments without frequent operating system intervention.

[0128] In S304, the processor core synchronizes the acknowledgment signals during the commit control phase of consistency-related instructions. Before receiving acknowledgment signals from all cache controllers, it delays the commit of the architectural visible state of consistency-related instructions.

[0129] In some embodiments, the processor core synchronizes the acknowledgment signal during the commit control phase of consistency-related instructions. Before receiving acknowledgment signals from all cache controllers, it does not commit the architectural visible state of consistency-related instructions, thereby ensuring consistency semantics at the hardware level.

[0130] In some embodiments, a distributed consistency maintenance mechanism is used to achieve coordinated failure control among the MMU, IOMMU, and shared cache, ensuring the consistency and correctness of address translation results in nested virtualization scenarios.

[0131] Figure 4 This is a schematic diagram illustrating an exemplary implementation of an address translation cooperative acceleration method for RISC-V nested virtualization, as shown in this application. Figure 4 As shown, the address translation collaborative acceleration method for RISC-V nested virtualization includes the following steps: The processor executes virtual machine services and generates a memory access request, sends the guest virtual address to the MMU, and triggers a first address translation request; The MMU queries its internal L1 TLB using the first index key corresponding to the guest virtual address. If a match is found, the corresponding match result is returned directly; if no match is found, a second address translation request is initiated to the GTA; Peripherals such as network cards and storage initiate DMA access, send the I / O virtual address to the IOMMU, and trigger an address translation request on the device side (i.e., the DMA access request in the above embodiment); The IOMMU queries its own internal L1 TLB using the second index key corresponding to the I / O virtual address. If the IOTLB is hit, the corresponding hit result is returned directly; if it is not hit, a third address translation request is initiated to the GTA. After receiving the second address translation request and / or the third address translation request, the GTA schedules the SLC to perform a query. If the SLC hits, the corresponding translation result is returned. If the SLC misses, the GTA schedules the page table traverser to perform nested virtualization two-stage address translation. Specifically, a first translation result is obtained for the second address translation request, and a second translation result is obtained for the third address translation request. The first translation result is written back to the SLC and L1 TLB, and the second translation result is written back to the SLC and L1 IOTLB. The MMU returns the first translation result to the processor, and the processor completes the memory access operation based on the corresponding physical address. The IOMMU returns the second translation result to the corresponding peripheral, and the peripheral completes DMA data transfer based on the physical address.

[0132] Figure 5 This application illustrates a schematic diagram of an address translation co-acceleration device for RISC-V nested virtualization, as shown below. Figure 5 As shown, the address translation co-acceleration device 500 for RISC-V nested virtualization includes an MMU, GTA, SLC, and a page table traverser resource pool, wherein... The MMU is used to receive the first address translation request sent by the processor, which includes the client virtual address; The MMU is also used to obtain the associated first virtual machine identifier and first address space identifier based on the client virtual address, and to obtain the first virtual page number based on the client virtual address at the page granularity, and to determine the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key; The MMU is also used to return a first hit result if the first index key is hit in the L1 TLB of the MMU; if the first index key is not hit in the L1 TLB of the MMU, a second address translation request is initiated to the GTA, and the second address translation request includes the first index key. GTA is used to uniformly schedule second address translation requests and schedule SLC for querying; GTA is also used to return the second hit result if the first index key is hit in SLC, where the second hit result can be reused by the processor and IOMMU; GTA is also used to schedule the page table traverser resource pool to perform nested virtualization two-stage address translation based on the first index key if the first index key is not hit in the SLC, and to obtain the first translation result, and write the first translation result back to the L1 TLB of the SLC and MMU. SLC is used to store the address translation results corresponding to the composite index field built based on the virtual machine identifier, address space identifier, and virtual page number; The page table traverser resource pool is used to perform nested virtualization two-stage address translation based on the first index key under GTA scheduling to obtain the first translation result, and then write the first translation result back to SLC and L1 TLB.

[0133] Furthermore, the aforementioned device also includes an IOMMU. The IOMMU is used to receive DMA access requests initiated by peripherals, where the DMA access request includes an I / O virtual address; IOMMU is also used to obtain the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and to obtain the second virtual page number based on the page granularity of the I / O virtual address, and to determine the second virtual page number, the second virtual machine identifier and the second address space identifier as the second index key; The IOMMU is also used to return a third hit result if the second index key is hit in the L1 IOTLB of the IOMMU; if the second index key is not hit in the L1 IOTLB of the IOMMU, a third address translation request is initiated to the GTA, and the third address translation request includes the second index key. GTA is also used to schedule SLC. If the second index key is hit in SLC, the fourth hit result is returned. The fourth hit result comes from the first translation result or from the translation entry already in the SLC. GTA is also used to schedule the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the second translation result if the second index key is not hit in the SLC.

[0134] The page table traverser resource pool is also used to perform nested page table traversal based on the second index key under GTA scheduling to obtain the second translation result, and write the second translation result back to SLC and L1 IOTLB.

[0135] Furthermore, the aforementioned SLC includes a composite index field, a mapping data field, and attribute bits. The composite index field includes a virtual machine identifier, an address space identifier, and a virtual page number. The mapping data field stores the translated system physical page number. The attribute bits include read / write / execute permissions, a dirty bit, and an access bit.

[0136] Furthermore, the aforementioned GTA is also used for: The second address translation request and / or the third address translation request are encapsulated into translation request descriptors, wherein the translation request descriptor includes a virtual machine identifier, a guest virtual address, a virtual page number, an address space identifier, a request source type identifier, and a priority flag; Insert the translation request descriptor into the translation request queue; The translation request descriptors in the translation request queue are traversed. Based on the request source type identifier and priority flag in the translation request descriptor, the corresponding scheduling priority is assigned to the translation request descriptor through a programmable priority mapping table.

[0137] Furthermore, the aforementioned GTA is also used for: Real-time monitoring of the running status parameters of at least one hardware resource instance, wherein the hardware resource instance includes at least one of page table traverser resource pool, cache structure and translation request queue, and the running status parameters include the utilization rate of each page table traverser, the number of access conflicts of the cache structure, and the queuing depth of the translation request queue. When the running status parameters meet the preset load imbalance conditions, the distribution strategy of translation request descriptors is dynamically adjusted to guide some translation request descriptors to hardware resource instances with loads below the preset threshold. When the operating status parameters meet the preset resource saturation conditions, a hardware-level backpressure signal is sent to at least one request source corresponding to the request source type identifier through on-chip interconnect to limit the request injection rate of the request source.

[0138] Furthermore, the aforementioned page table traverser resource pool is also used for: The client virtual address stage translation and the host physical address stage translation are executed in a cascaded manner through a dual-state machine pipeline mechanism. After the page table entry access is completed and an intermediate physical address is generated during the translation of the client virtual address stage, the intermediate physical address is used as input to directly drive the address translation process during the host physical address stage. Through a pipeline scheduling mechanism, different translation requests are executed in an overlapping manner between the client virtual address stage and the host physical address stage, so as to build a continuous nested translation pipeline structure. The translation process between the client virtual address stage and the host physical address stage achieves cascading execution without buffering by directly passing intermediate physical addresses, thus obtaining the first translation result.

[0139] Furthermore, the aforementioned page table traverser resource pool is also used for: Based on the request source type identifier associated with each page table traversal, the page table traverser dynamically assigns the priority of the traversal channel through a priority arbiter. When performing page table traversal at the target level, in response to the detection of a consecutive virtual page number access pattern, the page table traverser prefetches adjacent page table entries through the spatial locality prefetcher and stores them in the prefetch buffer. In response to an exception occurring during page table traversal, the exception state is recorded and the exception handler is triggered through a non-blocking exception handling mechanism. At the same time, the intermediate translation state of the completed stages in the pipeline is preserved so that page table traversal can be resumed after the exception handling returns.

[0140] Furthermore, the above-described apparatus also includes a processor and a cache controller, the processor being used for: In response to the processor core detecting a consistency trigger event, a failure message is generated based on the consistency trigger event. The failure message includes a virtual machine identifier, an address space identifier, a failure range field, and a request source type identifier. The processor core broadcasts failure messages to all cache controllers that subscribe to the failure distribution bus via the failure distribution bus in the on-chip interconnect. The cache controllers include the MMU cache controller, IOMMU cache controller, SLC cache controller, and GTA cache controller. Each cache controller receives a failure message, performs hardware filtering and corresponding failure handling operations based on the failure message, and returns an acknowledgment signal to the processor core. During the commit control phase of consistency-related instructions, the processor core synchronizes the acknowledgment signals and does not commit the architectural visible state of consistency-related instructions until it receives acknowledgment signals from all cache controllers.

[0141] Furthermore, the aforementioned device is also used for: The SLC cache controller invalidates the corresponding shared translation entry based on the failure message and returns an acknowledgment signal to the processor core. The GTA cache controller suspends translation scheduling and pauses the translation request queue, and returns an acknowledgment signal to the processor core. The MMU cache controller performs local cleaning based on the failure message and returns an acknowledgment signal to the processor core. The IOMMU cache controller determines whether the virtual machine identifier hits the active DMA stream / IOMMU stream status detection. If it does, it applies backpressure to limit DMA request injection and performs consistency maintenance on the processing path involving the failure scope field. It cleans the L1 IOTLB based on the failure message, resumes DMA scheduling after cleaning, and returns an acknowledgment signal to the processor core. If it does not hit, it returns an acknowledgment signal to the processor core.

[0142] To implement the above embodiments, this application also proposes an electronic device 600, such as... Figure 6 As shown, the electronic device 600 includes a processor 601 and a memory 602 communicatively connected to the processor. The memory 602 stores instructions that can be executed by at least one processor. The instructions are executed by at least one processor 601 to implement the address translation collaborative acceleration method for RISC-V nested virtualization as shown in the above embodiment.

[0143] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to implement the address translation cooperative acceleration method for RISC-V nested virtualization as shown in the above embodiments.

[0144] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the address translation cooperative acceleration method for RISC-V nested virtualization as shown in the above embodiments.

[0145] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0146] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0147] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0148] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A collaborative acceleration method for address translation in RISC-V nested virtualization, characterized in that, include: The MMU receives a first address translation request sent by the processor, the first address translation request including the client virtual address; The MMU obtains the associated first virtual machine identifier and first address space identifier based on the client virtual address, and obtains the first virtual page number by page granularity based on the client virtual address, and determines the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key; If the first index key is hit in the L1 TLB of the MMU, the first hit result is returned; if the first index key is not hit in the L1 TLB of the MMU, the MMU initiates a second address translation request to the Global Translation Arbitration Module (GTA), and the second address translation request includes the first index key. The GTA performs unified scheduling of the second address translation request and schedules the shared secondary address translation cache (SLC) for querying; If the first index key is hit in the SLC, a second hit result is returned, wherein the second hit result can be reused by the processor and the IOMMU; If the first index key is not found in the SLC, the GTA schedules the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain the first translation result, and writes the first translation result back to the SLC and the L1 TLB.

2. The method according to claim 1, characterized in that, The method further includes: The IOMMU receives a DMA access request initiated by a peripheral device, wherein the DMA access request includes an I / O virtual address; The IOMMU obtains the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and obtains the second virtual page number by page granularity based on the I / O virtual address. The second virtual page number, the second virtual machine identifier, and the second address space identifier are determined as the second index key. If the second index key is matched in the L1 IOTLB of the IOMMU, a third match result is returned; if the second index key is not matched in the L1 IOTLB of the IOMMU, the IOMMU initiates a third address translation request to the GTA, and the third address translation request includes the second index key. The GTA schedules the SLC to perform a query. If the second index key is matched in the SLC, a fourth match result is returned. The fourth match result is derived from the first translation result or from an existing translation entry in the SLC. If the second index key is not found in the SLC, the GTA schedules the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the second translation result, and writes the second translation result back to the SLC and the L1 IOTLB.

3. The method according to any one of claims 1-2, characterized in that, The SLC includes a composite index field, a mapping data field, and attribute bits. The composite index field includes a virtual machine identifier, an address space identifier, and a virtual page number. The mapping data field stores the translated system physical page number, which is the physical page where the physical address after nested two-stage address translation is located. The attribute bits include read / write / execute permissions, a dirty bit, and an access bit.

4. The method according to claim 2, characterized in that, The method further includes: The GTA encapsulates the second address translation request and / or the third address translation request into translation request descriptors, wherein the translation request descriptor includes a virtual machine identifier, a virtual page number, a client virtual address, an address space identifier, a request source type identifier, and a priority flag; Insert the translation request descriptor into the translation request queue; The translation request descriptors in the translation request queue are traversed, and based on the request source type identifier and the priority flag in the translation request descriptor, a corresponding scheduling priority is assigned to the translation request descriptor through a programmable priority mapping table.

5. The method according to claim 4, characterized in that, The method further includes: The GTA monitors the running status parameters of at least one hardware resource instance in real time. The hardware resource instance includes at least one of page table traverser resource pool, cache structure and translation request queue. The running status parameters include at least one of page table traverser utilization, access conflict count of cache structure and queuing depth of translation request queue. When the running status parameters meet the preset load imbalance conditions, the GTA dynamically adjusts the distribution strategy of the translation request descriptors, and guides some of the translation request descriptors to hardware resource instances with loads below a preset threshold. When the operating status parameters meet the preset resource saturation conditions, a hardware-level backpressure signal is sent to at least one request source corresponding to the request source type identifier through on-chip interconnect to limit the request injection rate of the request source.

6. The method according to claim 1, characterized in that, The GTA, based on the first index key, schedules the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the first translation result, including: Based on the first index key, the page table traverser resource pool is scheduled, and the client virtual address stage translation and the host physical address stage translation are cascaded through a dual-state machine pipeline mechanism. After the page table entry access is completed and an intermediate physical address is generated in the client virtual address stage, the intermediate physical address is used as input to directly drive the address translation process in the host physical address stage. Through a pipeline scheduling mechanism, different translation requests are executed in an overlapping manner between the translation at the client virtual address stage and the translation at the host physical address stage, so as to construct a continuous nested translation pipeline structure. The translation of the client virtual address stage and the translation of the host physical address stage are cascaded without buffering between the stages by directly passing the intermediate physical address, thus obtaining the first translation result.

7. The method according to claim 6, characterized in that, The method further includes: Based on the request source type identifier associated with each page table traversal, the page table traverser dynamically assigns the priority of the traversal channel through a priority arbiter; When performing page table traversal at the target level, in response to detecting a continuous virtual page number access pattern, the page table traverser prefetches adjacent page table entries through a spatial locality prefetcher and stores them in a prefetch buffer. In response to an exception occurring during page table traversal, the exception state is recorded and the exception handler is triggered through a non-blocking exception handling mechanism. At the same time, the intermediate translation state of the completed stages in the pipeline is preserved so that page table traversal can be resumed after the exception handling returns.

8. The method according to claim 2, characterized in that, The method further includes: In response to the processor core detecting a consistency trigger event, and generating a failure message based on the consistency trigger event, wherein the failure message includes a virtual machine identifier, an address space identifier, a failure range field, and a request source type identifier; The processor core broadcasts the failure message to all cache controllers that subscribe to the failure distribution bus via the failure distribution bus in the on-chip interconnect, wherein the cache controllers include MMU cache controller, IOMMU cache controller, SLC cache controller and GTA cache controller; Each of the cache controllers receives the failure message, performs failure handling operation on the cache entry that hits the corresponding translation context, and returns an acknowledgment signal to the processor core after completing the failure handling; During the commit control phase of consistency-related instructions, the processor core synchronizes the acknowledgment signals and delays the commit of the architecture-visible state of the consistency-related instructions until it receives acknowledgment signals from all the cache controllers.

9. The method according to claim 8, characterized in that, Each of the cache controllers receives the invalidation message, performs invalidation processing on the cache entry that matches the corresponding translation context, and returns an acknowledgment signal to the processor core after completing the invalidation processing, including: The SLC cache controller invalidates the corresponding shared translation entry based on the failure message and returns an acknowledgment signal to the processor core. The GTA cache controller suspends translation scheduling and pauses the translation request queue, and returns an acknowledgment signal to the processor core; The MMU cache controller performs local cleaning based on the failure message and returns an acknowledgment signal to the processor core. The IOMMU cache controller determines whether the virtual machine identifier hits the active DMA stream / IOMMU stream status detection. If it does, it applies backpressure to restrict DMA request injection and performs consistency maintenance on the processing path involving the failure scope field. It cleans the L1 IOTLB based on the failure message, resumes DMA scheduling after cleaning, and returns an acknowledgment signal to the processor core. If it does not hit, it returns an acknowledgment signal to the processor core.

10. A collaborative acceleration device for address translation in RISC-V nested virtualization, characterized in that, The device includes an MMU, GTA, SLC, and a page table traverser resource pool, wherein, The MMU is used to receive a first address translation request sent by the processor, the first address translation request including the client virtual address; The MMU is also used to obtain the associated first virtual machine identifier and first address space identifier based on the client virtual address, and to obtain the first virtual page number by page granularity based on the client virtual address, and to determine the first virtual page number, the first virtual machine identifier and the first address space identifier as the first index key; The MMU is also configured to return a first hit result if the first index key is hit in the L1 TLB of the MMU; and to initiate a second address translation request to the GTA if the first index key is not hit in the L1 TLB of the MMU, wherein the second address translation request includes the first index key. The GTA is used to uniformly schedule the second address translation request and schedule the SLC to perform queries; The GTA is also used to return a second hit result if the first index key is hit in the SLC, wherein the second hit result is configured to be reused by the processor and the IOMMU; The GTA is also used to, if the first index key is not hit in the SLC, schedule the page table traverser resource pool based on the first index key to perform nested virtualization two-stage address translation to obtain a first translation result, and write the first translation result back to the L1 TLB of the SLC and the MMU; The SLC is used to store the address translation results corresponding to the composite index field constructed based on the virtual machine identifier, address space identifier, and virtual page number; The page table traverser resource pool is used to perform nested virtualization two-stage address translation based on the first index key under the GTA scheduling to obtain a first translation result, and write the first translation result back to the SLC and the L1 TLB.

11. The apparatus according to claim 10, characterized in that, The device also includes an IOMMU. The IOMMU is used to receive DMA access requests initiated by peripherals, wherein the DMA access request includes an I / O virtual address; The IOMMU is also used to obtain the associated second virtual machine identifier and second address space identifier based on the I / O virtual address, and to obtain the second virtual page number by page granularity based on the I / O virtual address, and to determine the second virtual page number, the second virtual machine identifier and the second address space identifier as the second index key; The IOMMU is also configured to return a third hit result if the second index key is hit in the L1 IOTLB of the IOMMU; and to initiate a third address translation request to the GTA if the second index key is not hit in the L1 IOTLB of the IOMMU, wherein the third address translation request includes the second index key. The GTA is also used to schedule the SLC. If the second index key is hit in the SLC, a fourth hit result is returned. The fourth hit result comes from the first translation result or from an existing translation entry in the SLC. The GTA is also used to schedule the page table traverser resource pool to perform nested virtualization two-stage address translation to obtain the second translation result if the second index key is not found in the SLC; The page table traverser resource pool is also used to perform nested page table traversal based on the second index key under the GTA scheduling to obtain the second translation result, and write the second translation result back to the SLC and the L1 IOTLB.

12. An electronic device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

13. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

Images