HK1066071A - Reclaiming existing fields in address translation data structures to extend control over memory accesses - Google Patents

Description

Reclaiming existing fields of address translation data structures to extend memory access control

Technical Field

The present invention relates to memory access control, and more particularly, to reclaiming existing fields in an (recaim) address translation data structure to extend control over memory accesses.

Background

The computer processor accesses the system memory to retrieve or store data in the system memory. In particular, the processor uses the physical address of the data in memory to identify and access the data. However, the physical addresses at which data is stored in memory are not the addresses used by the processor to index the data during internal manipulation. Instead, the processor assigns a virtual address to the data being processed, according to program instructions. Thus, memory accesses often require translation of virtual addresses to physical addresses.

Conventional address translation mechanisms are typically based on Translation Lookaside Buffers (TLBs), which are structures within the processor that serve as caches for previously processed address translations. For example, in 32-bit Intel^In an architectural processor Instruction Set Architecture (ISA) (hereinafter IA-32 ISA), address translation is controlled by a TLB and a page-table hierarchy. The page table hierarchy referenced by the processor's control register CR3 is a translation data structure used to translate virtual memory addresses (also referred to as linear memory addresses in the IA-32ISA context) to physical memory addresses when paging is enabled. The page table hierarchy includes a Page Directory (PD), a set of Page Tables (PTs), and a plurality of Page Frames (PFs). Generally, the translation of a virtual memory address to a physical memory address begins by looking up the TLB using the upper 20 bits (for a 4KB page) or the upper 10 bits (for a 4MB page) of the virtual address. If a match is found, the upper bits of the physical page frame contained in the TLB are concatenated with the lower bits of the virtual address to form the physical address. If no match is found, the processor looks up the page table hierarchy to determine a virtual to physical address translation, and then caches this translation in the TLB.

Each entry in the PD and PT typically includes various fields that control the accessibility of the memory pages. Examples of these fields include a current (P) flag indicating whether the page referenced by the entry is valid, a user/supervisor (U/S) flag that controls access to the page referenced by the entry based on privilege level, and a read/write (R/W) flag that controls access based on access type (i.e., read or write).

Disclosure of Invention

A method and apparatus for reclaiming existing bits in an address translation data structure to extend control of memory accesses in a virtual machine environment is described.

With the method and apparatus provided by the present invention, existing fields in the address translation data structure can be interpreted and used in a variety of ways without loss of generality, thereby extending control over memory access in a virtual machine environment.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 illustrates one embodiment of a virtual machine environment in which the present invention may operate;

FIG. 2is a block diagram of one embodiment of a virtual TLB system;

FIG. 3 is a flow diagram of one embodiment of a process for reclaiming existing fields in an address translation data structure to extend control of memory accesses in a virtual machine environment;

FIG. 4 is a block diagram of one embodiment of a virtual TLB system that supports address translation in the IA-32 ISA; and is

FIG. 5 illustrates the format of a Page Directory Entry (PDE) and Page Table Entry (PTE) in a conventional page table hierarchy for the IA-32 ISA.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details.

Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer system's registers or memory. These algorithmic descriptions and representations are the means by which those skilled in the data processing arts can most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be understood, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or the like, may refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

In the following detailed description of the embodiments, reference is made to the accompanying drawings that show, by way of illustration, various embodiments in which the invention may be practiced. In the drawings, like numerals describe substantially similar components throughout the several views. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, logical, or electrical changes may be made without departing from the scope of the present invention. Moreover, it is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described in one embodiment may be included within other embodiments. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, including the full scope of equivalents to which such claims are entitled.

FIG. 1 illustrates one embodiment of a virtual machine environment 100 in which the present invention may operate. In this embodiment, bare platform hardware 116 comprises a computing platform capable of, for example, executing a standard Operating System (OS) or a Virtual Machine Monitor (VMM), such as VMM 112. The VMM 112, although typically implemented in software, may also emulate and output a bare machine interface to higher level software. Such higher level software may include a standard or real-time OS, may be a highly streamlined operating environment with limited operating system functionality, or may not include traditional OS facilities. Alternatively, the VMM 112 may be running in or on another VMM, for example. VMMs and their features and functions are well known to those skilled in the art and may be implemented in, for example, software, firmware, or by a combination of various techniques.

The platform hardware 116 includes a processor 118 and a memory 120. The processor 118 may be any type of processor capable of executing software, such as a microprocessor, digital signal processor, microcontroller, or the like. Memory 120 may be a hard disk, a floppy disk, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, any combination of the above devices, or any other type of machine medium readable by processor 118. Memory 120 may store instructions for performing the execution of method embodiments of the present invention.

The platform hardware 116 may be a Personal Computer (PC), mainframe, handheld device, portable computer, set-top box, or any other computing device.

The VMM 112 provides abstraction of one or more Virtual Machines (VMs) to other software (i.e., "guest" software), which may provide the same or different abstractions to the various guests. FIG. 1 shows two virtual machines, 102 and 114. The guest software running on each VM may include a guest OS, such as guest OS 104 or 106, and various guest software applications 108 and 110. The guest OSs 104 and 106 expect to access physical resources (e.g., processor registers, memory, and I/O devices) in the VMs 102 and 114 and perform other functions, with the guest OSs 104 or 106 running above the VMs 102 and 114. For example, during address translation operations, the guest OS expects to allocate physical memory, provide protection from and between software applications (e.g., applications 108 or 110), use various paging techniques, and so forth. However, in a virtual machine environment, the processor 118 and the VMM 112 need to have ultimate control over the address translation operations to support proper operation of the VMs 102 and 114, and to provide protection from the VMs 102 and 114 and protection between the VMs 102 and 114. In one embodiment, an address translation system, referred to herein as a virtual Translation Lookaside Buffer (TLB), is provided that tolerates and supports attempts by the OS to control address translation while allowing the processor 118 and VMM 112 to retain ultimate control over address translation operations. Some embodiments of the virtual TLB system are described in more detail below.

Resources accessible by guest software may be classified as "privileged" or "unprivileged". For privileged resources, the VMM 112 facilitates the functionality required by guest software while retaining ultimate control over these privileged resources. Non-privileged resources need not be controlled by the VMM 112 and may be accessed by guest software.

In one embodiment, if guest software attempts to access a privileged resource, control is transferred to the VMM 112. In response, the VMM 112 either allows guest software to access the privileged resource or emulates functionality required by the guest software and then transfers control back to the guest software. In one embodiment, the transfer of control between the VM 102 or 114 and the VMM 112 is accomplished by executing a dedicated instruction. Control of guest software by this mechanism is referred to herein as VMX operation, and the transfer of control from guest software to the VMM is referred to herein as a VM exit (VMexit). In another embodiment, the transfer of control between the VM 102 or 114 and the VMM 112 is initiated by a non-instructional event, such as an asynchronous hardware interrupt or a page fault.

In one embodiment, when a VM exit occurs, portions of the processor state used by guest software are saved and portions of the processor state needed by the VMM 112 are loaded. Depending on the processor Instruction Set Architecture (ISA), such saving and loading of processor state may have the effect of changing the active address space. For example, in 32-bit Intel^In the architecture's ISA (hereinafter the IA-32 ISA), the active address space can be determined by values in control registers that can be saved and restored upon a VM exit.

In one embodiment, when a transition occurs from the VMM 112 to guest software, the saved processor state at the VM exit (which may have been modified by the VMM 112) may be restored and control returned to the guest OS 104 or 106, or guest application 108 or 110.

It should be noted that any other mechanism known in the art may be used to transfer control between guest software and the VMM 112 without loss of generality.

FIG. 2is a block diagram of one embodiment of a virtual TLB system 200. The virtual TLB system 200 includes a guest address translation data structure 208 and a virtual TLB 202. The guest address translation data structure 208 represents how the guest OS will translate virtual memory addresses to physical memory addresses. An example of such an address translation data structure is the page table hierarchy of the IA-32 ISA. However, various other address translation data structures may also be used with the present invention without loss of generality. The guest address translation data structure 208 is managed by the guest OS, which may access and modify any entries in the guest address translation data structure 208. Some entries of the guest address translation data structure 208 include a number of fields that are specifically designated by software for operational use. As shown in FIG. 2, one example entry 212 in the guest address translation data structure 208 includes a software available field 216 that includes one or more bits that are specified by guest software for operational use (i.e., guest software may set values in this bit field for any desired purpose). It should be noted that the entries, including the field of software available bits, and the number of bits in the software available field contained in each entry may vary depending on the ISA. For example, in the page table hierarchy of the IA-32ISA, each entry in the page directory and page table includes 3 "AVAIL" (available) bits that are architecturally guaranteed to be available for use by a system programmer. As a result, these bits cannot be used or interpreted by hardware (e.g., to cause any particular action or protection).

The virtual TLB 202 includes a physical TLB 204 managed by the processor, and an active address translation data structure 206 managed by the VMM. The active address translation data structure 206 and the guest address translation data structure 208 obtain their formats from architecturally-defined formats (e.g., IA-32 formats). The physical TLB 204 is loaded by the processor with address translations obtained from the active address translation data structures 206.

In one embodiment, the VMM creates an active address translation data structure 206 based on the guest address translation data structure 208 and then periodically modifies one or more entries in the active address translation data structure 206 to remain consistent with corresponding entries in the guest address translation data structure 208. In one embodiment, the VMM modifies the active address translation data structure 206 upon receiving control of an event initiated by guest software and determining that the likely cause of the event is an inconsistency between the contents of the active address translation data structure 206 and the contents of the guest address translation data structure. For example, this event may be an attempt by the guest OS to manipulate the TLB 204 (e.g., a request by guest software to invalidate an address translation cached in the TLB 204), or a page fault generated by the processor in response to an operation performed by the guest software (e.g., a page fault generated in response to a request by guest software to write a memory region that is marked as read-only in the active address translation data structure and writable in the guest address translation data structure).

In modifying the contents of the active address translation data structure 206, the VMM avoids copying the software available bit field 216 from the guest address translation data structure 208 to the active address translation data structure 206 because the bit field 216 is used internally by guest software and has no meaning to the VMM. Accordingly, because bit field 216 contained in an entry of active address translation data structure 206 is not overwritten by data from guest address translation data structure 208, the VMM is able to reclaim this bit field for its own use. In one embodiment, the VMM uses a bit field in an entry (e.g., entry 210) of the active address translation data structure 206 to store an access control indicator 214 that controls the accessibility of the memory region referenced by the entry 210. Examples of access control indicators and their use in a virtual machine environment are described in more detail below.

FIG. 3 is a flow diagram of one embodiment of a process 300 for reclaiming existing fields in an address translation data structure in a virtual machine environment to extend control of memory accesses. The process may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both.

Referring to FIG. 3, process 300 begins with processing logic setting an access control indicator in one or more entries of an active address translation data structure (processing block 302). Processing logic sets an access control indicator when creating an entry in the active address translation data structure. In one embodiment, the entry is created when the processing logic creates the entire active address translation data structure based on a guest address translation data structure that is used by the guest OS for address translation operations. Alternatively, processing logic creates an entry in the active address translation data structure after a new entry is added to the guest address translation data structure. In one embodiment, once the access control indicators are set, processing logic may modify them as needed at any time.

Then, at processing block 304, processing logic detects a transfer of control to the VMM, the transfer resulting from an event initiated by guest software (e.g., an attempt by the guest software to manipulate the TLB, or a page fault generated in response to an operation performed by the guest software), and evaluates the event. Based on this evaluation, processing logic determines whether the event requires modification of the active address translation data structure (decision block 306). For example, this determination may depend on whether the page fault occurred because the contents of the active address translation data structure are inconsistent with the contents of the guest address translation data structure, or for other reasons.

If the determination made at decision block 306 is negative, the process 300 ends. Alternatively, if the determination made at decision block 306 is positive, then processing logic refrains from overwriting the access control indicator when modifying other contents of the active address translation data structure to match contents of the guest address translation data structure (processing block 308). As a result, during address translation operations, access control indicators are maintained in the active address translation data structure for use by the processor.

Example functions of the access control indicator will be described below with reference to specific features of the IA-32 ISA. It should be noted, however, that the access control indicator may be used for a variety of purposes other than the functions described below, and with a variety of processors other than the IA-32 processor.

FIG. 4 is a block diagram of one embodiment of a virtual TLB system 400 that supports address translation in the IA-32 ISA. System 400 includes a virtual TLB 404 and a physical TLB 408, where virtual TLB 404 contains active address translation data structures represented by an active page table hierarchy 406. The system 400 also includes a guest address translation data structure represented by a guest page table hierarchy 402. The active page table hierarchy 406 and the guest page table hierarchy 402 obtain their formats from a format defined in the IA-32 architecture. The entries of the guest page table hierarchy 402 have a conventional format according to the IA-32 ISA.

FIG. 5 illustrates the format 502 of a Page Directory Entry (PDE) and the format 504 of a Page Table Entry (PTE) in a conventional page table hierarchy for the IA-32 ISA. Each PDE and PTE includes a set of bits that control the accessibility of memory pages. For example, the bits include a current (P) flag 516 or 510 indicating whether the page referenced by the entry is valid, a user/supervisor (U/S) flag 520 or 514 that controls access to the page referenced by the entry based on privilege level, and a read/write (R/W) flag 518 or 512 that controls access based on access type (i.e., read or write). Each PDE and PTE also includes three "AVAIL" bits 506 and 508. The AVAIL bits 506 and 508 are architecturally guaranteed to be available for use by a system programmer. That is, software may place multiple values in the AVAIL bit for any desired purpose (e.g., to record information related to a given page). As a result, the hardware cannot interpret or use the bits for any other purpose (e.g., protection at the new page level). Thus, if these fields are not used by the software, they are "wasted".

Returning to FIG. 4, the AVAIL bit in each of the PDE and PTE is set by the VMM and is not overwritten by data from the guest page table hierarchy 402 when modifying the contents of the active page table hierarchy 406. In one embodiment, when the active page table hierarchy 406 is created or a new entry is added to the active page table hierarchy 406, an AVAIL bit is created:

in one embodiment, all entries in the active page table hierarchy 406 are initially marked invalid (using the P flag 516 in each PDE and the P flag 510 in each PTE) to simulate the initialization state of the TLB when it has no entries. Subsequently, when guest software provides a virtual address to the processor, the processor only finds invalid entries in the active page table hierarchy 406 and generates a page fault. A page fault transfers control from the guest OS to the VMM. The VMM then copies the corresponding entry from the guest page table hierarchy 402 to the active page table hierarchy 406, refilling the active page table hierarchy 406. During refill, the AVAIL bit in the guest page table hierarchy 402 is ignored (i.e., the AVAIL bit is not copied to the active page table hierarchy 406).

The guest software is allowed to freely modify the guest page table hierarchy 402, including changing virtual-to-physical mappings, permissions, and the like. Accordingly, the active page table hierarchy 406 may not always remain consistent with the guest page table hierarchy 402. That is, the active page table hierarchy 406 may be out of date, for example, it may allow too many accesses to its entries, provide a wrong virtual-to-physical address mapping, and so on. When a problem arises because of an inconsistency between the hierarchies 402 and 406, the guest OS issues one of the instructions 416 to the physical TLB 408. These instructions result in a transfer of control from the guest OS to the VMM. The VMM will then determine the cause of the instruction and modify the contents of the active page table hierarchy 406 (e.g., remove from the active page table hierarchy 406 the entry referenced in the issued instruction by guest software). During modification, the AVAIL bit in the guest page table hierarchy 402 is not copied to the active page table hierarchy 406.

Because the AVAIL bits in active page table hierarchy 406 are unchanged, they may be reclaimed by the VMM. Once reclaimed, the AVAIL bit may be used in various ways. For example, one of the AVAIL bits may be a guest/host ("G/H") access bit that controls access to a page by guest software. That is, if the "G/H" bit in the active PTE is cleared, then the processor may allow access to pages referenced by that PTE only if the VMM ("host") is running. If the "G/H" bit is set, the processor may allow access to the page while the VMM or guest software is running.

The "G/H" bit may be used to resolve address space conflicts between the VMM and the guest OS. In the current IA-32ISA, address space conflicts typically arise because an existing processor (e.g., an IA-32 microprocessor) does not allow the VMM to receive control of events initiated by the guest OS (e.g., an attempt by the guest OS to access privileged hardware resources) unless a portion of the VMM code and/or data structures are located in the same virtual address space as the guest OS. However, because the guest OS expects the VMM code and/or data structures not to reside in the same address space, it may attempt to access a region of this address space occupied by the VMM, resulting in an address space conflict between the guest OS and the VMM. This conflict may result in an abnormal termination of operations performed by the VMM or guest OS.

The "G/H" bit prevents address space conflicts from occurring between the guest OS and the VMM. In particular, using the "G/H" bits, the VMM finds a location in the guest OS's virtual address space to map its code and data structures and ensures that the corresponding "G/H" bits are cleared to protect VMM code and data structures from being accessed by the guest OS. When an attempt by the guest OS to access the address space occupied by the VMM is detected, VMM code and data structures are remapped to an unused region of the guest OS's virtual address space, and the guest OS can access the desired address space.

The "G/H" bit may also be used to simplify address switching in some ISAs, which do not require portions of VMM code and/or data structures to reside in the guest OS address space to receive control over events initiated by the guest OS. For example, when VMX operation controls guest software, a VM exit may cause a full address space switch before transferring control to the VMM, thus eliminating the need to have a portion of VMM code and/or data structures reside in the guest OS address space. However, performing a full address switch for each VM exit is costly. Accordingly, as described above, the execution of this switch may be optimized by running a portion of the VMM code and/or data structures in the guest OS address space and using the "G/H" bit to protect the VMM code and data structures from being accessed by the guest OS.

In another embodiment, two of the AVAIL bits may be interpreted by the processor as an execution privilege "X" and a read privilege "R" bit, while the existing "R/W" bit may be reinterpreted as a bit write privilege "W" bit. As a result, different types of page accesses can be controlled independently. For example, the processor may disable execution of any instructions from the page when the X bit is cleared, and enable execution of instructions from the page when the X bit is set. Similarly, the "R" bit may control read access of data from the page, while the "W" bit may control write access to the page.

It may be beneficial to use a combination of independently settable "R", "W", and "X" bits with a dynamic binary translator that modifies the instruction binary for various purposes, such as instruction set emulation, address tracking, and so forth. For example, the combination of "R", "W", and "X" bits may simplify the handling of self-modifying code (SMC) and self-checking code (SEC) by a dynamic binary translator on an IA-32 processor. That is, the dynamic binary translator may set the combination of the "R", "W", and "X" bits on a page holding translated instructions to 001, allowing the processor to execute the code while detecting an attempt by the code to modify or read an instruction byte of the code (which may be different from the original instruction of the code because of the translation or patching action of the binary translator). For a page that holds both instructions and data, the binary translator may set the "R" and "W" bits appropriately, but hold the "X" bit set to 0, so that code may directly access the data on the page, but may not be able to execute the instructions on the page. An attempt to execute an instruction on the page may result in a transition to the VMM, which may then emulate the instruction that caused the fault.

The combination of "R", "W", and "X" bits may also allow for secure execution of code containing embedded secret keys or algorithms. That is, the VMM may map code containing an embedded secret key or algorithm onto a page referenced by an entry whose combination of "R", "W", and "X" bits is set to 001. As a result, the secure code may be invoked and executed while the embedded secret key or algorithm may be protected from being read or modified by other code running in the same address space.

The combination of the "R", "W", and "X" bits may also be used to assist in debugging operations. Specifically, the current page holding the data may be mapped by the VMM resident debugger, with the combination of the "R", "W", and "X" bits set to 010 or 110. With these protections, the debugger can immediately determine when the problematic code has inadvertently started executing data as if it were an instruction.

In another embodiment, one of the AVAIL bits may be combined with an existing "U/S" bit to indicate whether a given page is accessible by code running at a particular privilege level. The VMM may then use two bits to specify the highest privilege level that a given page may be accessed. For example, a value of 00 may indicate that only code running at privilege level 0 may access a given page, a value of 01 may indicate that code running at privilege level 0 or 1 may access the page, a value of 10 may indicate that code running at privilege level 0, 1 or 2 may access the page, and a value of 11 may indicate that code running at any privilege level may access the page. Using two bits to control the privilege level of the access code provides greater flexibility, for example, so that the device driver can be run at privilege level 1 while the rest of the OS kernel is run at privilege level 0, while the ring 0 kernel is guarded with page level protection to prevent operation of a destructive or failed ring 1 device driver. These page level protections are not possible using the existing "U/S" bits, which cluster the 0, 1, 2 rings together as the supervisor (S) privilege level, while ring 3 is designated as the user (U) privilege level.

The functionality described above with reference to the "G/H" bits, the "R", "W", and "X" bits, which may be set independently, and the combination of the "U/S" bits with one AVAIL bit may be implemented simultaneously by redefining the 3 existing "P", "R/W", and "U/S" bits and combining them with the 3 AVAIL bits recovered. Specifically, 3 of the resulting 6 bits may be used as independently settable "R", "W", and "X" bits, two of the remaining three bits may be used to represent the highest ring to which the code has access, and the last bit may be used as the "G/H" bit. For this interpretation of these bits, if the combination of the "R", "W", and "X" bits has a setting of 000, then the page may be considered "not current".

It should be noted that in addition to the above, existing fields in the active address translation data structure may be interpreted and used in a variety of ways without loss of generality.

Thus, a method and apparatus for reclaiming existing fields in an address translation data structure has been described. It is to be understood that the above description is intended to be illustrative, and not restrictive. Numerous other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (30)

1. A method, comprising:

determining that the contents of the active address translation data structure need to be modified; and

avoiding rewriting a portion of an entry in the active address translation data structure while modifying the entry to remain consistent with a corresponding entry in a guest address translation data structure, wherein the portion of an entry in the active address translation data structure includes at least one access control indicator.

2. The method of claim 1, wherein a processor uses the contents of the active address translation data structure to cache address translations in a translation lookaside buffer.

3. The method of claim 1, wherein the guest address translation data structure is used by guest software for address translation operations.

4. The method of claim 1, wherein the active address translation data structure is managed by a virtual machine monitor.

5. The method of claim 1, further comprising:

at least one access control indicator is set to a holding value.

6. The method of claim 1, wherein the active address translation data structure is an active page table hierarchy.

7. The method of claim 6, wherein:

the entry in the active address translation data structure is any one of a page table entry and a page directory entry; and is

The at least one access control indicator is at least one software available bit in the entry.

8. The method of claim 6, wherein the at least one access control indicator comprises a guest host indicator for controlling access by guest software to a corresponding page in the page table hierarchy.

9. The method of claim 6, wherein the at least one access control indicator comprises: an execution privilege indicator for controlling execution of instructions from a corresponding page in the page table hierarchy; and a read privilege indicator for controlling read access to the corresponding page in the page table hierarchy.

10. The method of claim 9, wherein a read/write bit is reinterpreted as a write privilege indicator for controlling write access to the corresponding page in the page table hierarchy.

11. The method of claim 6, wherein the at least one access control indicator comprises a privilege level access indicator for controlling access to a corresponding page in the page table hierarchy by code running at a particular privilege level.

12. An apparatus, comprising:

a guest address translation data structure for translating virtual memory addresses to physical memory addresses by guest software;

an active address translation data structure to obtain partial content from the guest address translation data structure, the partial content excluding at least one access control indicator within each of a plurality of entries in the guest address translation data structure; and

a translation lookaside buffer to store address translations obtained by the processor from the active address translation data structure.

13. The apparatus of claim 12, wherein the active address translation data structure is managed by a virtual machine monitor.

14. The apparatus of claim 13, wherein the virtual machine monitor sets at least one access control indicator in an entry of the active address translation data structure to a particular value.

15. The apparatus of claim 12, wherein the active address translation data structure is an active page table hierarchy.

16. The apparatus of claim 15, wherein:

the entry in the active address translation data structure is any one of a page table entry and a page directory entry; and is

The at least one access control indicator is at least one software available bit in the entry.

17. The apparatus of claim 15, wherein the at least one access control indicator in an entry of the active address translation data structure comprises a guest host indicator for controlling access by guest software to a corresponding page in the page table hierarchy.

18. The apparatus of claim 15, wherein the at least one access control indicator in an entry of the active address translation data structure comprises: an execution privilege indicator for controlling execution of instructions from a corresponding page in the page table hierarchy; and a read privilege indicator for controlling read access to the corresponding page in the page table hierarchy.

19. The apparatus of claim 18, wherein a read/write bit is reinterpreted as a write privilege indicator for controlling write access to the corresponding page in the page table hierarchy.

20. The apparatus of claim 15, wherein the at least one access control indicator in an entry of the active address translation data structure comprises a privilege level access indicator for controlling access to a corresponding page in the page table hierarchy by code running at a particular privilege level.

21. A machine-readable medium containing instructions that, when executed by a processing system, cause the processing system to perform a method comprising:

determining that the contents of the active address translation data structure need to be modified; and

avoiding rewriting a portion of an entry in the active address translation data structure while modifying the entry to remain consistent with a corresponding entry in a guest address translation data structure, wherein the portion of an entry in the active address translation data structure includes at least one access control indicator.

22. The machine-readable medium of claim 20, wherein the processor uses the contents of the active address translation data structure to cache address translations in a translation lookaside buffer.

23. The machine-readable medium of claim 20, wherein the guest address translation data structure is used by guest software for address translation operations.

24. The machine-readable medium of claim 20, wherein the active address translation data structure is managed by a virtual machine monitor.

25. The machine-readable medium of claim 20 wherein the active address translation data structure is an active page table hierarchy.

26. The machine-readable medium of claim 25, wherein:

the entry in the active address translation data structure is any one of a page table entry and a page directory entry; and is

The at least one access control indicator is at least one software available bit in the entry.

27. A system, comprising:

a processing system; and

a memory coupled to the processor system to store instructions that, when executed by the processing system, cause the processing system to determine that a modification to a content of an active address translation data structure is required and avoid rewriting a portion of an entry in the active address translation data structure when the entry is modified to remain consistent with a corresponding entry in a guest address translation data structure, wherein the portion of an entry in the active address translation data structure includes at least one access control indicator.

28. The system of claim 27, wherein a processor uses the contents of the active address translation data structure to cache address translations in a translation lookaside buffer.

29. The system of claim 27, wherein the guest address translation data structure is used by guest software for address translation operations.

30. The system of claim 29, wherein the active address translation data structure is managed by a virtual machine monitor.