|Publication number||US9317428 B2|
|Application number||US 13/789,083|
|Publication date||Apr 19, 2016|
|Filing date||Mar 7, 2013|
|Publication number||13789083, 789083, US 9317428 B2, US 9317428B2, US-B2-9317428, US9317428 B2, US9317428B2|
|Inventors||Michael K. Gschwind|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (86), Non-Patent Citations (52), Classifications (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of co-pending U.S. Ser. No. 13/646,782, entitled “SUPPORTING MULTIPLE TYPES OF GUESTS BY A HYPERVISOR,” filed Oct. 8, 2012, which is hereby incorporated herein by reference in its entirety.
One or more aspects relate, in general, to memory of a computing environment, and in particular, to facilitating access to the memory.
System configurations include physical memory used to store applications and data. The amount of physical memory is fixed and often inadequate to support the needs of users. Therefore, to provide additional memory or at least the appearance of additional memory, a memory management technique, referred to as virtual memory, is utilized. Virtual memory uses virtual addressing, which provides ranges of addresses that can appear to be much larger than the physical size of main memory.
To access main memory in a system configuration that includes virtual memory, a memory access is requested that includes an effective address. The effective address is translated into a real address used to access the physical memory.
Translation is performed using an address translation technique. Several address translation techniques are available. For instance, in PowerPC systems offered by International Business Machines Corporation, an effective address is translated to a corresponding real address by way of page table entries found by selecting an effective segment identifier (ESID) table entry associated with the effective address, and using the entry to locate a group of page table entries by way of a hashing algorithm. In a further example, in the z/Architecture, also offered by International Business Machines Corporation, an effective address is translated to a corresponding real address by way of a hierarchy of translation tables. Translation tables are indexed by a portion of the effective address to find the address of the next translation table of the hierarchy until a real (or absolute) address is obtained. Both address translation techniques provide advantages to their respective operating systems.
Shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of facilitating translation of memory addresses. The method includes, for instance, providing, by a hypervisor executing within a computing environment, a first type of translation support for a first type of guest operating system supported by the hypervisor, the first type of translation support including a paravirtualization support in which the first type of guest operating system assists in handling address translation faults corresponding to host translations of guest memory addresses; and providing, by the hypervisor, a second type of translation support for a second type of guest supported by the hypervisor, the second type of translation support including a virtualization support in which handling address translation faults corresponding to host translations of guest memory addresses are handled entirely by a host, the host at least including the hypervisor.
Computer program products and systems relating to one or more aspects are also described and may be claimed herein. Further, services relating to one or more aspects are also described and may be claimed herein.
Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects.
One or more aspects are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and objects, features, and advantages of one or more aspects are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
In one aspect, a system configuration is provided that has different types of translation structures available to it for use in translating memory addresses from one format (e.g., an effective address, and in particular, a virtual address associated therewith) to another format (e.g., a real address). Multiple translation structure formats (e.g., multiple page table formats, such as hash page tables and hierarchical page tables) are concurrently supported in a system configuration.
Further, in one aspect, a system configuration is provided that includes multiple partitions that have differing translation mechanisms associated therewith. For instance, one partition has associated therewith a single level translation mechanism for translating guest virtual addresses to host physical addresses, and another partition has a nested level translation mechanism for translating guest virtual addresses to host physical addresses. The different translation mechanisms and partitions are supported by a single hypervisor. The hypervisor is, for instance, a paravirtualized hypervisor. Thus, in one aspect, faults, including host translation faults, associated with address translation of guest memory addresses in a single level translation mechanism are managed, at least in part, by the guest operating system. However, full virtualization is also provided for those partitions using nested level translations. With full virtualization, the guest operating system is not involved in managing address translation faults resulting from host level translations of guest memory addresses. The host translation faults are handled entirely by the host, without (or independent of) assistance from the guest operating system. To support full virtualization by a paravirtualization hypervisor, an adjunct component is provided that facilitates handling of address translation faults resulting from host level translations. As used herein, an adjunct component is a helper component connected, added or coupled to an entity, typically in an auxiliary manner, and not limited to any specific adjunct architecture.
Computing environments of different architectures may incorporate and use one or more aspects provided herein. For instance, environments based on the PowerPC architecture, also referred to as Power ISA, offered by International Business Machines Corporation and described in the Power ISA™ Version 2.06 Revision B specification, Jul. 23, 2010, incorporated herein by reference in its entirety, may include one or more aspects, as well as computing environments of other architectures, such as the z/Architecture, offered by International Business Machines Corporation, and described in z/Architecture—Principles of Operation, Publication No. SA22-7932-08, 9th Edition, August 2010, which is hereby incorporated herein by reference in its entirety.
One example of a computing environment to incorporate and use one or more aspects is described with reference to
Memory management unit 104 is used in managing memory portion 108 including facilitating access to the memory by providing address translation. To improve address translation, the memory management unit utilizes a translation lookaside buffer (TLB). The TLB is a cache of previously translated addresses. Thus, when a request is received for a memory access that includes an address to be translated, the TLB is checked first. If the address and its translation are in the TLB, then no translation is necessary. Otherwise, the received address is translated using one of any number of translation techniques.
A further embodiment of a computing environment to incorporate and use one or more aspects of the present invention is depicted in
In this embodiment, each virtual machine is capable of hosting a guest operating system 168 and may be executing one or more applications 170. An operating system or application running in a virtual machine appears to have access to a full complete system, but in reality, only a portion of it is available.
Central processors 156 (e.g., central processing units) are physical processor resources that are assignable to a virtual machine. For instance, virtual machine 154 includes one or more logical processors, each of which represents all or a share of a physical processor 156 that may be dynamically allocated to the virtual machine. Virtual machines 154 are managed by hypervisor 158, such as PowerVM, offered by International Business Machines Corporation, as examples.
Central processor 156, like CPU 102, includes at least one MMU/TLB portion and at least one cache.
Input/output subsystem 160 directs the flow of information between devices and memory (also referred to herein as main memory or main storage). It is coupled to the server in that it can be part of the server or separate therefrom. The I/O subsystem relieves the central processors of the task of communicating directly with the I/O devices coupled to the server and permits data processing to proceed concurrently with I/O processing.
Further details regarding the physical memory used by either system, such as memory 108 or memory 162, and access thereto are described with reference to
Further details regarding a segment lookaside buffer and a page table are described with reference to
Effective segment ID (ESID) 302 (bits 0-35);
Entry valid indicator (V) 304 (bit 36) which indicates whether the entry is valid (V=1) or invalid (V=0);
Segment sized selector (B) 306 (bits 37-38), which has the following meaning, in one example: 0b00-256 Megabytes (MB) (s=28), 0b01—1 Terabyte (TB) (s=40), 0b10—256 TB (s=48), and 0b11—reserved;
Virtual segment ID (VSID) 308 (bits 39-88);
Supervisor (privileged) state storage key (Ks) 310 (bit 89);
Problem state storage key (Kr) 312 (bit 90);
No-execute segment if N=1 indicator (N) 314 (bit 91);
Virtual page size selector bit 0 (L) 316 (bit 92);
Class indicator (C) 318 (bit 93);
Virtual page size selector bits 1:2 (LP) 322 (bits 95-96); and
Radix segment indicator (RS) 326 (bit 99), which, in one example, 0 indicates disabled and 1 indicates enabled. When RS=1, the virtual address used for the hash page table search has the lowest S (encoded in SLBEB) number of bits set to zero.
In one embodiment, instructions cannot be executed from a no-execute (N=1) segment. Segments may contain a mixture of page sizes. The L and LP bits specify the base virtual page size that the segment may contain. The SLBL|LP encodings are those shown below, in one example:
encoding base page size 0b000 4 KB 0b101 64 KB additional values 2b bytes, where b > 12 and b may differ among encoding values,
where the “additional values” are implementation-dependent, as are the corresponding base virtual page sizes. The values that are not supported by a given implementation are reserved in that implementation.
The base virtual page size also referred to as the base page size is the smallest virtual page size for the segment. The base virtual page size is 2b bytes. The actual virtual page size (also referred to as the actual page size or virtual page size) is specified by PTEL|LP.
The Class field is used in conjunction with the SLB Invalidate Entry (SLBIE) and SLB Invalidate All (SLBIA) instructions. Class refers to a grouping of SLB entries and implementation-specific lookaside information so that only entries in a certain group need be invalidated and others might be preserved. The class value assigned to an implementation-specific lookaside entry derived from an SLB entry is to match the class value of that SLB entry. The class value assigned to an implementation-specific lookaside entry that is not derived from an SLB entry (such as real mode address translations) is 0.
Software is to ensure that the SLB contains at most one entry that translates a given instruction effective address. An attempt to create an SLB entry that violates this requirement may cause a machine check.
As described herein, at least one field of the SLB is used to access a page table, and in particular, a specific page table entry. Further information regarding a page table and page table entries is described with reference to
Referring initially to
In one example, the hash page table contains page table entry groups (PTEGs). A page table entry group contains, for instance, eight page table entries of 16 bytes each; each page table entry group is thus 128 bytes long. PTEGs are entry points for searches of the page table.
Further details of a page table entry are described with reference to
0b00 - 256 MB; 0b01 - 1 TB;
0b10 - 256 TB; 0b11 - reserved
Abbreviated Virtual Address
Available for software use
Virtual page size
0b0 - 4 KB
0b1 - greater than 4 KB (large page)
Hash function identifier
Entry valid (V = 1) or invalid (V = 0)
Page Protection bit 0
KEY bits 0:1
Abbreviated Real Page Number
Large page size selector
Virtualized real address of Radix Table
(when SLBERS = 1 or VRMASDRS = 1)
KEY bits 2:4
Storage control bits
No-execute page if N = 1
Page Protection bits 1:2
Further details regarding one implementation of page tables and page table entries are described in Power ISA™ Version 2.06 Revision B specification, Jul. 23, 2010, offered by International Business Machines Corporation and incorporated herein by reference in its entirety.
The use of a hash page table to translate addresses is only one example of a translation technique. Other address translation schemes, including those that use a hierarchy of translation tables, are described below, as well as in the following publications: z/Architecture—Principles of Operation, Publication No. SA22-7932-08, 9th Edition, August 2010, and Intel Itanium Architecture Software Developer's Manual Volume 2: System Architecture, Document Number: 245318-005, each hereby incorporated herein by reference in its entirety. In one example, for the z/Architecture, the hierarchy of tables is referred to as dynamic address translation (DAT) tables; and for Power ISA, the tables are referred to as radix tables.
One example of a hierarchical translation table translation mechanism is described with reference to
The page table entry located by traversing the hierarchical page tables includes various information including at least a portion of a real address used to access the physical memory. The format and information included in the page table entry depends on the architecture of the system configuration and/or the specific type of translation.
In one example in which the address translation is the DAT translation of the z/Architecture, a page table entry 600 includes the following, as depicted in
Page-Frame Real Address (PFRA) (602): Bits 0-51 provide the leftmost bits of a real storage address. When these bits are concatenated with the 12-bit byte index field of the virtual address on the right, a 64-bit real address is provided;
Page-Invalid bit 604 (I): Bit 53 controls whether the page associated with the page table entry is available. When the bit is zero, address translation proceeds by using the page table entry. When the bit is one, the page table entry is not to be used for translation;
DAT-Protection Bit (P) 606: Bit 54 controls whether store accesses can be made in the page. This protection mechanism is in addition to the key-controlled-protection and low-address-protection mechanisms. The bit has no effect on fetch accesses; and
Change-Recording Override (CO) 608: When enhanced DAT does not apply, bit 55 of the page-table entry is to contain zero; otherwise, a translation-specification exception is recognized as part of the execution of an instruction using that entry for address translation. When enhanced DAT applies and a segment table entry (STE) format control is zero, bit 55 of the page-table entry is the change-recording override for the page.
As a further example in which the address translation is the radix translation of Power ISA, a page table entry includes the following fields, as depicted in
No-execute page if N = 1
Page Protections 0
KEY bits 0:4
Abbreviated Address (concatenated with twelve zeros)
Available for software
0 - is Page Directory Entry (PDE) (0-1, 52-55, 57-62
1 - is Page Table Entry (PTE)
Page Protections 1:2
Valid Entry Indicator
In accordance with one aspect, a system configuration is provided with different types of address translation structures for use in translating addresses. As examples, one type uses a hierarchical data structure (e.g., a radix structure), and another type uses a hash data structure. Other and/or different types of structures may also be used, including, for instance, a combination of a hierarchical and a hash structure, or an offset structure, as examples. Further, in one example, the type of translation structure to be used for a particular translation is selectable.
One embodiment of the logic to select from a plurality of translation mechanisms to translate an address is described with reference to
Based on the effective address in the translation request, a guest virtual address is obtained and translated within the partition to a guest physical address using a selected translation format, such as, for instance, a radix translation, STEP 702. A determination is made as to whether a translation event has occurred based on the translation from the guest virtual address to the guest physical address, INQUIRY 704. If a translation event has occurred, then that event (e.g., radix table miss), along with the guest virtual address, is presented from the hardware to the operating system using an instruction storage interrupt (ISI) or data storage interrupt (DSI) depending on whether the translation that resulted in a fault corresponded to an instruction or data access, STEP 706. However, if there was no translation event, then the guest virtual address has been translated to the guest physical address.
Next, a determination is made as to the type of translation to be selected to translate the guest physical address to the host physical address, INQUIRY 708. In the example herein, it is either a hierarchical translation mechanism (e.g., radix) or a hash page table translation mechanism that is selected; however, in other embodiments, other types of translation mechanisms may be selected, such as an offset mechanism or other types. In one embodiment, the selection of the translation mechanism is dependent on the type of hypervisor that is configuring the system for translation, and the preference of that hypervisor; and/or the selection may be based on the condition of the memory. For instance, if host memory has little fragmentation or large pages, a radix or other hierarchical translation mechanism may be selected; for heavily fragmented host memory, a hash page table translation mechanism may be selected; and for static partitions, an offset translation mechanism may be selected. Other selection criteria are also possible.
Further, in one embodiment, selection may be performed at various levels of translation including, for instance, from guest virtual to guest physical, and/or from guest physical to host physical, and each selection is independent of the other. That is, the selection of a particular structure at one level (e.g., guest level) has no bearing on the selection at another level (e.g., host level).
The selection, in one example, is configured by the hypervisor for the system by setting one or more indicators in one or more control registers, other registers, or memory, subsequent to making the selection and prior to receiving a translation request. In another example, the selection is made dynamically by, for instance, the hypervisor or operating system, at the time of the translation, and that selection is provided to the hardware or firmware.
Continuing with INQUIRY 708, if a radix (or other hierarchical) translation is selected for the host translation, then the guest physical address is translated to the host physical address using a radix (or other hierarchical) translation, STEP 710. However, if hash page table translation has been selected, then the guest physical address is translated to the host physical address using a hash page table translation, STEP 712. Other translation mechanisms may also be selected, although, not shown in this particular example.
If a translation event occurs during translation of the guest physical address to the host physical address, INQUIRY 714, then that event is indicated to the hypervisor via a host instruction storage interrupt (HISI)/host data storage interrupt (HDSI), in which the guest's physical address is specified, STEP 716. If a translation event has not been indicated, then the guest physical address has been translated to the host physical address, and the host physical address is usable for the memory access.
Should the hypervisor be interrupted via an HISI or HDSI, the hypervisor performs certain processing, an example of which is depicted and described with reference to
Returning to INQUIRY 762, if radix guest translation is enabled, in one embodiment, the partition fault address (e.g., the guest physical address) to be translated is obtained by the operating system from the hardware, STEP 768. Further, a translation entry for that address is obtained from a memory map to load the host translation table, STEP 770. The translation entry that is obtained is installed in the host translation table (e.g., HPT or radix, in a further embodiment), STEP 772, and execution of the instruction having caused the HISI/HDSI is restarted, STEP 774.
For example, in one embodiment, host translation is performed using an HPT structure. In accordance with this embodiment, further to STEP 768, a translation entry for that address is obtained from a memory map to load the HPT, STEP 770. In accordance with another embodiment and in another execution, a host physical page has been paged out and is paged in prior to installing a translation entry. The translation entry that is obtained is installed in the HPT, STEP 772, and execution of the instruction having caused the HISI/HDSI is restarted, STEP 774. In another embodiment, host translation is performed by a radix structure. In accordance with this embodiment, further to STEP 768, a translation fault is handled for a radix table, e.g., a translation entry for that address is obtained from a memory map to load the radix table, STEP 770. In accordance with another embodiment and in another execution, a host physical page has been paged out and is paged in prior to installing a translation entry. The translation entry that is obtained is installed in the radix table, STEP 772, and execution of the instruction having caused the HISI/HDSI is restarted, STEP 774.
In one embodiment, multiple partitions of a guest/host system configuration supported by a single central processing unit architecture may be configured to use different address translation formats (e.g., different guest formats). For instance, one guest is configured to use a hierarchical translation format (e.g., radix) for guest translations, while another guest is configured to use a hash translation format for guest translations. Further, the guests may use different host translation formats. For instance, one guest may use a single level of translation, and thus, the same translation format used for the guest translation is used for the host translation. For instance, a hash translation format is used to translate a guest virtual address to a host physical address. Further, another guest may use a nested level of translation, and thus, one format (e.g., radix) may be used to translate the guest virtual address to a guest physical address, and another or the same format (e.g., hash, offset, radix) may be used to translate the guest physical address to a host physical address. In one example, both guests are supported by the same hypervisor.
Further details of one embodiment of configuring partitions for address translation are described with reference to
The above process is repeated for a second partition and any other partitions that are to be allocated. As shown, a second partition is allocated, STEP 804, and a configuration is created for the second partition, STEP 806. Again, other partitions may be allocated and configured.
In a further embodiment, the partition type and/or translation mechanism is selected at partition dispatch time, described below, via a hypervisor call. Further, a hypervisor call may be used to change the type of partition or the selected translation mechanism.
Thereafter, one or more partitions are dispatched as described with reference to
Subsequent to configuring and dispatching a partition, address translation may be provided for that partition. For instance, as shown in
In one embodiment, multiple partitions are supported by a single hypervisor, which is able to support paravirtualized partitions, as well as fully virtualized partitions. As used herein, a paravirtualized partition is a partition in which the operating system communicates with the hypervisor to handle address translation faults resulting from host level translation. That is, the guest updates the host's address translation tables; although, some information (such as, for example, the host physical address being used by the system to store a page) may be missing and is to be provided by the hypervisor. In contrast, a fully virtualized partition is one in which the guest operating system is ignorant of the host level translation. The operating system does not receive fault indications and does not manage such faults corresponding to host translation. The term “fully” is used herein simply to distinguish from “paravirtualization”. In particular, a system may be fully virtualized with respect to address translation in one partition, but not with respect to other system aspects (such as I/O operations).
The paravirtualized partitions, which use a single level of translation to translate a guest virtual address to a host physical address, and the fully virtualized partitions, which use a nested level of translation in which a guest virtual address is translated to a guest physical address within the partition, and then the guest physical address is translated to a host physical address, are supported, in one embodiment, by the single hypervisor. The hypervisor is of a particular kind, referred to herein as a paravirtualized hypervisor, but also supports full virtualization (e.g., without having to modify the hypervisor, in one embodiment). This is further described below with reference to
Referring initially to
Additionally, hypervisor 904 also supports guests 902 b. However, unlike guest 902 a, guests 902 b use a multilevel (a.k.a., nested) translation in which a guest virtual address is first translated to a guest physical address within the partition (e.g., using radix translation), and then the guest physical address is translated to the host physical address during host level translation using, for instance, radix translation, hash page table translation, etc. In this scenario, however, the guests are unaware of the hypervisor and do not communicate with the hypervisor. In one aspect of this scenario, the guests are unaware of the hypervisor with respect to host translation operations and do not communicate with the hypervisor with respect to host translations, but may be aware of the hypervisor with respect to other properties (e.g., such as I/O).
Thus, in one embodiment, to enable the hypervisor to also support guests 902 b, an adjunct component 950, as shown in
Further details regarding various mechanisms for handling address translation faults are described with reference to
One embodiment of the logic of using a full virtualization adjunct component to handle a miss is described with reference to
Further details regarding handling the miss notification are described with reference to
Further details regarding different types of translation structures, including a hierarchical translation structure, such as a radix translation structure, and variations thereof, such as a radix on radix translation structure (i.e., using a radix table for guest translation in conjunction with a radix table for host translation), and a radix on hash page table (HPT) translation structure (i.e., using a radix table for guest translation in conjunction with an HPT table for host translation) are described below with reference to
Referring initially to
In one example, radix translation structure 1102 includes, for instance, a plurality of radix structures, including a level 4 page directory (PD) 1102 a, a level 3 page directory 1102 b, a level 2 page directory 1102 c, and a level 1 page table (PT) 1102 d. Each page directory and page table includes a plurality of entries, referred to herein as page directory entries (PDEs) and page table entries (PTEs), respectively. (The L field of an entry indicates whether there are additional entries to be used in the translation.) The structures are indexed into, in this example, using a page number 1110 generated from a segment offset 1112 of the effective address.
To index into radix structure 1102, as one example, the first X (e.g., 9) bits of page number 1110 are used as an offset into PD 1102 a pointed to by radix table origin 1100. The contents of the selected PDE of PD 1102 a provides an address of PD 1102 b, and the next X bits of page number 1110 are used to index into PD 1102 b to obtain an address of PD 1102 c. Further, the next X bits of page number 1110 are used to access a selected PDE of PD 1102 c to obtain the address of the page table 1102 d. The next X bits of page number 1110 are used to access the selected PTE of PT 1102 d. The output of the PTE of PT 1102 d combined with byte portion 1114 of segment offset 1112 creates a physical address 1116, also known as a real address.
The above describes one embodiment of translating a virtual address to a physical address using radix translation. However, in the situation in which the virtual address is a guest virtual address, additional processing may be used to translate each guest address to a corresponding host address. One embodiment of this logic is described with reference to
Then, in guest structure 1202, the first X (e.g., 9) bits of the effective address (not shown) to be translated are used to index into the level 4 PD 1202 a to obtain a virtual real address of level 3 PD 1202 b. This virtual address is translated into a real address of level 3 PD 1202 b using radix host structure 1204, which is indexed into using the bits of the virtual real address of the level 3 PD, as described above. The second set of X bits of the effective address is then used to index into PD 1202 b to obtain a virtual real address of level 2 PD 1202 c. That address is then translated using host structure 1204 to obtain a real address of level 2 PD 1202 c. The third set of X bits of the effective address is used to index into PD 1202 c to obtain a virtual real address of PT 1202 d. The virtual real address is then translated using radix host structure 1204 to obtain a real address of level 1 PT 1202 d. The next X bits of the effective address are used to index into PT 1202 d to obtain a virtual real address. The virtual real address is translated using radix host structure 1204, and the output of that translation combined with a byte offset of the effective address is a host physical address 1206. In one example, using this type of translation, it takes 24 reads to translate an address, in the worst case.
In addition to the above, a radix on hash page table (HPT) translation mechanism is provided, in which the guest translations are via a radix structure and the host translations are via a hash page table structure. An example of a radix on hash page table translation is described with reference to
The first X (e.g., 9) bits of the effective address to be translated are used to index into PD 1304 a to obtain the pertinent contents. As in each of these translations, the contents of the selected level 4 page directory entry of PD 1004 a are checked to see if there are additional levels to be searched (e.g., is L=0), and if so, the virtual real address of PD 1304 b is used to hash into HPT 1302. Based thereon, the real address of a level 3 PD structure 1304 b is obtained. The next X bits of the effective address are used to index into PD 1304 b and this access provides a virtual real address of a level 2 structure 1304 c. This virtual address is used in hash structure 1302 to obtain a real address of structure 1304 c. The next X bits of the effective address are used to index into PD 1304 c to obtain a virtual real address of level 1 PT 1304 d, which is used to access the HPT. The output of the HPT access is the real address of a level 1 table 1304 d, which is used to obtain another virtual real address. Since implicitly L=1 as all levels in the page table have been exhausted, this is the last table of the radix structure, and therefore, this entry is the page table entry. The next X bits of the effective address are used to index into the page table to provide the guest physical address. The guest physical address is used to access the hash table. The output of the hash table combined with a byte offset of the effective address provides the host physical address 1306 corresponding to the effective address being translated.
In one embodiment, the guest page table pointer (e.g., guest page table pointer 1300; a.k.a., the virtual real address of the first table in the hierarchy of tables) is obtained using the hash table. This is described with reference to
More specifically, if the indicator specifies that multiple types of translation formats are to be used to translate the effective address of the request to a real address (i.e., SLBERS=1), then processing continues with obtaining the VSID from the SLBE. The VSID is used to locate an entry in one type of table (e.g., the hash table) in order to obtain the root of a another type of table (e.g., a hierarchical table, such as a radix table). In particular, in one example, the VSID is used to create a canonical address used to index into the HPT to obtain the RTABORG. A canonical address is an address created for a plurality of pages in a segment. That is, a particular segment includes a plurality of pages that share the same radix table. Therefore, the address used to index into HPT is to be the same for all those pages. In order to create the canonical address, the low order address bits for all the addresses that share the same radix table are zeroed out (and in one embodiment an appropriate constant is added). For instance, the virtual address obtained based on the effective address includes the VSID, and page and byte offsets. The VSID is used (optionally, along with the constant) to create the canonical address. The canonical address is used to index into the HPT to obtain the origin of the radix table (i.e., the virtual real address of the first table in the hierarchy of tables to be used in translation).
In addition to, or in lieu of, the translation mechanisms described above, other translation mechanisms may be used. One example of another type of translation mechanism is a radix on offset mechanism, in which a radix guest translation mechanism is used in conjunction with a host translation based on a real mode base and a real mode limit, an example of which is described with reference to
In this example, translation is performed using a real mode offset register (RMOR) and a real mode limit selector (RMLS) 1502 and a radix structure 1504. As described previously, radix structure 1504 includes, in this example, a level 4 PD 1504 a, a level 3 PD 1504 b, a level 2 PD 1504 c and a level 1 PT 1504 d, each including a plurality of PDEs or PTEs. A guest page table pointer 1500 (a.k.a., a virtual real address of PD 1504 a) is translated to a real address of PD 1504 a using a real mode offset register (RMOR) value and a real mode limit selector (RMLS). The RMOR is added to address 1500 and the result of the addition is compared to RMLS. If it is less than the limit, in this example, then the result is used to access PD 1504 a of radix table 1504. The radix table is walked, as described herein (e.g., using first X (e.g., 9) bits of the effective address), to obtain from the selected PDE of PD 1504 a a virtual real address of PD 1504 b. The base and limit are used again, but this time with the virtual real address of PD 1504 b to obtain the real address of PD 1504 b. Translation continues and when the selected PTE of PT 1504 d is located, a guest physical address is obtained which is translated using host structure 1502 to obtain an address that when concatenated with a byte offset of the effective address provides a host physical address to be used in translation.
Described in detail above are aspects in which multiple types of translation structures are included in a configuration. In one embodiment, it is selectable as to which translation mechanism(s) may be used to translate an effective address to a host real address. However, if the system configuration does not support such a feature or if it supports that feature, as well as legacy translation techniques, then legacy translation is provided.
One embodiment of the logic of a legacy translation technique in which a hash page table is used is described with reference to
Returning to INQUIRY 1608, if there is an HPT translation event, then the translation event is specified to either the operating system or hypervisor using, for instance, ISI/DSI or HISI/HDSI, STEP 1610. HPT event processing is performed, including optionally performing paging, STEP 1612. The operating system or hypervisor restarts the instruction, STEP 1614, and the flow returns to STEP 1600.
Returning to INQUIRY 1604, if there is an SLB generation event, then an SLB event is indicated to the operating system, STEP 1620. Further, SLB event processing is performed including, for instance, reloading the SLB (excluding paging), STEP 1622. The operating system restarts the instruction, STEP 1624, and processing continues with STEP 1600.
A further legacy technique for translating memory addresses is described with reference to
However, if there is a DAT translation event, INQUIRY 1704, then the translation event is either indicated to the operating system or hypervisor, STEP 1710. DAT event processing is performed in the operating system or hypervisor; optionally, performing paging, STEP 1712. Further, the operating system or the hypervisor restarts the instruction, STEP 1714, and processing continues to STEP 1700.
Described in detail above is a configuration that includes multiple types of translation structures to translate an effective address to a real address. Although examples of translation mechanisms are described, additional and/or different mechanisms may be used. Further, in one embodiment, a guest/host configuration is provided in which multiple partitions have differing translation mechanisms associated therewith. For instance, one partition has associated therewith a single level translation mechanism for translating guest virtual addresses to host physical addresses, and another partition has a nested level translation mechanism for translating guest virtual addresses to host physical addresses. Additionally, in one embodiment, operating systems that support a single level of translation may first generate a guest virtual address from an effective address using, for instance, an SLB. In yet a further embodiment, a processor identifier or address space identifier might be used to further specify a guest virtual address.
For nested level translation partitions, in one embodiment, the hypervisor creates a partition with a linear translated address space using a hash page table or another host translation architecture. The host table input for a partition ranges from 0x0000 to 0xMAXX. This translation is used as a second level of translation once a first level of translation is performed in the guest from a guest virtual address to a guest physical address. In one embodiment, the partition is not using HENTER/HREMOVE to manage replacements or updates to the host table. Instead, the hypervisor manages replacement of host table entries transparently when entries need to be updated/replaced in the host table. For each guest physical address to host physical address range, the hypervisor maintains a mapping to the host physical address. When a host table miss occurs, the hypervisor transparently loads the host translation table.
Additionally, in one aspect, a configuration is provided that enables a paravirtualized hypervisor to support different types of partitions, including those that expect the hypervisor to provide full virtualization (e.g., partitions that use nested translations) and those that use paravirtualization (e.g., partitions that use single level translation). An adjunct component is provided that installs the linear address space needed by a fully virtualized partition. It is packaged as a component that interacts with the hypervisor to install translations needed by a virtualized partition. The actual code can be included with the hypervisor, partition firmware, or operating system, but is segregated and distinct from the hypervisor and/or the operating system in terms of program logic. In embodiments, the adjunct component may run either in hypervisor or operating system privilege. If packaged with the hypervisor, although separate therefrom, it still has certain security trustworthiness, and therefore, less security checks need to be made when transferring control to the adjunct component.
In one example, the adjunct component creates a linear translated address space by allocating partition memory (e.g., using HPTs, or other host translation architecture). An address range input for a partition ranges from 0x0000 to 0xMAXX. This translation is used as a second level of translation once a first level of translation is performed in the guest from a guest virtual address to a guest physical address. The adjunct component uses HENTER to either pre-install translations, or install translations responsive to translation misses. The adjunct component manages replacement of HPTs (or other structures) transparently when entries need to be updated/replaced in the HPT (or other structures). For each guest address range, the adjunct component maintains a mapping to a host physical address. When an HPT (or other) miss occurs, the adjunct component transparently to the operating system loads the HPT (or other structure) To facilitate full-virtualization support, the hypervisor uses an adjunct component that can be included with the hypervisor or with the partition, and the adjunct component handles a fault on behalf of the hypervisor and the unsuspecting partition.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system”. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus or device.
A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Referring now to
Program code embodied on a computer readable medium may be transmitted using an appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for one or more aspects may be written in any combination of one or more programming languages, including an object oriented programming language, such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language, assembler or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
One or more aspects 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 invention. 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 program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of customer environments. For instance, the service provider can create, maintain, support, etc. computer code and/or a computer infrastructure that performs one or more aspects of the present invention for one or more customers. In return, the service provider may receive payment from the customer under a subscription and/or fee agreement, as examples. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.
In one aspect, an application may be deployed for performing one or more aspects of the present invention. As one example, the deploying of an application comprises providing computer infrastructure operable to perform one or more aspects of the present invention.
As a further aspect, a computing infrastructure may be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more aspects of the present invention.
As yet a further aspect, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer readable medium, in which the computer medium comprises one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.
Although various embodiments are described above, these are only examples. For example, computing environments of other architectures can incorporate and use one or more aspects of the present invention. Additionally, other types of translation structures may be used and other types of environments may benefit from one or more aspects. Additionally, the structures may have different fields and/or the fields can be of different sizes. Further, the number of bits used to index into a structure can be the same or different for each level, and/or for each structure. Moreover, one or more aspects may pertain to I/O. Many variations are possible.
Further, other types of computing environments can benefit from one or more aspects. As an example, an environment may include an emulator (e.g., software or other emulation mechanisms), in which a particular architecture (including, for instance, instruction execution, architected functions, such as address translation, and architected registers) or a subset thereof is emulated (e.g., on a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though a computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, the specific instruction or operation being emulated is decoded, and an appropriate emulation function is built to implement the individual instruction or operation.
In an emulation environment, a host computer includes, for instance, a memory to store instructions and data; an instruction fetch unit to fetch instructions from memory and to optionally, provide local buffering for the fetched instruction; an instruction decode unit to receive the fetched instructions and to determine the type of instructions that have been fetched; and an instruction execution unit to execute the instructions. Execution may include loading data into a register from memory; storing data back to memory from a register; or performing some type of arithmetic or logical operation, as determined by the decode unit. In one example, each unit is implemented in software. For instance, the operations being performed by the units are implemented as one or more subroutines within emulator software.
Further, a data processing system suitable for storing and/or executing program code is usable that includes at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memory which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/Output or I/O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives and other memory media, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising”, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain various aspects and the practical application, and to enable others of ordinary skill in the art to understand the various embodiments with various modifications as are suited to the particular use contemplated.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4456954||Jun 15, 1981||Jun 26, 1984||International Business Machines Corporation||Virtual machine system with guest architecture emulation using hardware TLB's for plural level address translations|
|US4680700||Dec 19, 1986||Jul 14, 1987||International Business Machines Corporation||Virtual memory address translation mechanism with combined hash address table and inverted page table|
|US4876646||Dec 18, 1985||Oct 24, 1989||Hitachi, Ltd.||Data processor having multilevel address translation tables|
|US5226168||Apr 24, 1990||Jul 6, 1993||Seiko Epson Corporation||Semiconductor memory configured to emulate floppy and hard disk magnetic storage based upon a determined storage capacity of the semiconductor memory|
|US5854913||Jun 10, 1997||Dec 29, 1998||International Business Machines Corporation||Microprocessor with an architecture mode control capable of supporting extensions of two distinct instruction-set architectures|
|US6393544||Oct 31, 1999||May 21, 2002||Institute For The Development Of Emerging Architectures, L.L.C.||Method and apparatus for calculating a page table index from a virtual address|
|US6430670||Nov 1, 2000||Aug 6, 2002||Hewlett-Packard Co.||Apparatus and method for a virtual hashed page table|
|US6671791||Jun 15, 2001||Dec 30, 2003||Advanced Micro Devices, Inc.||Processor including a translation unit for selectively translating virtual addresses of different sizes using a plurality of paging tables and mapping mechanisms|
|US6895491||Sep 26, 2002||May 17, 2005||Hewlett-Packard Development Company, L.P.||Memory addressing for a virtual machine implementation on a computer processor supporting virtual hash-page-table searching|
|US7089377||Sep 6, 2002||Aug 8, 2006||Vmware, Inc.||Virtualization system for computers with a region-based memory architecture|
|US7111145||Mar 25, 2003||Sep 19, 2006||Vmware, Inc.||TLB miss fault handler and method for accessing multiple page tables|
|US7395405||Jan 28, 2005||Jul 1, 2008||Intel Corporation||Method and apparatus for supporting address translation in a virtual machine environment|
|US7428626||Mar 8, 2005||Sep 23, 2008||Microsoft Corporation||Method and system for a second level address translation in a virtual machine environment|
|US7752417||Jun 5, 2006||Jul 6, 2010||Oracle America, Inc.||Dynamic selection of memory virtualization techniques|
|US7822941||Jun 5, 2006||Oct 26, 2010||Oracle America, Inc.||Function-based virtual-to-physical address translation|
|US7827381||Jun 5, 2006||Nov 2, 2010||Oracle America, Inc.||Hybrid techniques for memory virtualization in a computer system|
|US8078827||Jul 5, 2007||Dec 13, 2011||International Business Machines Corporation||Method and apparatus for caching of page translations for virtual machines|
|US8086822||May 14, 2009||Dec 27, 2011||Vmware, Inc.||In-place shadow tables for virtualization|
|US8103851||Jan 11, 2008||Jan 24, 2012||International Business Machines Corporation||Dynamic address translation with translation table entry format control for indentifying format of the translation table entry|
|US8127098||Feb 25, 2005||Feb 28, 2012||Globalfoundries Inc.||Virtualization of real mode execution|
|US8135937||Nov 17, 2008||Mar 13, 2012||International Business Machines Corporation||Logical partition memory|
|US8225071||Feb 8, 2011||Jul 17, 2012||Vmware, Inc.||Accessing multiple page tables in a computer system|
|US8244978||Feb 17, 2010||Aug 14, 2012||Advanced Micro Devices, Inc.||IOMMU architected TLB support|
|US8386747||Jun 11, 2009||Feb 26, 2013||Freescale Semiconductor, Inc.||Processor and method for dynamic and selective alteration of address translation|
|US20040210588||Apr 18, 2003||Oct 21, 2004||Simkins Mark B.||Methods and apparatus for address lookup|
|US20050193165||May 21, 2004||Sep 1, 2005||Takashi Sakaguchi||Storage system|
|US20060064567||May 23, 2005||Mar 23, 2006||Jacobson Quinn A||Translating loads for accelerating virtualized partition|
|US20060075146||Sep 30, 2004||Apr 6, 2006||Ioannis Schoinas||Address translation for input/output devices using hierarchical translation tables|
|US20070101099||Oct 26, 2006||May 3, 2007||Makiko Shinohara||Virtual machine control method and virtual machine system|
|US20070283123||Jun 5, 2006||Dec 6, 2007||Sun Microsystems, Inc.||Function-based virtual-to-physical address translation|
|US20070283125||Jun 5, 2006||Dec 6, 2007||Sun Microsystems, Inc.||Dynamic selection of memory virtualization techniques|
|US20080086620||Oct 6, 2006||Apr 10, 2008||Morris Robert P||Method and system for using a distributable virtual address space|
|US20080104362||Oct 25, 2006||May 1, 2008||Buros William M||Method and System for Performance-Driven Memory Page Size Promotion|
|US20080162864||Dec 27, 2006||Jul 3, 2008||Suresh Sugumar||Guest to host address translation for devices to access memory in a partitioned system|
|US20080189506||Feb 7, 2007||Aug 7, 2008||Brian Joseph Kopec||Address Translation Method and Apparatus|
|US20090037906||Apr 28, 2008||Feb 5, 2009||International Business Machines Corporation||Partition adjunct for data processing system|
|US20090037941||Apr 28, 2008||Feb 5, 2009||International Business Machines Corporation||Multiple partition adjunct instances interfacing multiple logical partitions to a self-virtualizing input/output device|
|US20090113164||Oct 30, 2007||Apr 30, 2009||Ramakrishnan Rajamony||Method, System and Program Product for Address Translation Through an Intermediate Address Space|
|US20090172341||Dec 31, 2007||Jul 2, 2009||Durham David M||Using a memory address translation structure to manage protected micro-contexts|
|US20090327648||Jun 30, 2008||Dec 31, 2009||Savagaonkar Uday R||Generating multiple address space identifiers per virtual machine to switch between protected micro-contexts|
|US20100011187||Sep 1, 2009||Jan 14, 2010||Ioannis Schoinas||Performance enhancement of address translation using translation tables covering large address spaces|
|US20100058358 *||Aug 27, 2008||Mar 4, 2010||International Business Machines Corporation||Method and apparatus for managing software controlled cache of translating the physical memory access of a virtual machine between different levels of translation entities|
|US20100125708||Nov 17, 2008||May 20, 2010||International Business Machines Corporation||Recursive Logical Partition Real Memory Map|
|US20100125709||Nov 17, 2008||May 20, 2010||International Business Machines Corporation||Logical Partition Memory|
|US20100180276||Jan 15, 2009||Jul 15, 2010||Jiva Azeem S||Application partitioning across a virtualized environment|
|US20100250499||Mar 31, 2009||Sep 30, 2010||Mcalister Grant Alexander Macdonald||Cloning and Recovery of Data Volumes|
|US20100250869||Mar 27, 2009||Sep 30, 2010||Vmware, Inc.||Virtualization system using hardware assistance for shadow page table coherence|
|US20100318761||Jun 11, 2009||Dec 16, 2010||Freescale Semiconductor, Inc.||Processor and method for dynamic and selective alteration of address translation|
|US20110016290||Jul 14, 2009||Jan 20, 2011||Arie Chobotaro||Method and Apparatus for Supporting Address Translation in a Multiprocessor Virtual Machine Environment|
|US20110078388||Sep 29, 2009||Mar 31, 2011||International Business Machines Corporation||Facilitating memory accesses|
|US20110153909 *||Dec 22, 2009||Jun 23, 2011||Yao Zu Dong||Efficient Nested Virtualization|
|US20110197004||Dec 6, 2010||Aug 11, 2011||Serebrin Benjamin C||Processor Configured to Virtualize Guest Local Interrupt Controller|
|US20110239268||Mar 23, 2010||Sep 29, 2011||Richard Sharp||Network policy implementation for a multi-virtual machine appliance|
|US20110283040||May 13, 2010||Nov 17, 2011||International Business Machines Corporation||Multiple Page Size Segment Encoding|
|US20110320756||Jun 23, 2010||Dec 29, 2011||International Business Machines Corporation||Runtime determination of translation formats for adapter functions|
|US20110320758||Jun 23, 2010||Dec 29, 2011||International Business Machines Corporation||Translation of input/output addresses to memory addresses|
|US20110320759||Jun 23, 2010||Dec 29, 2011||International Business Machines Corporation||Multiple address spaces per adapter|
|US20110321158||Jun 23, 2010||Dec 29, 2011||International Business Machines Corporation||Guest access to address spaces of adapter|
|US20120011341||Sep 16, 2011||Jan 12, 2012||International Business Machines Corporation||Load Page Table Entry Address Instruction Execution Based on an Address Translation Format Control Field|
|US20120023300||Jul 26, 2010||Jan 26, 2012||International Business Machines Corporation||Memory page management in a tiered memory system|
|US20120079479||Sep 27, 2010||Mar 29, 2012||James Robert Howard Hakewill||Microprocessor system for virtual machine execution|
|US20120110236||Oct 29, 2010||May 3, 2012||Vmware, Inc.||System and Method to Prioritize Large Memory Page Allocation in Virtualized Systems|
|US20120137106||Dec 23, 2011||May 31, 2012||International Business Machines Corporation||Dynamic Address Translation With Translation Table Entry Format Control for Identifying Format of the Translation Table Entry|
|US20120137288||Nov 29, 2010||May 31, 2012||International Business Machines Corporation||Virtualization of vendor specific configuration and management of self-virtualizing input/output device|
|US20120159039||Dec 2, 2011||Jun 21, 2012||Andy Kegel||Generalized Control Registers|
|US20120180047||Jan 11, 2011||Jul 12, 2012||International Business Machines Corporation||PRESERVING TRAFFIC CLASS PRIORITY QoS WITH SELF-VIRTUALIZING INPUT/OUTPUT DEVICE|
|US20120185854||Mar 28, 2012||Jul 19, 2012||Oracle International Corporation||System and method to improve memory usage in virtual machines running as hypervisor guests|
|US20120191940||Jan 25, 2011||Jul 26, 2012||International Business Machines Corporation||Allocating addressable memory regions to an adapter|
|US20120209894||Apr 21, 2012||Aug 16, 2012||International Business Machines Corporation||Partition file system for virtual machine memory management|
|US20130024598||Jul 18, 2011||Jan 24, 2013||Vmware, Inc.||Increasing granularity of dirty bit information in hardware assisted memory management systems|
|US20140047251||Aug 7, 2012||Feb 13, 2014||Qualcomm Incorporated||Methods, systems and devices for hybrid memory management|
|US20140101359||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||Asymmetric co-existent address translation structure formats|
|US20140101360||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||Adjunct component to provide full virtualization using paravirtualized hypervisors|
|US20140101361||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||System supporting multiple partitions with differing translation formats|
|US20140101362||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||Supporting multiple types of guests by a hypervisor|
|US20140101363||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||Selectable address translation mechanisms within a partition|
|US20140101364||Mar 7, 2013||Apr 10, 2014||International Business Machines Corporation||Selectable address translation mechanisms within a partition|
|US20140101402||Mar 4, 2013||Apr 10, 2014||International Business Machines Corporation||System supporting multiple partitions with differing translation formats|
|US20140101404||Oct 8, 2012||Apr 10, 2014||International Business Machines Corporation||Selectable address translation mechanisms|
|US20140101406||Mar 7, 2013||Apr 10, 2014||International Business Machines Corporation||Adjunct component to provide full virtualization using paravirtualized hypervisors|
|US20140101407||Mar 7, 2013||Apr 10, 2014||International Business Machines Corporation||Selectable address translation mechanisms|
|US20140101408||Mar 7, 2013||Apr 10, 2014||International Business Machines Corporation||Asymmetric co-existent address translation structure formats|
|US20140108701||Dec 16, 2013||Apr 17, 2014||Memory Technologies Llc||Memory protection unit in a virtual processing environment|
|EP0690386A1||Mar 31, 1995||Jan 3, 1996||International Business Machines Corporation||Address translator and method of operation|
|EP1959348A2||Dec 19, 2007||Aug 20, 2008||Intel Corporation||Address translation in partitioned systems|
|WO2012129729A1||Mar 31, 2011||Oct 4, 2012||Intel Corporation||Memory mirroring and redundancy generation for high availability|
|1||"z/Architecture-Principles of Operation," Publication No. SA22-7832-08, 9th Edition, Aug. 2010.|
|2||Barr, Thomas et al., "Translation Caching. Skip, Don't Walk (the Page Table)," ISCA '10, Jun. 2010, pp. 48-59.|
|3||Ben-Yehuda, Muli, et al., "The Turtles Project: Design and Implementation of Nested Virtualization," IBM Research Report H-0282 (H1001-004), Jan. 9, 2010, 14 pages.|
|4||Bybell, Anthony et al., "Asymmetric Co-Existent Address Translation Structure Formats," U.S. Appl. No. 13/646,770, filed Oct. 8, 2012.|
|5||Bybell, Anthony et al., "Selectable Address Translation Mechanisms," U.S. Appl. No. 13/646,771, filed Oct. 8, 2012.|
|6||Final Office Action for U.S. Appl. No. 13/646,770 dated Nov. 19, 2014, 22 pages.|
|7||Final Office Action for U.S. Appl. No. 13/646,779 dated May 6, 2015, pp. 1-21.|
|8||Final Office Action for U.S. Appl. No. 13/646,788 dated May 5, 2015, pp. 1-16.|
|9||Final Office Action for U.S. Appl. No. 13/784,082 dated May 5, 2015, pp. 1-17.|
|10||Final Office Action for U.S. Appl. No. 13/788,895 dated May 6, 2015, pp. 1-13.|
|11||Final Office Action for U.S. Appl. No. 13/789,148 dated Nov. 19, 2014, 20 pages.|
|12||Final Office Action in U.S. Appl. No. 13/646,771, dated Sep. 22, 2015, pp. 1-41.|
|13||Final Office Action in U.S. Appl. No. 13/646,773, dated Oct. 7, 2015, pp. 1-17.|
|14||Final Office Action in U.S. Appl. No. 13/789,101, dated Oct. 7, 2015, pp. 1-13.|
|15||Gschwind, Michael K. "System Supporting Multiple Partitions With Differing Translation Formats," U.S. Appl. No. 13/646,779, filed Oct. 8, 2012.|
|16||Gschwind, Michael K., "Adjunct Component to Provide Full Virtualization Using Paravirtualized Hypervisors," U.S. Appl. No. 13/646,773, filed Oct. 8, 2012.|
|17||Gschwind, Michael K., "Selectable Address Translation Mechanisms within a Partition," U.S. Appl. No. 13/646,788, filed Oct. 8, 2012.|
|18||Gschwind, Michael K., "Supporting Multiple Types of Guests by a Hypervisor," U.S. Appl. No. 13/646,782, filed Oct. 8, 2012.|
|19||Hoang, Giang et al., "A Case for Alternative Nesting Paging Models for Virtualized Systems," IEEE Computer Architecture Letters, Jan.-Jun. 2010, vol. 9, No. 1, pp. 17-20.|
|20||Intel Itanium Architecture Software Developer's Manual vol. 2: System Architecture, Document No. 245318-005, Jan. 2006.|
|21||International Preliminary Report on Patentablility and Written Opinion in related Application No. PCT/US2013/063672, dated Apr. 8, 2015, pp. 1-5.|
|22||International Search Report and Written Opinion for PCT/US2013/063675 dated Jan. 22, 2014, pp. 1-11.|
|23||International Search Report and Written Opinion for PCT/US2013/63651 dated Apr. 21, 2014, pp. 1-9.|
|24||International Search Report in related Application No. PCT/US2013/063672, dated Jan. 28, 2014, pp. 1-3.|
|25||Nakajima et al., "Hybrid Virtualization: Enhanced Virtualization for Linux", Proceedings of the Linux Symposium, 2007, vol. 2, pp. 87-96.|
|26||Notice of Allowance in U.S. Appl. No. 13/646,773, dated Jan. 15, 2016, pp. 1-14.|
|27||Notice of Allowance in U.S. Appl. No. 13/646,779, dated Jan. 15, 2016, pp. 1-9.|
|28||Notice of Allowance in U.S. Appl. No. 13/646,779, dated Sep. 30, 2015, pp. 1-7.|
|29||Notice of Allowance in U.S. Appl. No. 13/646,782, dated Jan. 19, 2016, pp. 1-14.|
|30||Notice of Allowance in U.S. Appl. No. 13/646,782, dated Oct. 23, 2015, pp. 1-10.|
|31||Notice of Allowance in U.S. Appl. No. 13/784,082, dated Dec. 7, 2015, pp. 1-14.|
|32||Notice of Allowance in U.S. Appl. No. 13/784,082, dated Sep. 24, 2015, pp. 1-7.|
|33||Office Action for U.S. Appl. No. 13/646,770 dated Jun. 18, 2014, 18 pages.|
|34||Office Action for U.S. Appl. No. 13/646,771 dated Apr. 9, 2015, pp. 1-44.|
|35||Office Action for U.S. Appl. No. 13/646,771 dated Dec. 15, 2014, 30 pages.|
|36||Office Action for U.S. Appl. No. 13/646,771 dated Jul. 10, 2014, 22 pages.|
|37||Office Action for U.S. Appl. No. 13/646,773 dated Mar. 25, 2015, pp. 1-23.|
|38||Office Action for U.S. Appl. No. 13/646,779 dated Oct. 8, 2014, 26 pages.|
|39||Office Action for U.S. Appl. No. 13/646,782 dated Apr. 9, 2015, pp. 1-25.|
|40||Office Action for U.S. Appl. No. 13/646,788 dated Oct. 8, 2014, 23 pages.|
|41||Office Action for U.S. Appl. No. 13/784,082 dated Oct. 8, 2014, 20 pages.|
|42||Office Action for U.S. Appl. No. 13/788,895 dated Oct. 8, 2014, 17 pages.|
|43||Office Action for U.S. Appl. No. 13/789,101 dated Mar. 26, 2015, pp. 1-17.|
|44||Office Action for U.S. Appl. No. 13/789,124 dated Aug. 12, 2014, 17 pages.|
|45||Office Action for U.S. Appl. No. 13/789,124 dated Dec. 2, 2014, 17 pages.|
|46||Office Action for U.S. Appl. No. 13/789,148 dated Jun. 19, 2014, 16 pages.|
|47||Office Action in U.S. Appl. No. 13/646,788, dated Oct. 8, 2015, pp. 1-17.|
|48||Office Action in U.S. Appl. No. 13/788,895, dated Oct. 6, 2015, pp. 1-13.|
|49||Office Action in U.S. Appl. No. 13/789,101, dated Feb. 1, 2016, pp. 1-12.|
|50||Peng, C. Ray et al., "The Power PC Architecture: 64-Bit Power with 32-Bit Compatibility," pp. 300-307, 1995 (no further date information available).|
|51||Power ISA™ Version 2.06 Revision B specification, Jul. 23, 2010.|
|52||Wang, et al., Dynamic Memory Paravirtualization Transparent to Guest OS, Science in China, Jan. 2010, 12 pages.|
|International Classification||G06F12/10, G06F12/08|
|Cooperative Classification||G06F12/10, G06F2212/151, G06F12/08, G06F12/1009|