Patent Description:
Virtualization, in some aspects, is a technique to operate one or more guest operating systems (OS) on the same host hardware by presenting multiple copies of a host hardware-software interface to each guest OS. In a system that supports virtualization, a memory address for the guest may be correlated to host physical memory address. The physical host memory may back up the physical guest memory.

Furthermore, in a system having a graphics device and supporting virtualization, it may be necessary to provide two memory address translations. One translation to map a graphics address to a physical guest address and a second translation to translate the physical guest address to a physical host address.

Thus, there exists a need in the technology to provide a system and method to efficiently translate graphics addresses in a context that supports virtualization. <CIT> relates a method and apparatus for managing memory used by a device driver in an operating system. The method comprises: (i) configuring a chipset to set up a mapping table for memory address translation, (ii) allocating a device memory in response to a request by the device driver, and (iii) mapping non-contiguous system memory to contiguous device memory using the mapping table. <CIT> reports a software monitor, interposed between the hardware layer of a computer system and one or more guest operating systems, constructs and maintains a guest-physical-address-to-host-physical-address map for each guest operating system, and maintains a virtual memory addressing context for each guest operating system that may include a virtual-hash-page table for each guest operating system, the contents of translation registers for each guest operating system, CPU-specific virtual-memory translations for each guest operating system, and the contents of various status registers. The monitor runs at the highest privilege level provided by the hardware system, intercepting attempts to execute privileged instructions by guest operating systems, and simulates or enhances certain of the privileged instructions related to virtual-memory addressing in order to construct and maintain the guest-physical-address-to-host-physical-address map and to provide each guest operating system with the illusion that the guest operating system is executing as the most privileged process on a virtual machine. <CIT> reports a translation look aside buffer hardware in a central processor (CP) that receives the results of double-level address translations to eliminate the need for having shadow tables for the second-level in a virtual machine environment. Hardware is provided for indicating whether a requested address sent by the CP Instruction Execution (IE) unit for translation is a guest or host/native request, and for a guest request whether it is a real or virtual address. Intermediate translations for a double-level translation may or may not be inhibited from being loaded into the TLB. Guest entries may be purged from the TLB without disturbing any host entries. An accelerated preferred guest mode in the CP forces single-level translation hardware to translate each accelerated preferred guest request. A non-accelerated guest request may instead be translated by microcode. A limit check register is provided to check preferred guest addresses without causing performance degradation. <CIT> relates a modular architecture for storing, addressing and retrieving graphics data from main memory instead of expensive local frame buffer memory. A graphic address remapping table (GART), defined in software, is used to remap virtual addresses falling within a selected range, the GART range, to non-contiguous pages in main memory. Virtual address not within the selected range are passed without modification. The GART includes page table entries (PTEs) having translation information to remap virtual addresses falling within the GART range to their corresponding physical addresses. The GART PTEs are of configurable length enabling optimization of GART size and the use of feature bits, such as status indicators, defined by software. The GART is implemented during system boot up by configuration registers. Similarly, the PTEs are configured using mask registers. The GART may be used in conjunction with a translation lookaside buffer (TLB) to improve address remapping performance.

The invention is according to the claims as appended herein.

<FIG> is an exemplary block diagram illustrating physical hardware of a computer system that may be used in some embodiments hereof, generally represented by reference number <NUM>. Computer system <NUM> includes a processor <NUM>. Processor <NUM> represents a central processing unit of any type of architecture. Some embodiments hereof may be implemented by computer systems having multiple processors. Computer system <NUM> includes a chipset <NUM> that has a number of control circuits and a number of interface circuits to allow processor <NUM> to access a system memory <NUM>, a system bus <NUM> (e.g., a Peripheral Component Interconnect (PCI) Express bus), and a graphics device <NUM>.

A number of peripheral component interconnect (PCI Express) devices <NUM><NUM> through <NUM>n are connected to Express bus <NUM>, as defined by the PCI Special Interest Group (PCI-SIG) in "PCI Express Base Specification, Version <NUM>" (July <NUM>). PCI Express devices <NUM><NUM> through <NUM>n are input/output (I/O) hardware devices such as, for example, a disk controller/card, a local area network controller/card, etc..

In some embodiments, chipset <NUM> may have one or more bus controllers (e.g., PCI Express bus), a graphics controller, a CPU controller, and a memory controller to control data access between various components such as, for example, bus <NUM>, graphics device <NUM>, system memory <NUM>, processor <NUM>, etc..

It should be appreciated that computer system <NUM> may include other, additional, or fewer components than those illustrated in <FIG>, without departing or altering the scope of the various embodiments herein.

System memory <NUM> represents one or more mechanisms for storing information. For example, system memory <NUM> may include non-volatile or volatile memories. In some embodiments, system memory <NUM> includes a graphics memory unit <NUM>, a graphics aperture <NUM> and a main memory <NUM>. Main memory <NUM> may include an operating system (OS) <NUM>, a memory manager <NUM>, a graphics memory translation table <NUM>, and additional main memory <NUM> allocated for other information such as, for example, other programs and data.

Graphics device <NUM> may be an add-in device or integrated into computer system <NUM>. In some embodiments, graphics device <NUM> includes a graphics processor <NUM> and a graphics local memory <NUM>. The memory may be random access memory (RAM) (e.g., extended data out dynamic random access memory (EDO), synchronous graphic random access memory (SGRAM), video random access memory (VRAM)). The memory is included, since the video card must be able to remember a complete screen image at any time, and maintain local copies of graphics programs, and graphics objects like triangles, and textures. It is noted that some embodiments herein are also applicable to graphics devices and I/O devices having no local memory.

Graphics processor <NUM> performs graphics functions, such as, <NUM>-D rendering operations, drawings, etc. Graphics processor <NUM> has access to its own graphics local memory <NUM>. Graphics device <NUM> may be coupled to chipset <NUM> via accelerated graphics port (AGP) <NUM>. AGP <NUM> provides a high-speed bus for moving data directly from system memory <NUM> to graphics device <NUM>. Direct references may be made to system memory <NUM>. Due to the direct references to system memory <NUM>, a contiguous view of system memory <NUM> may be essential for efficient transfer of information between graphics device <NUM> and system memory <NUM>.

In some embodiments, graphics device <NUM> may be coupled to chipset via PCI express bus <NUM>.

In some embodiments, a range of system memory <NUM> is reserved for graphics memory unit <NUM> including graphics aperture <NUM>. Graphics aperture <NUM> provides a range of memory addresses used by AGP <NUM> for graphics information such as, for example, <NUM>-D features and textures. However, since system memory <NUM> is dynamically allocated for graphics data, it is necessary to provide a graphics mapping table mechanism to map random segments of system memory <NUM> into a single contiguous, physical space for graphics aperture <NUM>.

A graphics memory translation table such as a Graphics Address ReMapping Table (GART) or a Graphics Translation Table (GTT) may be used to provide a physically-contiguous view of scattered pages in system memory for direct memory access (DMA) transfers. With AGP <NUM>, main memory is specifically used for advanced three-dimensional features, such as textures, alpha buffers, and ZBuffers. As mentioned above, since the AGP generates direct references into system memory, a contiguous view of that space is essential. However, since system memory is dynamically allocated in, for example, random <NUM> pages, it may be necessary to provide an address mapping mechanism that maps random <NUM> pages into a single contiguous, physical address space.

<FIG> illustrates an exemplary graphics memory translation table map, generally represented by reference number <NUM>. In some embodiments, system memory <NUM> includes a main memory <NUM> having an address range from address zero (<NUM>) to a top thereof. Graphics aperture <NUM> may have an address range that begins from the top of main memory <NUM>. Graphics aperture <NUM> is a virtual memory and maps into the physical address space of main memory <NUM>.

Graphics aperture <NUM> is a portion of system memory <NUM> that is allocated by operating system <NUM> for use by graphics device <NUM>. Graphics device <NUM> is provided access to the reserved graphics aperture <NUM> to store texture data, front buffer data or other graphics data for faster graphics data processing. Each address Pa in graphics aperture <NUM> has a corresponding entry mapped into a physical address space Pg of main memory <NUM>.

Operating system <NUM> allocates pages in main memory <NUM> (of system memory <NUM>) wherever they are found and assigns them for graphics device <NUM>. Graphics device <NUM> is therefore provided with a continuous block of graphics aperture <NUM>, wherein references pointing from a graphics aperture <NUM> address Pa to a corresponding address Pg in main memory <NUM> are stored in graphics memory translation table <NUM> as a page table entry (PTE).

Virtualization, in some aspects, is a technique to operate one or more guest operating systems (OS) on the same native hardware by presenting multiple copies of a host hardware-software interface to each guest OS. The native hardware may be referred to as the host. The multiple guest OSs may even run concurrently. In a virtualization context, managing memory used by a graphics device or subsystem is further complicated because of a need to translate guest memory addresses to physical host addresses due to the virtualization of the host hardware.

<FIG> illustrates an exemplary system <NUM> that supports virtualization. System <NUM> includes physical host hardware <NUM>, a number of guest virtual machines VM<NUM> <NUM><NUM> and VM<NUM> <NUM><NUM>, and a virtual machine monitor (VMM) <NUM>. Each of VM<NUM> <NUM><NUM> and VM<NUM> <NUM><NUM> may be referred to as a guest herein relative to physical host hardware <NUM>. In some embodiments, physical host hardware <NUM> may include a computer system and/or components thereof similar to system <NUM> illustrated in <FIG>. Physical host hardware <NUM> may also be referred to herein as the host.

It should be appreciated that the particular physical host hardware included in host <NUM> may be varied, much as system <NUM> may be altered as stated in conjunction with the discussion of <FIG>, without departing from and/or altering the scope of the various embodiments herein.

In some embodiments, physical host hardware <NUM> may include a processor, a memory, various I/O devices (e.g., keyboard, monitor, USB controller, network controller etc.), and a graphics device.

Two virtual machines VM<NUM> <NUM><NUM> and VM<NUM> <NUM><NUM> are shown in system <NUM>. It should be appreciated that more or fewer virtual machines may be included or supported in system <NUM>. VM<NUM> <NUM><NUM> and VM<NUM> <NUM><NUM> are depicted as including similar components. For example, VM<NUM> <NUM><NUM> has a number of addresses <NUM>, a guest OS G1 <NUM>, and components <NUM> associated therewith. In a similar manner, VM<NUM> <NUM><NUM> has a number of addresses <NUM>, a guest OS G2 <NUM>, and virtual components <NUM>. It should be appreciated by those in the art that differences in functionality may exist between the virtual machine(s) supported by system <NUM>.

In some embodiments, VMM <NUM> provides a hardware-software interface to each of VM<NUM> <NUM><NUM> and VM<NUM> <NUM><NUM>. Each instance of the hardware-software interface may provide an efficient replica of host <NUM>, including the processing, memory, instructions, and other resources thereof (e.g., memory and I/O devices) to the virtual machines connected to or supported by system <NUM>. In some embodiments, guest OS G1 <NUM> and guest OS G2 <NUM> may operate concurrently, in part due to each guest OS operating in its own virtual machine.

In a system that supports virtualization, a guest memory address needs to be translated or mapped to a host physical address since the physical guest memory address (Pg) is a virtual memory address that is actually located at a physical host address (Ph). That is, since the guest's resources, including memory, are virtualizations of hardware or the entire hardware environment of the host, a correlation must be established to associate guest memory addresses (Pg) to physical host addresses (Ph).

Thus, in a virtualized system or a system that supports virtualization, it may be necessary to translate a graphics address of a virtual, guest machine to an actual physical host address location. In accordance with some embodiments herein, there is provided a method and a system to efficiently translate graphics addresses in a context that supports virtualization.

In a computing system that supports virtualization, a guest memory address, Pg, may be backed up by (i. e, located at) a physical host address Ph.

<FIG> is an illustration showing guest OS memory mapped to host memory in a system that supports virtualization. As illustrated, guest G1 address space <NUM> is <NUM> MB and guest G1 address space <NUM> is <NUM> MB. Physical memory address space for guest OS G1 (Pg1) and guest OS G2 (Pg2) are shown mapped to host physical address space (Ph1) and (Ph2), respectively. For example, guest memory address <NUM> is mapped to host address <NUM>, and guest address <NUM> is mapped to <NUM>.

It should be appreciated that the address locations and sizes shown in <FIG> are provided as examples, not necessarily actual memory addresses. Furthermore, the exemplary memory illustrated in <FIG> do not represent or imply any limitations to the present disclosure.

It should be appreciated that while various embodiments and aspects of the present disclosure are discussed in the context of a graphics device assigned to a virtual machine and associating a memory address thereof with a physical host address, various aspects and embodiments of the present disclosure may encompass other types of devices. That is, various aspects and embodiments herein may include devices, systems, and subsystems other than a graphics device. For example, an I/O device having a local processor and local memory and forming part of a virtual machine or system that supports virtualization may also benefit from the systems and methods of the present disclosure. As an example, a memory address for a virtual machine I/O device having a processor and a local memory, similar to but not necessarily a graphics device or graphics subsystem, may be used with and/or include aspects of the present disclosure.

<FIG> provides an illustrative depiction of a two-step translation process <NUM> used to map a graphics aperture address (Pa) of a graphics device to a physical guest address (Pg) that is backed up by an actual physical host memory address (Ph) located in main memory of a host system. For example, graphics aperture address (Pa) is translated to a guest physical address (Pg) by chipset <NUM>. Chipset <NUM> uses a graphics memory translation table mechanism such as a GTT and page table entries (PTEs) to map the graphics aperture address (Pa) to the physical guest address (Pg). However, the guest physical address (Pg) must still be associated with a host physical address (Ph) since the host physical hardware is where the actual physical memory locations exist. A DMA remap mechanism of operation <NUM> provides the translation from the physical guest address (Pg) to the physical host address (Ph). DMA re-map mechanism <NUM> may be implemented in hardware or software.

In accordance with some embodiments herein, <FIG> provides an exemplary illustration of a process <NUM> to map a graphics memory (e.g., aperture) address (Pa) of a guest, virtual machine to a physical host address (Ph) in a single process or operation. Per operation <NUM>, a graphics translation table is provided that may use PTEs for mapping a guest graphics memory address (Pa) to physical host address (Ph).

In some embodiments, the graphics memory translation table may be a GART or a GTT. Furthermore, the graphics memory translation table may be implemented in a chipset, such as, for example, chipset <NUM> shown in <FIG>.

<FIG> is an exemplary flow diagram of a process <NUM>, according to some embodiments herein. <FIG> may be referenced in conjunction with <FIG> for a better understanding of <FIG> and the discussion thereof. <FIG> is an exemplary depiction of a logical memory map, generally represented by reference number <NUM>, illustrating a guest graphics memory address (Pa) to host physical address (Ph) translation, facilitated by a PTE to a graphics memory translation table <NUM>. The graphics memory translation table <NUM> (e.g., a GTT) is used to facilitate a translation or mapping of guest graphics memory address (Pa) <NUM> to host physical address (Ph) <NUM>. The translation is facilitated by DMA remapping.

At operation <NUM>, in a system that supports virtualization, a request for memory is made for a graphics device (or other I/O device) assigned to a virtual machine (i.e., guest).

At operation <NUM>, a mapping or translation of the guest graphics memory address (Pa) to the host physical address (Ph) is provided. The host physical address Ph is an actual address location of physical memory in system memory of the physical host hardware <NUM>. The guest graphics memory address (Pa) is mapped to the host physical address (Ph) in GTT <NUM> using a DMA remapping technique. The graphics device, and more generally an I/O device including a processor and local memory that is assigned or supported by virtualization, uses host physical addresses (<NUM>) to DMA data from main memory <NUM> of physical host hardware <NUM>.

In some embodiments herein, the process of using a graphics memory translation table <NUM> to map a guest graphics memory address (Pa) to a host physical address (Ph) may be implemented in software. In some embodiments herein, the process of using graphics memory translation table <NUM> to map the guest graphics memory address (Pa) to the host physical address (Ph) may be implemented in hardware. The hardware mechanism may use page table translation logic in chipset hardware.

Regarding some embodiments including a software implementation of the process of using a graphics memory translation table <NUM> to map a guest graphics memory address (Pa) to a host physical address (Ph), a guest OS driver and a VMM (e.g., <NUM>) cooperate to manage entries to the graphics memory translation table. The guest OS driver provides a physical host address (Ph) directly to the graphics memory translation table. Prior to installing the host physical address (Ph) in the graphics memory translation table, the guest OS driver queries the VMM for a valid physical host address. In response to the query by the guest OS, the VMM provides a valid (e.g., available) host physical address (Ph). That is, the VMM only returns a host physical address that is valid for use by the guest OS. The guest OS driver then installs the valid physical host address (Ph) in the GTT.

In some software implemented embodiments, a guest OS driver and a VMM cooperate to manage entries to the graphics memory translation table in which the guest OS driver is aware of the guest-to-host mapping. Graphics memory translation table <NUM> may be read-only for the guest OS. Accordingly, the guest OS can only read from GTT <NUM>. In these embodiments, the guest OS driver may attempt to write a guest graphics memory address to the GTT <NUM>. The VMM may provide a service to validate physical host addresses prior to entering the validated physical host addresses (Ph) into the graphics memory translation table. That is, the VMM validates the physical host addresses and enters the validated physical host addresses into the graphics memory translation table. The VMM validation and entry of the physical host addresses into GTT <NUM> may be provided to offer a level of security to safeguard against a guest OS from accessing a physical host address needed by, for example, another guest OS.

In some software implemented embodiments herein, writes or installs of physical host memory to GTT <NUM> may be accomplished as part of a batch process. Accordingly, system resource overhead may be amortized.

In some software implemented embodiments herein, the VMM sets up the page tables used in the graphics memory translation table, GTT <NUM>. In these embodiments, the guest OS is unaware of the guest-to-host mapping functionality or process herein. Any writes intended for GTT <NUM> by a guest OS driver are captured by the VMM (e.g., <NUM>). The VMM translates a guest graphics memory address (Pa) into a corresponding physical host address (Ph) and installs the corresponding host physical address (Ph) in the graphics memory translation table. In these embodiments, it is not necessary to alter, adapt, or modify the guest OS driver to accommodate guest-to-host translations since the OS driver does not translate or make entries to the GTT. Additionally, the guest OS cannot access or monitor the physical host addresses of other VMs.

In some embodiments herein, the functionality of process <NUM> is implemented in hardware. An address decoder or other hardware devices may be used to detect writes to GTT <NUM>. Upon detection of an attempted write to the GTT by a guest OS driver, the hardware may make a query to determine a valid physical host address and install valid physical host address entries to the GTT. Hereto, as in some of the software implementation embodiments discussed above, the guest OS need not be altered or modified since the functionality of the guest-to-host mapping (i.e., translation) does not depend on the OS driver. As in some software embodiments discussed above, a measure of security is provided since the guest OS driver cannot set-up a GTT to map an entry from other VMM's physical memory (i.e., a guest OSS cannot snoop on the activity of another VM's memory).

Accordingly, a single translation operation may be provided to translate the guest graphics memory address to host physical address. In this manner, the number and frequency of translating needed for an I/O device such as, for example, a graphics device, in a system that supports virtualization may be reduced.

In accordance with the hereinabove disclosure, a graphics memory translation table may be utilized to map a guest graphics aperture address to a host physical address. Accordingly, a need for separate DMA remapping and the associated hardware costs and/or changes to translate a guest address to a host address may be reduced or eliminated. Additionally, hardware and/or software (e.g., a chipset) implementing or including the translation functionality disclosed herein may be, in some embodiments, generalized and used in systems that support virtualization.

In some embodiments herein, the graphics may include at least one chipset address remapping method in addition to the remapping methods disclosed hereinabove. For example, an I/O Memory Management Unit (not shown) may be included.

Claim 1:
An apparatus (<NUM>) comprising:
address translation circuitry (<NUM>) to perform translations for a plurality of guests in a virtual execution environment, at least one two-step translation comprising a first translation of a guest virtual address to a guest physical address and a second translation of the guest physical address to a host physical address;
hardware translation table circuitry (<NUM>) to store a one-step mapping of one or more guest virtual addresses associated with a first guest directly to host physical addresses, wherein, in the second translation of the two-step translation, a direct memory access is used;
wherein the address translation circuitry (<NUM>) is to query the hardware translation table circuitry to determine if an entry exists for a first guest virtual address to determine a first host physical address;
wherein the virtual execution environment comprises a virtual machine monitor, VMM, to control access by each guest to processing resources; and
an input/output, I/O, interface to couple a first I/O device to the address translation circuitry, wherein at least the first guest is to be associated with the first I/O device.