Unified Memory Address Translation

Abstract

The unified memory address translation system includes a translation queue module configured to receive different modes of translation requests for a real address (RA) of the physical memory. A translation cache (XLTC) interface is configured to receive successful translation results for a previous request for the RA and provide the previous successful translation results to the translation queue module. A plurality of page table entry group (PTEG) search modules are coupled to the translation queue module. A unified translation walk address generation (UTWAG) module is configured to provide translation support for each mode of the different modes of translation requests. A memory interface is coupled between the UTWAG module and the physical memory.

Description

[Technical Field]

[0001] The present invention relates generally to computer systems, and more particularly to managing memory tables in processing systems that support multiple operating systems. [Background technology]

[0002] Modern computing platform operating systems use a combination of hardware and software to map memory addresses used by programs, sometimes called virtual addresses, to physical addresses in the computer's memory. Main storage thus appears as a uniform segment in a contiguous address space. The operating system manages the assignment of real (physical) memory to virtual address space and virtual memory. Address translation hardware in the processor, sometimes called a memory management unit (MMU), translates virtual addresses to physical addresses. Software in the operating system can provide a virtual address space larger than the capacity of real memory, thereby referencing more memory that physically exists in the computing platform. By using virtual memory, software can use more memory than is physically available. Virtual memory simplifies application programming by masking physical memory fragmentation.

[0003] Today's computing systems use different address translation mechanisms based on the type of operating system used. To support multiple computer system environments, address translation hardware should support multiple addressing modes when translating from an effective address (EA) to a real address (RA). As used herein, an effective address (EA) is the address a program sees; a virtual address (VA) is the address used by the OS; and a real address (RA) is the actual memory hardware address. When translating an EA to a real address, the processor typically performs the time-intensive process of walking a translation table to generate the correct address so that the appropriate memory address can be accessed. A page table is where the operating system stores its mapping of virtual addresses (VAs) to physical addresses; each mapping is also known as a page table entry (PTE). The time-intensive process of translating an EA to a VA and finally to a real address may require many memory reads, cache accesses, and may stall the progress of a hardware thread or the entire processor core. Summary of the Invention

[0004] According to one aspect of the present invention, a unified memory address translation system includes a translation queue module configured to receive different modes of translation requests for a real address (RA) of a physical memory. A translation cache (XLTC) interface is configured to receive successful translation results for previous requests for the RA and provide the previous successful translation results to the translation queue module. Multiple page table entry group (PTEG) search modules (e.g., page and / or segment entry table groups PTEG and STEG) are coupled to the translation queue module. A unified translation walk address generation (UTWAG) module is configured to provide translation support for each mode of the different modes of translation requests. A memory interface is coupled between the UTWAG module and the physical memory.

[0005] In one embodiment, the XLTC interface, the PTEG search module, and the transformation queue module are shared by all transformation support in the UTWAG module.

[0006] In one embodiment, the mode of the translation request includes at least one of a hashed page table (HPT) request, a segment table request, a non-nested radix request, or a nested radix request.

[0007] In one embodiment, each of the transformation requests is processed by a sequence module of the transformation queue module.

[0008] In one embodiment, the sequence module of the conversion queue module is configured to provide round-robin arbitration between conversion requests.

[0009] In one embodiment, the translation support of the UTWAG module includes at least one of a partition table entry real address generation (PATE RA GEN), a segment table entry group virtual address generation (STEG VA GEN) that operates to provide effective address (EA) to virtual address (VA) translations, a segment table entry group real address generation (STEG RA GEN) that operates to define intermediate virtual address (STEG VA) to real address (RA) translations, a page table entry group real address generation (PTEG RA GEN), a radix host real address generation (RADIX HOST RA GEN), or a radix guest real address generation (RADIX GUEST RA GEN).

[0010] In one embodiment, a finite state machine is coupled to each transformation queue entry.

[0011] In one embodiment, the state machine is shared by all translation support in the UTWAG module.

[0012] According to another aspect of the present invention, a method for providing unified memory address translation includes receiving, by a translation queue module, multiple translation requests for a real address (RA) of physical memory. Each of the multiple translation requests is allocated to a translation walk queue entry in the translation queue module. For each translation walk queue entry, a starting virtual address (VA) and a translation mode are determined from the corresponding translation request. The VA and translation mode are provided to a unified translation walk address generation (UTWAG) module, which includes multiple translation support for different translation modes. The VA is translated to an RA by the UTWAG module based on the translation mode. The UTWAG does not translate from the VA to the RA by itself; rather, an HPT translation flow based on the HPT request follows. EA-to-VA is the target of "Segment Table Translation." When an "HPT Translation" begins, the XLTC is accessed to find the previous EA-to-VA translation, then the translation walk queue entry performs a table walk to find the RA using its "starting VA".

[0013] In one embodiment, the multiple conversion requests are not of a uniform mode.

[0014] In one embodiment, the plurality of translation requests includes at least one of a hashed page table (HPT) request, a segment table request, a non-nested radix request, or a nested radix request.

[0015] In one embodiment, a translation request of the plurality of translation requests is received by a translation cache (XLTC) interface from a translation cache (XLTC) that operates to store one or more previous successful translation results.

[0016] In one embodiment, the XLTC interface, one or more Page Table Entry Group (PTEG) lookup modules, and a translation queue module are shared by all translation support in the UTWAG module.

[0017] In one embodiment, the allocation of each transformation request to one transformation walk queue entry of the plurality of transformation walk queue entries occurs upon determining that no matching previous result is found in the XLTC.

[0018] In one embodiment, each transformation walk queue entry is different for each clock cycle of the processor.

[0019] In one embodiment, round-robin arbitration is provided between multiple transformation walk queue entries.

[0020] In one embodiment, the translation support of the UTWAG module provides at least one of partition table entry real address generation (PATE RA GEN), segment table entry group virtual address generation (STEG VA GEN) that provides effective address (EA)-to-virtual address (VA) translation, segment table entry group real address generation (STEG RA GEN) that defines VA-to-RA translation for STEG VA, page table entry group real address generation (PTEG RA GEN), Radix host real address generation (RADIX HOST RA GEN), or Radix guest real address generation (RADIX GUEST RA GEN).

[0021] In one embodiment, a finite state machine is coupled to each transformation queue entry.

[0022] In one embodiment, the state machine is shared by all translation support in the UTWAG module.

[0023] According to another aspect of the present invention, a computing device includes a processor; a translation queue module configured to receive different modes of translation requests for real addresses (RAs) in physical memory; a translation cache (XLTC) interface configured to receive successful translation results for previous requests for the RAs and provide the previous successful translation results to the translation queue module; and a plurality of page table entry group (PTEG) search modules coupled to the translation queue module. A memory is coupled to the processor. A unified translation walk address generation (UTWAG) software module is stored in the memory, and execution of the UTWAG module by the processor configures the computing device to provide translation support for each mode of the different modes of translation requests. A memory interface is coupled between the UTWAG module and the physical memory.

[0024] In one embodiment, the XLTC interface, the PTEG search module, and the transformation queue module are shared by all transformation support in the UTWAG module.

[0025] In one embodiment, the mode of the translation request includes at least one of a hashed page table (HPT) request, a segment table request, a non-nested radix request, or a nested radix request.

[0026] In one embodiment, the translation support of the UTWAG module includes at least one of a partition table entry real address generation (PATE RA GEN), a segment table entry group virtual address generation (STEG VA GEN) that operates to provide effective address (EA) to virtual address (VA) translation, a segment table entry group real address generation (STEG RA GEN) that operates to define intermediate virtual address (STEG VA) to RA translation, a page table entry group real address generation (PTEG RA GEN), a Radix host real address generation (RADIX HOST RA GEN), or a Radix guest real address generation (RADIX GUEST RA GEN).

[0027] In one embodiment, a finite state machine is coupled to each transformation queue entry.

[0028] In one embodiment, the state machine is shared by all translation support in the UTWAG module.

[0029] Improved area and power efficiency is provided for address translation by sharing various hardware components and / or various software components with various translation modes. In effect, the combination of the translation walk queue iterative process and UTWAG results in efficient use of chip real estate, reduced power consumption, and improved performance for translation requests. These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

[0030] The drawings are illustrative embodiments. The drawings do not show all embodiments. Other embodiments may be used in addition or instead. Details that may be obvious or unnecessary may be omitted to save space or for a more effective illustration. Some embodiments may be practiced with additional components or steps and / or without all components or steps shown. The same numerals refer to the same or similar components or steps when appearing in different drawings. [Brief explanation of the drawings]

[0031] [Figure 1] FIG. 1 is a conceptual block diagram of a unified memory address translation system supporting multiple translation modes consistent with illustrative embodiments. [Figure 2] FIG. 10 is a more detailed block diagram of a unified memory address translation system supporting multiple translation modes consistent with an illustrative embodiment. [Figure 3] FIG. 2 is an example process flow for handling hashed page table (HPT) requests and segment table requests while sharing various components of the unified translation system. [Figure 4] An example process flow that addresses both nested and non-nested Radix requests. [Figure 5] FIG. 1 is an example functional block diagram of a computer hardware platform that may be used to host a Unified Translation Walk Address Generation (UTWAG) module. [Figure 6] FIG. 1 illustrates a cloud computing environment consistent with illustrative embodiments. [Figure 7] FIG. 10 illustrates an abstraction model layer consistent with an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0032] In the following detailed description, numerous specific details are set forth by way of example to provide a thorough understanding of the relevant teachings. However, it should be recognized that the present teachings may be practiced without such details. In other instances, well-known methods, procedures, components, or circuit configurations, or combinations thereof, have been described at a relatively high level without detail in order to avoid unnecessarily obscuring aspects of the present teachings.

[0033] This disclosure generally relates to systems and methods for managing memory tables in processing systems that support multiple operating systems. Processor cores are being developed today that can support different operating environments and virtual machines. For example, one part of a computing system may perform radix-mode translation, which uses a series of nested tables instead of a single large hashed table to find page table entries for its particular operating system (OS), while another part of the system runs a PowerPC® processor that uses a different mode of translation for its corresponding OS. For example, a hypervisor, sometimes called a virtual machine monitor (VMM), can create and run virtual machines by isolating the hypervisor operating system and resources from the virtual machine (VM), enabling the creation and management of such machines that can be based on different OSs while sharing the same hardware. Each operating system may include different address translations based on different page tables. When a process requests access to data in its memory, it is the OS's responsibility to map the virtual address (VA) provided by the process to the actual physical address of the memory where the data is stored. A page table is where an operating system stores its mappings from virtual addresses to physical addresses, and each mapping is also known as a page table entry (PTE). As different operating systems are used, there can be different translation units, sometimes referred to herein as translation modes.

[0034] PTEs are typically used to translate virtual addresses seen by the operating system into physical addresses used by the hardware to process application program instructions. The hardware that performs such translation is sometimes called a memory management unit (MMU). Each entry in the page table contains an indication of whether the corresponding page resides in physical memory. If the corresponding page resides in physical memory, the page table entry will contain the actual memory address where the page is stored. When a reference is made to a page by the hardware, if the page table entry for that page indicates that the page is not currently in physical memory, the hardware raises a page fault exception and invokes the operating system's paging supervisor component, which is discussed in more detail later.

[0035] A typical implementation dedicates hardware table walk logic for each address translation mode due to the uniqueness of each mode. There are separate units within the processor, each with its own interface that handles memory accesses, load / store data translation requests, and instruction fetch address translation requests.

[0036] In various scenarios, a system can have one page table for the entire system, a separate page table for each application, a tree of page tables for large segments, or a combination thereof. When only one page table exists, different applications running simultaneously use different portions of a single range of virtual addresses. When multiple page or segment tables exist, multiple virtual address spaces exist, and concurrent applications with separate page tables redirect to different real addresses.

[0037] Multiple translation units introduce complexity and increased chip area to accommodate multiple interfaces. Address translation latency and performance are also affected because the requesting unit handles the unique aspects of each translation unit. For example, segment table translation may involve an intermediate hashed page table (HPT), which may require handling by the requesting unit, a separate sideband interface between translation units, or even worse, replication of the HPT translation logic. Similarly, radix translation is quite different from HPT in that it uses a series of nested tables instead of a single large hashed table to find the page table entry (PTE) that defines the EA-to-RA translation. Known computing systems do not support multiple translation modes, let alone in an efficient manner.

[0038] Thus, the teachings herein provide a computer system and method for a processor that supports multiple address translation modes, a translation walk queue that supports multiple requests, where each translation walk can be in a different mode and at a different stage in the translation flow, and a unified translation walk address generator that is shared by the multiple translation modes and provides all intermediate addresses used for the translation. Improved area and power efficiency is provided for address translation by sharing various hardware and / or software components by the various translation modes. The techniques described herein can be implemented in multiple ways. Example implementations are provided below with reference to the following figures.

[0039] Example Architecture Reference is now made to FIG. 1, which is a conceptual block diagram of a unified memory address translation system 100 supporting multiple translation modes consistent with illustrative embodiments. The unified memory address translation system 100 facilitates sharing of various translation blocks without replicating one or more components of logic and hardware. The system 100 includes multiple load / store units, represented by blocks 102 and 104, associated with units within a processor core that operate to receive data and write the data into registers, represented by physical memory 114. As such, these units 102 and 104 have effective addresses (EAs) that are translated into physical addresses, sometimes referred to herein as real addresses (RAs) in (physical) memory 114. Depending on the operating system (OS) used for the corresponding load / store unit 102 or 104, there may be different ways of translating from EAs to RAs, represented by multiple translation units 106-112. In various scenarios, a hashed page table (HPT) translation 106, a segment table translation 108, a non-nested radix translation 110, or a nested radix translation table 112 may be used.

[0040] Some processor architectures that support load / store units can use a hashed page table (HPT) to dynamically map virtual memory addresses to physical memory addresses. For example, in an HPT, the virtual page number in a virtual address is hashed into a hash table. The HPT can be used to handle address spaces higher than 32 bits, for example. Each entry in the hash table is a PTEG (group of PTEs), where each PTE contains a VA and a corresponding RA. When a VA matches a PTE VA, the corresponding RA is accessed so that the HPT can provide the RA in memory 114.

[0041] Some processor architectures can use a radix tree page table (e.g., 110 or 112) to dynamically map virtual memory addresses to physical memory addresses. The OS manages physical resources in fixed page-size allocation units using address translations determined by the OS and stored in the radix tree page table. Mapping a virtual address used by the OS to a physical address (i.e., RA) in memory 114 involves traversing the radix tree, sometimes referred to herein as "walking the page table," which can involve multiple memory accesses. For example, several memory accesses for translation and data fetching may be involved for a single load operation.

[0042] Although four address translation units (i.e., 106-112) are shown in FIG. 1 to avoid confusion, it will be understood that additional address translation units are supported by the teachings herein. Typically, each of the address translation units 106-112 would be independent and would not share any components, thereby introducing additional complexity, chip area, and power consumption. In contrast, the teachings herein facilitate sharing of various translation blocks of a translation system without replicating logic and hardware components, as better understood in the context of the discussion of FIG. 2 below.

[0043] FIG. 2 is a more detailed block diagram of a unified memory address translation system 200 supporting multiple translation modes, consistent with illustrative embodiments. There is a translation queue module 230 configured to receive address translation requests, which may be of any mode. For example, the translation request may be a hashed page table (HPT) translation request, a segment table translation request, a non-nested radix request, a nested radix request, etc. There is a translation cache (XLTC) interface 206 configured to receive translated cache requests from the translation cache 204 and provide them to the translation queue module 230. The translation cache (XLTC) 204 operates to store previous successful translation results. For example, the XLTC 204 may include previous translations of different types, such as EA-to-VA, VA-to-RA, and EA-to-RA. There is a page table entry group (PTEG) lookup module 208 and / or a segment table entry group (STEG) lookup module 210 coupled to the translation queue module 230. A STEG is a group of STEs. Segment table translation looks up STEG for STE in a similar way. For example, a segment table entry is used to translate from EA to VA.

[0044] The translation module 240 includes a unified translation walk address generation (UTWAG) module 260 configured to provide translation support for each mode of translation request of a plurality of translation requests. The translation support of the UTWAG module includes at least one of a partition table entry real address generation (PATE RA GEN) 262, a segment table entry group virtual address generation (STEG VA GEN) 264 that provides EA-to-VA address translation, a segment table entry group real address generation (STEG RA GEN) 266 that reads a group of STEs for which a matching STE provides EA-to-VA address translation, a page table entry group real address generation (PTEG RA GEN) 268, a Radix host real address generation (RADIX HOST RA GEN) 270, or a Radix guest real address generation (RADIX GUEST RA GEN) 272. The HPT PTE (which may be provided by block 208) defines the VA-to-RA translation.

[0045] The UTWAG module 260 is coupled to the memory access interface 212, which operates to communicate with the physical memory 214. In some embodiments, the transformation module 240 includes a finite state machine next state generation module 220. A finite state machine can be thought of as having two parts: a set of latches that define the current state of the machine and a logic block that operates to determine the next state of the machine. In the transformation queue module 230, each transformation queue entry necessarily has its own independent FSM because each entry has a set of latches that define its current state. In a given processor cycle, arbitration 239 determines which queue entries can access the shared FSM next state generation logic block 220.

[0046] The memory access interface 212, translation cache (XLTC) 204, read / write interface 206, and XLTC interface 206 are all shared by all translation support 262-272 of UTWAG module 260, thereby saving power and / or chip real estate while reducing the complexity of unified memory address translation system 200.

[0047] By way of example and not limitation, architecture 200 of FIG. 2 illustrates transform queue module 230 servicing a four-entry transform walk, although it will be understood that the teachings herein support any number of transform walk queues within transform queue module 230. Each entry within transform queue module 230 can independently service a transform request using any of architected transform entries 232-238, sometimes referred to herein as transform modules. For example, a transform walk mode may include HPT transform 232, segment table transform 234, non-nested radix transform 236, nested radix transform 238, etc. In one embodiment, transform queue module 230 includes sequence module 239 that operates to provide round-robin arbitration between different transform walk queue entries 232-238. Each of these transform walk queue entries 232-238 may be of a different type. For example, transformation walk queue entry 232 can perform a segment table walk, transformation walk queue entry 234 can perform a nested radix walk, transformation walk queue entry 236 can perform a non-nested radix walk, etc. Thus, architecture 200 automatically supports different modes of threading.

[0048] In addition to the queue entries 232-238, the architecture 200 includes a unified translation walk address generation (UTWAG) module 260 that operates to generate all intermediate addresses appropriate for ultimately achieving the RA. Significantly, the UTWAG is configured so that the memory access interface 212, translation cache (XLTC) 204, XLTC interface 206 (a read / write interface sometimes referred to herein as the XLTC interface 206), and translation request interface 202 are shared by all translation support 262-272. The UTWAG module 260 also provides the ability for translation modes to share translation functionality of one mode with translation functionality of another mode, as described in more detail below. Each processor cycle can be an entirely different thread mode. The iterative process of translation walk queue entries 232-238, combined with the UTWAG, results in efficient use of chip real estate, reduced power consumption, and improved performance for translation requests.

[0049] For example, consider a Power10 (P10) processor when a load / store unit or instruction fetch unit 202 requests that an effective address (EA) be translated. This request may be sent to a translation cache (XLTC) 204, which contains previous translation results. These previous translations may be EA-to-virtual address (VA) translations, VA-to-RA translations, or direct EA-to-RA translations, depending on the address translation mode. If no previous results are found in the XLTC 204, the translation request 202 is allocated to one of the translation walk queue entries 232-238. As part of the request, context information defining the translation mode is provided along with the initiating EA. For example, in the PowerPC® architecture, this could be a segment table EA-to-virtual address translation, a hashed page table virtual address-to-real address translation, or a radix EA-to-RA translation.

[0050] Each translation request includes an address (e.g., EA or VA) along with context information (e.g., the mode of the request). Context information is used to start a translation walk queue entry. Every translation mode includes a "Partition Table Entry" (PATE) 262 that defines the base address of the respective translation table (segment table, hashed page table, or radix (level 1) table). The UTWAG module 260 efficiently provides this common function by generating the addresses of the PATE and RA in memory 214 for each mode.

[0051] Example Process With the above overview of example architectures 100 and 200, it may be helpful to now consider a high-level discussion of example processes. Accordingly, FIGS. 3 and 4 present example processes 300 and 400 for translating memory addresses having different modes consistent with illustrative embodiments. Processes 300 and 400 are each illustrated as a collection of blocks in a logical flow chart illustrating a sequence of operations that may be implemented in hardware, software, or a combination thereof. In the software context, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, and the like that perform a function or implement an abstract data type. Within each process, the order in which the operations are described is not intended to be limiting, and any number of the described blocks may be combined in any order and / or performed in parallel to implement the process. For purposes of discussion, processes 300 and 400 are described with reference to the architecture of FIG. 2.

[0052] Figure 3 is an example process for handling HPT requests and segment table requests while sharing various components of the unified translation system 200 of Figure 2. For example, the memory access interface 212, translation cache (XLTC) 204, XLTC interface 206, read / write interface, and translation request interface 202 are shared by all translation modes used in response to HPT requests 302 and segment table requests 304.

[0053] At block 303, an HPT is received that includes a virtual address (VA) and a context indicating the mode of the translation request. At block 310, the virtual address is hashed to a page table entry (PTE) group real address (GEN PTEG RA) and sent to memory 214. At block 312, the system waits a predetermined period to receive the PTE from memory.

[0054] At block 314, the PTE is searched for a PTE hit. If there is no PTE hit (i.e., there is a "MISS"), the translation queue module 230 identifies the address (e.g., the VA provided by the translation request) as an exception. For example, the FSM next state generation module 220 will transition to an "exception" state. However, if there is a PTE "HIT," the process continues at block 324, and the translation cache (XLTC) 204 is updated with the RA.

[0055] Process 300 also shows another entry point, shown as segment table request 301. At block 302, upon receiving a segment table request including an effective address (EA), a partition table entry is generated (GEN PATE) based on the provided translation request context. At block 304, the system waits a predetermined period of time until the partition table entry is generated. At block 306, a segment table entry group virtual address (STEG VA) is generated. In other words, an intermediate virtual address (VA) is provided. The segment table entry group (STEG), being a virtual address, requires its own translation (i.e., because it is an intermediate translation of a real address).

[0056] In block 308, in one embodiment, the translation cache (XLTC) 204 is checked to determine whether this virtual address (VA) has been previously translated. If this virtual address (VA) has not been previously translated and is therefore not available in the translation cache (XLTC) 204 (i.e., a "MISS" at decision block 308), the process continues with blocks 310-314, which are seamlessly integrated with the HPT request 303 discussed above. In other words, logic and / or hardware already used for the HPT request 303 can be successfully reused for the segment table request walk 301.

[0057] More specifically, at block 310, the virtual address is hashed into a page table entry (PTE) group real address (GEN_PTEG_RA) and sent to memory 214. At block 312, the system waits a predetermined period to receive the PTEG from memory. At block 314, the PTEG is searched for a PTE "hit." If there is no PTE "hit" (i.e., there is a "MISS" at decision block 314), the system identifies the address as an exception. However, if there is a PTE "hit," the process continues at block 316, where the translation cache (XLTC) 204 is updated with the real address (RA). This real address (RA) is sent to memory 214, and the process continues at block 318, where a segment table entry group real address is provided (GEN_STEG_RA) and sent to memory 214. At block 320, the system waits a predetermined period to receive the segment table entry group (STEG) data from memory 214.

[0058] At block 322, a segment table entry group search is performed (SEARCH STEG). If the search is successful (i.e., a "hit" at decision block 322), the process continues at block 324, where the translation cache (XLTC) 204 is updated with the VA. The goal of a segment table translation request is to translate from an EA to a VA by using a segment table entry (STE). More specifically, the EA portion and corresponding virtual address found in the STE are stored in the XLTC 204 so that further accesses to the same EA page will be a "hit" to avoid a "miss" on the next search.

[0059] However, if the SEARCH STEG is not successful (i.e., a "MISS" at decision block 322), the process returns to block 306 and the iterative process continues. For example, this iterative loop function could include four separate iterations.

[0060] Returning to block 308, if the virtual address has previously been translated (i.e., a "hit" at decision block 308), the process is substantially simplified and goes directly to block 318, and the process continues as discussed above.

[0061] If the address mode included in the request context information 202 is for a radix EA-to-RA translation, a different flow follows, which also efficiently shares the XLTC interface 206 and the memory access interface 212. For example, some processors use a four-deep radix tree for effective-to-physical translation in native applications. There can be four layers in the tree, with the fourth layer, L4, being the root of the tree. Each node in the tree contains a table that points to the node at the subsequent level of the tree. The node fills a single physical memory frame. Each table entry maintains the physical frame number (e.g., a pointer) of the child node and the OS-imposed permissions for the entire subtree. The translation process, sometimes referred to herein as a page table walk, is iterative, traversing a path from the root to the leaf node. At each step, subsequent bit sets from the source effective address (EA) are used to index the tables at subsequent nodes along the path.

[0062] In this regard, reference is now made to Figure 4, which is an example process flow for addressing both nested and non-nested radix requests. To avoid confusion, process 400 is separate from process 300 of Figure 3; it will be understood that these processes may be integrated. In process 400, nested radix flows are provided by solid lines, while non-nested flows are provided by dashed lines.

[0063] At block 401A, a non-nested radix request is received, which includes an effective address and a context indicating the mode of the request (i.e., the non-nested radix). Upon receiving the non-nested radix request, at block 402, a partition table entry is generated (GEN PATE) based on the received translation context. At block 404, the system waits a predetermined period of time until the partition table entry is generated.

[0064] The process then proceeds to block 410, where a host real address is generated (GEN HOST RA), first for L1. Radix examines a series of tables that are referenced sequentially. When L1 is accessed, it contains a pointer to the L2 host table, and so on. Four such tables are walked, as indicated by blocks 410-416, until the correct page table entry PTE is identified. The process then continues to block 424, where the translation cache (XLTC) 204 is updated with the RA.

[0065] As noted above, process 400 can also handle nested radix requests. For example, at block 401B, a nested radix request is received that includes an effective address and a context (i.e., a nested radix) indicating the mode of the request. At block 402, when the nested radix request is received, a partition table entry is generated (GEN PATE) based on the received translation context. At block 404, the system waits a predetermined period until the partition table entry generation is complete.

[0066] The process then continues at block 406, where a guest real address is generated (GEN GUEST RA) for each of the four radix levels L1 through L4. In other words, the effective address generates a guest level address that is further refined before the address can be sent to memory, as discussed in more detail below.

[0067] At block 408, in one embodiment, the translation cache (XLTC) 204 is checked to determine whether this guest real address has been previously translated. If this guest real address has not been previously translated (i.e., a "miss" at decision block 308), the process continues at block 410, where a host address is generated (GEN HOST RA), first for L1. As in the non-nested case discussed above, the radix examines a series of successively referenced tables, as indicated by blocks 410-416, until the correct page table entry (PTE) is identified. The process then continues at block 418, where the translation cache (XLTC) 204 is updated with the RA.

[0068] In block 420, a host real address is generated (GEN HOST RA). In this regard, note that in the case of nested radixes, the EA-to-RA translation is included in the guest L4 entry. Each guest entry (L1, L2, L3, L4) is initially addressed by a guest RA. However, the guest RA cannot be sent to memory 214, as discussed above, and therefore is translated to a host RA. Block 420 is the host RA translated from the guest RA (block 406).

[0069] At block 422, the system waits for the end of the guest table entry for the subject radix level (e.g., L1). The iterative process continues by returning to block 406 until all radix levels (i.e., L1 through L4 in this example) have been evaluated for guest table entries. The process continues at block 424, where the translation cache (XLTC) 204 is updated with the RA.

[0070] Returning to block 408, if the guest address has previously been translated (i.e., there is a "hit" at decision block 408), the process is substantially simplified and goes directly to block 420, and the process continues as discussed above.

[0071] Example Computer Platform In one embodiment, the functionality associated with providing a unified memory address translation system may be implemented using one or more computing devices. Figure 5 provides an example functional block diagram of a computer hardware platform 500 that may be used to host a unified translation walk address generation (UTWAG) module 540.

[0072] The computer platform 500 may include a central processing unit (CPU) 504, a hard disk drive (HDD) 506, random access memory (RAM) and / or read only memory (ROM) 508, a keyboard 510, a mouse 512, a display 514, and a communication interface 516 connected to a system bus 502.

[0073] In one embodiment, HDD 506 has capabilities including storing programs capable of executing various processes, such as UTWAG engine 540, in the manner described herein. UTWAG engine 540 can have various modules configured to perform different functions, such as those discussed in the context of FIG. 2 and other figures. For example, there can be PATE RA GEN 542, STEG VA GEN 544, STEG RA GEN 546, PTEG RA GEN 548, RADIX HOST RA GEN 550, and RADIX GUEST RA GEN 552 modules that perform the functions discussed herein. While modules 542-552 are shown in FIG. 5 as being part of HDD 506, in some embodiments, one or more of these modules can be implemented in the hardware of computing device 500. For example, the modules discussed herein can be implemented in part in hardware and part in software. 5 may be implemented in the form of an electronic circuit having transistor(s), diode(s), capacitor(s), resistor(s), inductor(s), varactor(s), or memristor(s), or a combination thereof. In other words, UTWAG engine 540 may be implemented by one or more specially designed electronic circuits that perform the specific tasks and functions described herein by components of the CPU and / or modules of RAM / ROM 508.

[0074] Example Cloud Platform As discussed above, functionality associated with providing a unified memory address translation system may include a distributed computing architecture, a distributed storage architecture, or both, such as in the case of a cloud. While the present disclosure includes detailed descriptions of cloud computing, it is understood that implementation aspects of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present disclosure may be implemented in conjunction with any other type of computing environment now known or later developed.

[0075] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0076] The characteristics are as follows:

[0077] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without requiring human interaction with the provider of the service.

[0078] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0079] Resource Pooling: A provider's computing resources are pooled and served to multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge over the exact location of the resources provided, although a sense of location independence exists in that they may be able to specify a location at a higher level of abstraction (e.g., country, nation, or data center).

[0080] Rapid Elasticity: Capacity is provisioned quickly and elastically, in some cases automatically, and can be rapidly scaled out and rapidly released to rapidly scale in. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any amount at any time.

[0081] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both providers and consumers of utilized services.

[0082] The service model is as follows:

[0083] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0084] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire on cloud infrastructure, written using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configuration.

[0085] Infrastructure as a Service (IaaS): The capability provided to the consumer is to supply processing, storage, network, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but rather has control over the operating system, storage, deployed applications, and perhaps limited control over select networking components (e.g., host firewalls).

[0086] The deployment model is as follows:

[0087] Private Cloud: This cloud infrastructure serves only the organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0088] Community Cloud: This cloud infrastructure is shared by several organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0089] Public Cloud: This cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0090] Hybrid Cloud: This cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that allow data and application portability (e.g., cloud bursting for load balancing between clouds).

[0091] Cloud computing environments are service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0092] Referring now to FIG. 6, an illustrative cloud computing environment 600 is shown. As shown, the cloud computing environment 600 includes one or more cloud computing nodes 610 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 654A, a desktop computer 654B, a laptop computer 654C, or an automobile computer system 654N, or combinations thereof, can communicate. The nodes 610 can communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as the private cloud, community cloud, public cloud, or hybrid cloud described above, or combinations thereof. This enables the cloud computing environment 650 to provide infrastructure as a service, platform as a service, or software as a service, or combinations thereof, without the cloud consumer having to maintain resources on their local computing devices. It is understood that the types of computing devices 654A-N shown in FIG. 6 are intended to be illustrative only, and that computing node 610 and cloud computing environment 650 can communicate with any type of computerized device (e.g., using a web browser) over any type of network and / or any type of network-addressable connection.

[0093] Referring now to Figure 7, a set of functional abstraction layers provided by cloud computing environment 650 (Figure 6) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 7 are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0094] The hardware and software layer 760 includes hardware and software components. Examples of hardware components include mainframes 761, RISC (Reduced Instruction Set Computer) architecture-based servers 762, servers 763, blade servers 764, storage devices 765, and networks and networking components. In some embodiments, software components include network application server software 767 and database software 768.

[0095] The virtualization layer 770 provides an abstraction layer from which the following example virtual entities may be provided: virtual servers 771, virtual storage 772, virtual networks including virtual private networks 773, virtual applications and operating systems 774, and virtual clients 775.

[0096] In one example, the management layer 780 can provide the following functions: Resource provisioning 781 enables dynamic procurement of computing resources and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 782 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 783 provides access to the cloud computing environment for consumers and system administrators. Service level management 784 provides cloud computing resource allocation and management to meet requested service levels. Service level agreement (SLA) planning and execution 785 enables advance arrangement and procurement of cloud computing resources, with future requirements for those resources anticipated according to the SLA.

[0097] The Workload Layer 790 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 791, software development and lifecycle management 792, virtual classroom instruction delivery 793, data analytics processing 794, transaction processing 795, and unified transformation engine 796, as discussed herein.

[0098] The description of various embodiments of the present teachings has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many changes and modifications will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best explain the principles of the invention, practical applications, or technical improvements over technology found in the marketplace, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0099] While the above describes what is believed to be the best mode and / or example, it is understood that various modifications may be made therein, and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be adapted for use in numerous applications, only some of which are described herein. It is intended by the appended claims to claim any and all applications, modifications, and variations that fall within the true scope of the present teachings.

[0100] The components, steps, features, objects, benefits, and advantages discussed herein are illustrative only. Neither they nor the discussions related thereto are intended to limit the scope of protection. While various advantages have been discussed herein, it will be understood that not all embodiments necessarily include all advantages. Unless otherwise stated, all measurements, values, orders, positions, dimensions, sizes, and other specifications set forth herein, including in the appended claims, are approximate rather than precise. They are intended to have a reasonable range consistent with the function to which they relate and that which is customary in the technical field to which they pertain.

[0101] Numerous other embodiments are contemplated, including embodiments having fewer, additional, and / or different components, steps, features, objects, benefits, and advantages, including embodiments in which components and / or steps are arranged and / or ordered differently.

[0102] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0103] These computer-readable program instructions may be provided to a processor of a suitably configured computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in such a way that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0104] The computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process that causes the computer, other programmable apparatus, or other device to perform a series of operational steps, such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0105] The call flows, flowcharts, and block diagrams in the figures herein illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially in parallel, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware instructions and computer instructions.

[0106] While the above has been described in conjunction with exemplary embodiments, it is understood that the term "exemplary" is meant merely as an example, not as best or optimal. Except as set forth above, nothing described or illustrated is intended to, or should be construed to, result in the provision to the public of any component, step, feature, object, benefit, advantage, or equivalent, whether in the claims or not recited in the claims.

[0107] It will be understood that the terms and expressions used herein have the ordinary meanings ascribed to such terms and expressions with respect to their corresponding respective areas of investigation and study, unless a specific meaning is ordinarily stated herein. Related terms such as first, second, and the like may be used merely to distinguish one entity or operation from another, without necessarily requiring or suggesting any actual relationship or order between such entities or operations. The term "comprises" or "comprises" may be used interchangeably with "comprises" or "comprises" to refer to a specific entity or operation. comprises The use of "a," "comprising," or any other variation thereof is intended to cover a non-exhaustive inclusion, such that a process, method, article, or apparatus comprising a list of elements may include not only those elements, but also other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "a" or "an" does not, without further constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that comprises that element.

[0108] The Abstract of the present disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the above Detailed Description, various features may be found grouped together in various embodiments to streamline the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the appended claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the appended claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. 1. A unified memory address translation system, comprising: a translation queue module configured to receive translation requests of different modes for real addresses (RA) of the physical memory; a translation cache (XLTC) interface configured to receive successful translation results for a previous request for RA and to provide the previous successful translation results to the translation queue module; at least one of a page table entry group (PTEG) lookup module or a segment table entry group (STEG) lookup module coupled to the translation queue module; a unified translation walk address generation (UTWAG) module configured to provide translation support for each of the different modes of translation requests; a memory interface coupled between said UTWAG module and said physical memory; Equipped with each of the transformation requests is processed by a sequence module of the transformation queue module; system.

2. 2. The system of claim 1, wherein the sequence module of the conversion queue module is configured to provide round-robin arbitration among the conversion requests.

3. 3. The system of claim 1, wherein the XLTC interface, the PTEG search module, the STEG search module, and the conversion queue module are shared by all conversion modes.

4. The different mode conversion request is: Hashed Page Table (HPT) requests, Segment table request, Non-nested radix requests, and Nested Radix Requests 4. The system according to claim 1, further comprising at least one of:

5. The conversion support of the UTWAG module includes: Partition table entry real address generation (PARTITION TABLE ENTRY GENERATION); a segment table entry group virtual address generation (STEG VA GEN) that operates to provide effective address (EA) to virtual address (VA) translations; a segment table entry group real address generation (STEG RA GEN) that operates to define intermediate virtual address (STEG VA) to real address (RA) translations; Page Table Entry Group Real Address Generation (PTEG RA GEN), Radix Host Real Address Generation (RADIX HOST RA GEN), or Radix Guest Real Address Generation (Radix Guest RA Gen) 5. The system according to claim 1, further comprising at least one of:

6. 6. The system of claim 1, further comprising a finite state machine coupled to each transformation queue entry of the transformation queue module.

7. The system of claim 6 , wherein the finite state machine is shared by all transformation support of the UTWAG module.

8. 1. A method for providing a unified memory address translation, comprising: receiving, by a translation queue module, a plurality of translation requests of different modes for a real address (RA) of a physical memory; allocating, by a sequence module, each of the plurality of transformation requests to a plurality of transformation walk queue entries of the transformation queue module; For each transformation walk queue entry, determining a starting virtual address (VA) and a translation mode from the corresponding translation request; providing the VA and translation mode to a unified translation walk address generation (UTWAG) module that includes multiple translation support for different translation modes; and converting the VA to an RA by the UTWAG module based on the conversion mode; A method comprising:

9. 9. The method of claim 8, wherein one of the plurality of conversion requests is received by a conversion cache (XLTC) interface from a conversion cache (XLTC) that operates to store one or more previous successful conversion results.

10. The plurality of conversion requests include: Hashed Page Table (HPT) requests, Segment table request, non-nested radix requests, or Nested Radix Requests 10. The method of claim 8 or 9, comprising at least one of:

11. 10. The method of claim 9, wherein the XLTC interface, one or more page table entry group (PTEG) search modules, and the translation queue module are shared by all translation modes.

12. 10. The method of claim 9, wherein the allocation of each transformation request to one transformation walk queue entry of the plurality of transformation walk queue entries occurs upon determining that no matching previous result is found in the XLTC.

13. 9. The method of claim 8, wherein each transformation walk queue entry is different for each clock cycle of the processor.

14. The method of any one of claims 8 to 13, further comprising providing round robin arbitration among the plurality of transformation walk queue entries.

15. The conversion support of the UTWAG module includes: Partition table entry real address generation (PARTITION TABLE ENTRY GENERATION); Segment Table Entry Group Virtual Address Generation (STEG VA GEN) which provides effective address (EA) to virtual address (VA) translation; Segment table entry group real address generation (STEG RA GEN) that defines intermediate virtual address (STEG VA) to real address (RA) translations; Page Table Entry Group Real Address Generation (PTEG RA GEN), Radix Host Real Address Generation (RADIX HOST RA GEN), or Radix Guest Real Address Generation (Radix Guest RA Gen) 15. The method of claim 8, further comprising providing at least one of:

16. 16. The method of claim 8, further comprising coupling a finite state machine to each transformation queue entry of the transformation queue module.

17. The method of claim 16 , wherein the finite state machine is shared by all translation modes.

18. 1. A computing device comprising: a processor; a memory coupled to the processor; A computing device comprising: a unified memory address translation system as described in any one of claims 1 to 7, wherein the UTWAG module is stored in the memory; and execution of the UTWAG module by the processor configures the computing device to provide the translation support for each mode of the different modes of translation requests.

Images