Patent Publication Number: US-11023385-B2

Title: System and method for one step address translation of graphics addresses in virtualization

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of application Ser. No. 16/182,899, filed Nov. 7, 2018 (now U.S. Pat. No. 10,671,541 issued Jun. 2, 2020), which is a continuation of application Ser. No. 14/711,312, filed May 13, 2015 (now U.S. Pat. No. 10,133,674 issued Nov. 20, 2018), which is a continuation of application Ser. No. 11/025,126, filed Dec. 29, 2004 (now U.S. Pat. No. 9,058,292 issued Jun. 16, 2015), which are hereby incorporated by reference. 
    
    
     BACKGROUND ART 
     A graphics device may require a contiguous memory range to store graphics data. The graphics data may include, for example, three-dimensional data and instructions used by, for example, a graphics subsystem in a personal computer. The contiguous graphics memory may be correlated to a physical memory using a graphics translation table. However, the physical memory may not be contiguous. 
     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. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings: 
         FIG. 1  is block diagram of a computer system, according to some embodiments hereof; 
         FIG. 2  is an exemplary depiction of a graphics translation table, according to some embodiments herein; 
         FIG. 3  is an exemplary depiction of a virtual machine, according to some embodiments herein; 
         FIG. 4  is an exemplary depiction of physical memory mapping on a virtualized machine, in accordance with some embodiments herein; 
         FIG. 5  is a flow diagram of a memory translation including two translations; 
         FIG. 6  is an exemplary memory translation scheme including one translation operation, according to some embodiments herein; 
         FIG. 7  is an exemplary flow diagram of a process, according to some embodiments herein; and 
         FIG. 8  is an exemplary depiction of a logical memory map illustrating a guest graphics memory address to host physical address translation, in accordance with some embodiments herein. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  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  100 . Computer system  100  includes a processor  105 . Processor  105  represents a central processing unit of any type of architecture. Some embodiments hereof may be implemented by computer systems having multiple processors. Computer system  100  includes a chipset  110  that has a number of control circuits and a number of interface circuits to allow processor  105  to access a system memory  115 , a system bus  150  (e.g., a Peripheral Component Interconnect (PCI) Express bus), and a graphics device  160 . 
     A number of peripheral component interconnect (PCI Express) devices  155   1  through  155   n  are connected to Express bus  150 , as defined by the PCI Special Interest Group (PCI-SIG) in “PCI Express Base Specification, Version 1.0” (July 2002). PCI Express devices  155   1  through  155   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  110  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  150 , graphics device  160 , system memory  115 , processor  105 , etc. 
     It should be appreciated that computer system  100  may include other, additional, or fewer components than those illustrated in  FIG. 1 , without departing or altering the scope of the various embodiments herein. 
     System memory  115  represents one or more mechanisms for storing information. For example, system memory  115  may include non-volatile or volatile memories. In some embodiments, system memory  115  includes a graphics memory unit  118 , a graphics aperture  120  and a main memory  125 . Main memory  125  may include an operating system (OS)  130 , a memory manager  135 , a graphics memory translation table  140 , and additional main memory  145  allocated for other information such as, for example, other programs and data. 
     Graphics device  160  may be an add-in device or integrated into computer system  100 . In some embodiments, graphics device  160  includes a graphics processor  165  and a graphics local memory  170 . 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  160  performs graphics functions, such as, 3-D rendering operations, drawings, etc. Graphics processor  165  has access to its own graphics local memory  160 . Graphics device  160  may be coupled to chipset  110  via accelerated graphics port (AGP)  175 . AGP  175  provides a high-speed bus for moving data directly from system memory  115  to graphics device  160 . Direct references may be made to system memory  115 . Due to the direct references to system memory  115 , a contiguous view of system memory  115  may be essential for efficient transfer of information between graphics device  160  and system memory  115 . 
     In some embodiments, graphics device  160  may be coupled to chipset via PCI express bus  150 . 
     In some embodiments, a range of system memory  115  is reserved for graphics memory unit  118  including graphics aperture  120 . Graphics aperture  120  provides a range of memory addresses used by AGP  175  for graphics information such as, for example, 3-D features and textures. However, since system memory  115  is dynamically allocated for graphics data, it is necessary to provide a graphics mapping table mechanism to map random segments of system memory  115  into a single contiguous, physical space for graphics aperture  120 . 
     A graphics memory translation table such as a Graphics Address Re-Mapping 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  175 , 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 4K pages, it may be necessary to provide an address mapping mechanism that maps random 4K pages into a single contiguous, physical address space. 
       FIG. 2  illustrates an exemplary graphics memory translation table map, generally represented by reference number  200 . In some embodiments, system memory  115  includes a main memory  125  having an address range from address zero (0) to a top thereof. Graphics aperture  120  may have an address range that begins from the top of main memory  125 . Graphics aperture  120  is a virtual memory and maps into the physical address space of main memory  125 . 
     Graphics aperture  120  is a portion of system memory  115  that is allocated by operating system  130  for use by graphics device  160 . Graphics device  160  is provided access to the reserved graphics aperture  120  to store texture data, front buffer data or other graphics data for faster graphics data processing. Each address Pa in graphics aperture  120  has a corresponding entry mapped into a physical address space Pg of main memory  125 . 
     Operating system  130  allocates pages in main memory  125  (of system memory  115 ) wherever they are found and assigns them for graphics device  160 . Graphics device  160  is therefore provided with a continuous block of graphics aperture  120 , wherein references pointing from a graphics aperture  120  address Pa to a corresponding address Pg in main memory  125  are stored in graphics memory translation table  140  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. 3  illustrates an exemplary system  300  that supports virtualization. System  300  includes physical host hardware  305 , a number of guest virtual machines VM 0    310   0  and VM 1    310   1 , and a virtual machine monitor (VMM)  330 . Each of VM 0    310   0  and VM 1    310   1  may be referred to as a guest herein relative to physical host hardware  305 . In some embodiments, physical host hardware  305  may include a computer system and/or components thereof similar to system  100  illustrated in  FIG. 1 . Physical host hardware  305  may also be referred to herein as the host. 
     It should be appreciated that the particular physical host hardware included in host  305  may be varied, much as system  100  may be altered as stated in conjunction with the discussion of  FIG. 1 , without departing from and/or altering the scope of the various embodiments herein. 
     In some embodiments, physical host hardware  305  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 0    310   0  and VM 1    310   1  are shown in system  300 . It should be appreciated that more or fewer virtual machines may be included or supported in system  300 . VM 0    310   0  and VM 1    310   1  are depicted as including similar components. For example, VM 0    310   0  has a number of addresses  315 , a guest OS G 1   320 , and components  325  associated therewith. In a similar manner, VM 1    310   1  has a number of addresses  317 , a guest OS G 2   322 , and virtual components  327 . It should be appreciated by those in the art that differences in functionality may exist between the virtual machine(s) supported by system  300 . 
     In some embodiments, VMM  330  provides a hardware-software interface to each of VM 0    310   0  and VM 1    310   1 . Each instance of the hardware-software interface may provide an efficient replica of host  305 , 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  300 . In some embodiments, guest OS G 1   320  and guest OS G 2   322  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&#39;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. 4  is an illustration showing guest OS memory mapped to host memory in a system that supports virtualization. As illustrated, guest G 1  address space  410  is 128 MB and guest G 1  address space  405  is 256 MB. Physical memory address space for guest OS G 1  (P g1 ) and guest OS G 2  (P g2 ) are shown mapped to host physical address space (P h1 ) and (P h2 ), respectively. For example, guest memory address  415  is mapped to host address  420 , and guest address  425  is mapped to  430 . 
     It should be appreciated that the address locations and sizes shown in  FIG. 4  are provided as examples, not necessarily actual memory addresses. Furthermore, the exemplary memory illustrated in  FIG. 4  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. 5  provides an illustrative depiction of a two-step translation process  500  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  110 . Chipset  110  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  510  provides the translation from the physical guest address (Pg) to the physical host address (Ph). DMA re-map mechanism  510  may be implemented in hardware or software. 
     In accordance with some embodiments herein,  FIG. 6  provides an exemplary illustration of a process  605  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  605 , 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  110  shown in  FIG. 1 . 
       FIG. 7  is an exemplary flow diagram of a process  700 , according to some embodiments herein.  FIG. 8  may be referenced in conjunction with  FIG. 7  for a better understanding of  FIG. 7  and the discussion thereof.  FIG. 8  is an exemplary depiction of a logical memory map, generally represented by reference number  800 , illustrating a guest graphics memory address (Pa) to host physical address (Ph) translation, facilitated by a PTE to a graphics memory translation table  810 . The graphics memory translation table  810  (e.g., a GTT) is used to facilitate a translation or mapping of guest graphics memory address (Pa)  805  to host physical address (Ph)  815 . The translation may be facilitated by DMA remapping. 
     At operation  705 , 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  710 , 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  410 . The guest graphics memory address (Pa) may be mapped to the host physical address (Ph) in GTT  810  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 ( 815 ) to DMA data from main memory  125  of physical host hardware  330 . 
     In some embodiments herein, the process of using a graphics memory translation table  810  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  810  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  810  to map a guest graphics memory address (Pa) to a host physical address (Ph), a guest OS driver and a VMM (e.g.,  330 ) 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  810  may be read-only for the guest OS. Accordingly, the guest OS can only read from GTT  810 . In these embodiments, the guest OS driver may attempt to write a guest graphics memory address to the GTT  810 . 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  810  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  810  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  810 . In these embodiments, the guest OS is unaware of the guest-to-host mapping functionality or process herein. Any writes intended for GTT  810  by a guest OS driver are captured by the VMM (e.g.,  330 ). 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  700  is implemented in hardware. An address decoder or other hardware devices may be used to detect writes to GTT  810 . 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&#39;s physical memory (i.e., a guest OSS cannot snoop on the activity of another VM&#39;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. 
     The several embodiments described herein are solely for the purpose of illustration. The various features described herein need not all be used together, and any one or more of those features may be incorporated in a single embodiment. Therefore, persons in the art will recognize from this description that other embodiments may be practiced with various modifications and alterations.