An approach is provided in a hypervised computer system where a page table request is at an operating system running in the hypervised computer system. The operating system determines whether the page table request requires the hypervisor to process. If the determination reveals that the page table request requires the hypervisor, then the hypervisor is used to handle the request. However, if the determination reveals that the page table request does not require the hypervisor, then an indicator included in a page table entry corresponding to the request is read to determine if the page table entry is controlled by the operating system or the hypervisor. The operating system is able to update the page table entry if the indicator identifies the page table entry as being operating system controlled.
TECHNICAL FIELD
The present invention allows an operating system to manage address data structures rather than a hypervisor.
BACKGROUND
Traditionally in hypervised systems, an operating system manages storage (e.g. maintains the page table, etc.) using service calls to the hypervisor. In environments which set up and tear down huge numbers of short-lived applications (e.g. some types of web serving applications, etc.), the overhead of hypervisor intervention is costly in terms of performance. One approach used by some architectures (e.g. IA32, etc.) has been to create a second level of translation so that the operating system can maintain the first level of page translation, while the hypervisor continues to maintain the actual mapping to real address space. This approach can be costly both in terms of hardware lookaside resources and storage footprint for the tables (and resulting cache pressure). Traditionally, the hypervisor prevents the OS from accessing page tables using conventional storage protection mechanisms that are part of most memory management architectures.
SUMMARY
An approach is provided in a hypervised computer system where a page table request is at an operating system running in the hypervised computer system. The operating system determines whether the page table request requires the hypervisor to process. If the determination reveals that the page table request requires the hypervisor, then the hypervisor is used to handle the request. However, if the determination reveals that the page table request does not require the hypervisor, then an indicator included in a page table entry corresponding to the request is read to determine if the page table entry is controlled by the operating system or the hypervisor. The operating system is able to update the page table entry if the indicator identifies the page table entry as being operating system controlled, otherwise the update is handled by the hypervisor.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings, wherein:
FIG. 1 is a block diagram of a data processing system in which the methods described herein can be implemented;
FIG. 2 is a network diagram of various types of data processing systems connected via a computer network;
FIG. 3 is a block diagram depicting the hypervisor and operating systems interaction with CPU components in order to manipulate memory management storage;
FIG. 4 is a first flowchart depicting steps taken by an operating system to handle an incoming page table request; and
FIG. 5 is a second flowchart depicting actions taken by the operating system to update the page table entry.
DETAILED DESCRIPTION
The following detailed description will generally follow the summary of the invention, as set forth above, further explaining and expanding the definitions of the various aspects and embodiments of the invention as necessary. To this end, this detailed description first sets forth a computing environment in FIG. 1 that is suitable to implement the software and/or hardware techniques associated with the invention.
FIG. 1 illustrates information handling system 100, which is a simplified example of a computer system capable of performing the computing operations described herein. Information handling system 100 includes one or more processors 110coupled to processor interface bus 112. Processor interface bus 112 connects processors 110 to Northbridge 115, which is also known as the Memory Controller Hub (MCH). Northbridge 115 connects to system memory 120 and provides a means for processor(s) 110 to access the system memory. Graphics controller 125 also connects to Northbridge 115. In one embodiment, PCI Express bus 118 connects Northbridge 115 to graphics controller 125. Graphics controller 125 connects to display device 130, such as a computer monitor.
Northbridge 115 and Southbridge 135 connect to each other using bus 119. In one embodiment, the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between Northbridge 115 and Southbridge 135. In another embodiment, a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge. Southbridge 135, also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge. Southbridge 135 typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus. The LPC bus often connects low-bandwidth devices, such as boot ROM 196 and "legacy" I/O devices (using a "super I/O" chip). The "legacy" I/O devices (198) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller. The LPC bus also connects Southbridge 135 to Trusted Platform Module (TPM) 195. Other components often included in Southbridge 135 include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connects Southbridge 135 to nonvolatile storage device 185, such as a hard disk drive, using bus 184.
ExpressCard 155 is a slot that connects hot-pluggable devices to the information handling system. ExpressCard 155supports both PCI Express and USB connectivity as it connects to Southbridge 135 using both the Universal Serial Bus (USB) the PCI Express bus. Southbridge 135 includes USB Controller 140 that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera) 150, infrared (IR) receiver 148, keyboard and trackpad 144, and Bluetooth device 146, which provides for wireless personal area networks (PANs). USB Controller 140 also provides USB connectivity to other miscellaneous USB connected devices 142, such as a mouse, removable nonvolatile storage device 145, modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removable nonvolatile storage device 145 is shown as a USB-connected device, removable nonvolatile storage device 145 could be connected using a different interface, such as a Firewire interface, etcetera.
Wireless Local Area Network (LAN) device 175 connects to Southbridge 135 via the PCI or PCI Express bus 172. LAN device 175 typically implements one of the IEEE 802.11 standards of over-the-air modulation techniques that all use the same protocol to wireless communicate between information handling system 100 and another computer system or device. Optical storage device 190 connects to Southbridge 135 using Serial ATA (SATA) bus 188. Serial ATA adapters and devices communicate over a high-speed serial link. The Serial ATA bus also connects Southbridge 135 to other forms of storage devices, such as hard disk drives. Audio circuitry 160, such as a sound card, connects to Southbridge 135 via bus158. Audio circuitry 160 also provides functionality such as audio line-in and optical digital audio in port 162, optical digital output and headphone jack 164, internal speakers 166, and internal microphone 168. Ethernet controller 170 connects to Southbridge 135 using a bus, such as the PCI or PCI Express bus. Ethernet controller 170 connects information handling system 100 to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks.
While FIG. 1 shows one information handling system, an information handling system may take many forms. For example, an information handling system may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system. In addition, an information handling system may take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.
FIG. 2 is a network diagram of various types of data processing systems connected via a computer network. FIG. 2provides an extension of the information handling system environment shown in FIG. 1 to illustrate that the methods described herein can be performed on a wide variety of information handling systems that operate in a networked environment. Types of information handling systems range from small handheld devices, such as handheld computer/mobile telephone 210 to large mainframe systems, such as mainframe computer 270. Examples of handheld computer 210 include personal digital assistants (PDAs), personal entertainment devices, such as MP3 players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet, computer 220, laptop, or notebook, computer 230, workstation 240, personal computer system 250, and server 260. Other types of information handling systems that are not individually shown in FIG. 2 are represented by information handling system 280. As shown, the various information handling systems can be networked together using computer network 200. Types of computer network that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), the Internet, the Public Switched Telephone Network (PSTN), other wireless networks, and any other network topology that can be used to interconnect the information handling systems. Many of the information handling systems include nonvolatile data stores, such as hard drives and/or nonvolatile memory. Some of the information handling systems shown in FIG. 2 depicts separate nonvolatile data stores (server 260 utilizes nonvolatile data store 265, mainframe computer 270 utilizes nonvolatile data store 275, and information handling system 280 utilizes nonvolatile data store 285). The nonvolatile data store can be a component that is external to the various information handling systems or can be internal to one of the information handling systems. In addition, removable nonvolatile storage device 145 can be shared among two or more information handling systems using various techniques, such as connecting the removable nonvolatile storage device 145 to a USB port or other connector of the information handling systems.
FIG. 3 is a block diagram depicting the hypervisor and operating systems interaction with CPU components in order to manipulate memory management storage. System memory 300 includes Memory Management Storage 310 that further include Page Table Entries (PTEs) 320 as well as eXtension Pointers (XPs). In storage constrained and highly dynamic computing environments, page table manipulations can be frequent enough that the hypervisor call (hcall) overhead causes performance degradation. This approach provides a technique and resources with which an operating system (370) can directly manipulate page table entries 320. In one embodiment, the page table structure includes of a hashed table. In one embodiment, the entry may be either a Page Table Entry (PTE) or an eXtension Pointer (XP), which points to a page containing 256 PTEs. The operating system may use a variety of data structures to track the allocation of storage, including the Page Table itself. Those structures which contain the real address reside in storage with a new storage attribute called Memory Management, which is used to protect the integrity of the Page Frame Descriptor (PFD). Each entry in Memory Management Storage (MMS) 310 is a quadword, with the Page Frame Descriptor, consisting of the real address, page size, and storage control bits 321 (WIMG) attribute information, located in fixed locations consistent with the Page Table Entry format.
In one embodiment, MMS 310 is accessed freely by hypervisor 380 through Load/Store Unit 330 of CPU 325, and is accessed via registers 340 using defined instructions by operating system running on the system. Values stored in registers340 are processed by Load/Store Unit 330 to update PTE 320. In one embodiment, the Memory Management attribute is identified by control bits 321 (WIMG)=Ob1100. A second special WIMG combination (WIMG=Ob1101) is used to identify XPs in the hashed page table. In one embodiment where the second special WIMG combination is used, the kernel storage is mapped by page tables that are under the control of the hypervisor. It is also possible to have range registers or some such technique to create MMS 310 without the use of page tables. In some embodiments, hypervisor 380 might need to "steal" pages (e.g., for additional memory needs, etc.). In addition, in some embodiments, it might be necessary to differentiate PTEs that are under hypervisor control from those which may be manipulated by the operating system. Control indicator 322, also referred to as "the O bit" indicates whether the PTE can be managed by the OS (e.g., O=1) or may be updated only by the hypervisor (e.g., O=0). To ensure proper use of the page frames, the base address and the page size are provided and manipulated in a way that does not allow the operating system to access storage outside the bounds defined by the page frame real address and page size. In one embodiment, the operating system can alter the address and size to address a smaller page within the page provided by the hypervisor. In one embodiment, the operating system is further restricted in that it may not change the WIMG attributes.
Four registers 340 are used to communicate PTE data. The Page Frame Descriptor Register (PFDR) 350 is the repository for the authorized Page Frame Descriptor (i.e. the page frame base address, the page size, the WIMG attributes, and the valid bit). Note that in one embodiment, access to Page Frame Descriptor Register (PFDR) 350 is privileged and can be accessed by the operating system using the LPTE and STPTE instructions discussed above. In one embodiment, manipulation of the PFDR by the operating system is possible as a monolithic set of data using the LPTE and STPTE instructions. In this embodiment, the operating system is not permitted to manipulate individual fields of the PFDR. In addition, when the PTE is stored using STPTE, the PTE will be a consistent integration, or merger, of the PFDR content with PFAR1 and PFAR2, rather than solely a reflection of what is in the PFDR. In a further embodiment, for some system security implementations, it may be desirable to inhibit the operating system from reading the real address portion of the PFDR as this information may be considered secure. Page Frame Attribute Registers 1 and 2 (PFAR1 355, PFAR2 360) hold the other bits for a PTE. The Page Frame Attribute Registers also contain the bits that control page size, which may be programmed by the operating system, and identify a proper subset of the page specified in the PFDR. In this manner, in one embodiment, the operating system is able to make limited modifications to some of the fields that are included in the PFDR and one of either PFAR 1 or PFAR 2. For example, the operating system can change the L and LP values (the changed values go in PFAR1 and PFAR2, not PFDR) to specify a smaller page within the page it was originally given.
The Page Table Entry Address Register (PTEAR) 345 includes the effective address of the PTE to be updated and a valid bit that indicates the quadword is a PTE which the operating system may update. Page Table Entry Address Register (PTEAR) 345 is used to enforce the management state of a PTE when updating the PTE. In one embodiment, the PTEAR may only be loaded by using the LPTEAR instruction discussed below. The PTEAR includes the effective address of the PTE and a valid bit that indicates that the entry is a PTE (as opposed to an eXtension Pointer) and that the PTE is not in a hypervisor management state.
Four instructions are used to manage page table entries. These four instructions are hardware instructions executed by Load/Store Unit 330 of Central Processing Unit (CPU) 325. The instruction are as follows: First, Load Page Table Entry (LPTE) is an instruction that tests for the memory management attribute and that the PTE may be updated by the OS, and also the absence of the WIMG combination that indicates an eXtension Pointer as part of the load of the PFDR and PFARs (resetting the valid bit if the conditions are not met). Second, Store Page Table Entry (STPTE) is an instruction that stores the merge of the PFDR and the PFARs to a location in storage if the target quadword is not an eXtension Pointer and is not being managed by the hypervisor. As part of the merge operation, the STPTE instruction verifies that the L/LP bits supplied in the PFARs are consistent with those in the PFDR. As known by those skilled in the art, in one embodiment, the L/LP bits indicate the page size and, in some cases, the alignment of the page in storage. Third, Load Page Table Entry Address Register (LPTEAR) is an instruction that loads the effective address of the target PTE and checks to ensure that the quadword is not an eXtension Pointer and that the hypervisor is not managing the entry, setting a valid bit accordingly. Fourth, Page Frame Descriptor Invalidate (PFDI) is an instruction that sets the valid bit in the PFDR to zero.
To write a new PTE, the operating system first loads the address into the PTEAR using the LPTEAR instruction. The operating system then loads an authorized Page Frame Descriptor in the format of a PTE into the PFDR and PFARs (with L/LP bits replicated into the appropriate bits of the PFARs) using the LPTE instruction. The operating system then modifies the contents of the PFARs using the MFSPR and MTSPR instructions to establish the appropriate page size, protection attributes, and so forth. Last, the operating system uses the STPTE instruction to merge and store the PTE.
In one embodiment, Memory Management Storage 310 includes two types of memory-management related structures: Page Table Entries (PTE) 320 and eXtension Pointers (XPs). General access to Memory Management Storage using In one embodiment, Load and Store instructions are limited to hypervisor state (hypervisor 380). Non-hypervisor privileged software (e.g., operating systems 370) may access Memory Management Storage via the Load Page Table Effective Address Register (LPTEAR), Load Page Table Entry (LPTE), Load Real Address (LRA), Store eXtension Pointer, and Store Page Table Entry instructions. In one embodiment, other attempts to access Memory Management Storage 310 by non-hypervisor privileged software is considered a storage protection violation.
As outlined above, this approach provides an operating system operating in a hypervised system with some limited ability to load and store data to the memory management storage. Accessing memory management storage via the registers and the instructions described above allows the operating system to access memory management storage while maintaining the integrity of the page table through the processes performed by the instructions.
FIG. 4 is a first flowchart depicting steps taken by an operating system to handle an incoming page table request. Operating system processing is shown commencing at 400 whereupon, at step 410, a page table request is received. As shown, there can be many different request types including 1. reallocate page to another process, 2. change protection attributes, 3. subdivide page, 4. create another PTE to map to same real page, 5. manipulate reference and change bits, 6. change software control bits, 7. increase page size, 8. change storage control bits, 9. move page, and the like. Some of these pages may need the hypervisor to execute, while others may be performed by the operating system using registers340 introduced in FIG. 3, and related text, above. Returning to FIG. 4, a decision is made as to whether the page table request received at the operating system requires the hypervisor (decision 420). For example, in one embodiment, the hypervisor is required to increase a page size, to change the storage control bits, and to move a page. If the received request does not require the hypervisor, then decision 420 branches to the "no" branch whereupon, at step 425, a control indicator is checked (e.g., control indicator "O bit" 322 shown in FIG. 3) in order to determine if the page table entry (e.g., PTE 320 shown in FIG. 3) is hypervisor or operating system controlled. For example, in one embodiment, if the control indicator is "1" then the PTE is operating system controlled, and if the control indicator is "0" then the PTE is hypervisor controlled.
A decision is made as to whether the PTE is hypervisor controlled (decision 430). If the request is hypervisor controlled, then decision 430 branches to the "yes" branch. If either the request requires the hypervisor (decision 420 branching to the "yes" branch) or the control indicator identifies the hypervisor as controlling the PTE (decision 430 branching to the "yes" branch), then the hypervisor handles the request at step 440. On the other hand, if the request does not require the hypervisor (decision 420 branching to the "no" branch) and the PTE is not hypervisor controlled (decision 430 branching to the "no" branch), then the operating system updates the PTE at predefined process 450 (see FIG. 5 and corresponding text for processing details). A decision is made as to whether the update performed by the operating system was successful (decision 460). If the update was successful, then decision 460 branches to the "yes" branch whereupon, at step 470, a successful return code is returned to the requestor indicating that the request was performed successfully. On the other hand, if the update attempted by the operating system was not successful, then decision 460 branches to the "no" branch whereupon, at step 480, an error is returned to the requestor indicating that the page table request was not successful.
FIG. 5 is a second flowchart depicting actions taken by the operating system to update the page table entry. This routine is called from predefined process 450 shown in FIG. 4. Processing commences at 500 whereupon, at step 510, the operating system loads the address of the PTE into PTEAR register 345 using the LPTEAR instruction. The LPTEAR instruction validates that the PTE can be manipulated by the operating system and also loads the address of the PTE into the PTEAR register. At step 520, the PTE data is loaded from memory into various registers (PFDR 350, PFAR1 355, and PFAR2 360) using the LPTE instruction. The LPTE instruction uses the (now validated) address that was loaded in the PTEAR register during step 510 to load data to the various registers. At step 530, the operating system alters the data stored in PFAR1 and 2 (registers 355 and 360) to describe the new page that the operating system is mapping in system memory. After the various registers are loaded and the contents are altered as needed, at step 540, the operating system executes the Store Page Table Entry (STPTE) hardware instruction to store the new PTE into Memory Management Storage (MMS).
Block 550 shows steps performed by the Load/Store Unit of the CPU to execute the STPTE instruction. First, at step 560, the Load/Store Unit validates data stored in the registers, such as the contents stored in PFAR1 and 2 which could have been altered by the operating system during step 530. A decision is made by the Load/Store Unit, based on the validation of the data, as to whether the update to the PTE is allowed (decision 570). If the update is allowed, then decision 570branches to the "yes" branch whereupon, at step 580, the Load/Store Unit of the CPU updates PTE 320 using values loaded in registers 340. On the other hand, if the update is not allowed, then decision 570 branches to the "no" branch whereupon, at step 590, the Load/Store Unit causes an error to occur indicating that the PTE was not updated. After block550 concludes, at 595, processing returns to the calling routine (see FIG. 4) with a result that indicates whether the update was allowed (performed).
