Patent Application
20070067505
Embodiments of the invention relate generally to computing systems, and more particularly, to input/output (I/O) virtualization.
To meet the increasing computing demands of homes and offices, virtualization technology in computing has been introduced recently. In general virtualization technology allows a platform to run multiple operating systems and applications in independent partitions. In other words, one computing system with virtualization can function as multiple “virtual” systems. Furthermore, each of the virtual systems may be isolated from each other and may function independently.
Part of virtualization technology is input/output (I/O) virtualization. In platforms supporting I/O virtualization, address remapping is used to enable assignment of I/O devices to domains, where each domain is considered to be an isolated environment in the platform. A subset of the available physical memory is designated to a domain and I/O devices assigned to that domain are allowed access to the memory allocated. Isolation is achieved by blocking access from I/O devices not assigned to that specific domain.
The system view of physical memory may be different than each domain's view of its assigned physical address space. A set of translation structures provides the needed remapping between the domain's assigned physical address space (also known as guest physical address) to the system physical address (also known as host physical address). Thus a full address translation is a two step process: In the first step, the I/O request is mapped to a specific domain (also known as context) based on the context mapping structures. In the second step, the guest physical address of the I/O request is translated to the host physical address based on the translation structures (also known as page tables) for that domain or context.
Direct memory access (DMA) remapping hardware (also referred to as DMA remap engine) is added to I/O hubs to perform the needed address translations in I/O virtualization. To enable efficient and fast address remapping, translation lookaside buffers (TLB) in DMA remap engine are used to store frequently used address translations. This speeds up an address translation by avoiding long latencies associated with main memory read operations otherwise needed to complete the address translation.
DMA remap engines in a conventional I/O hub includes a queuing structure (also known as GPA queue) to temporarily hold incoming address translation requests (may be referred to as “requests” or “translation requests” hereinafter) from one or more root ports coupled to the I/O devices. Address translation requests are triggered as a result of I/O requests from devices connected to the root ports in the I/O hub. Translation requests are issued by the GPA queue to the TLB and if valid translations are available, the TLB can service the address translations. If the needed address translation is not available, the DMA remap engine performs a page walk and loads the translation into the TLB. A page walk typically includes one or more memory read requests to fetch the needed page table entries from translation mapping tables in main memory to complete the address translation. Note that the latencies for these memory requests may be avoided by designing in caches for these intermediate mapping table entries. Design considerations such as power, die size etc may limit the capacity of the TLB. As a result, the TLB may not be able to store address translations for all translation requests stored in the GPA queue, and hence, over subscription and thrashing may occur as illustrated in the following examples.
Thrashing is a second problem that may arise out of the above described situation. As described above, the translation in Entry a has been thrown out in order to assign Entry a to Request J before Request A is serviced. Since Request A is ahead of Request J in the queuing structure 120 and requests are serviced in the order the requests are received, Request A has to be serviced before Request J. However, when Request A is serviced, Entry a does not contain the address translation for Request A but has been reassigned to Request J. As a result, the translation in Entry a is discarded and memory operations have to be performed to retrieve the address translation for Request A again. The discarding of the original translation in Entry a for Request A happening even before that translation is used is referred to as thrashing. This directly increases latency of translation and reduces the bandwidth of the associated I/O root ports.
Embodiments of the present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
A method and an apparatus to prevent over subscription and thrashing of translation lookaside buffer (TLB) entries in I/O virtualization hardware are disclosed. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding. However, it will be apparent to one of ordinary skill in the art that these specific details need not be used to practice some embodiments of the present invention. In other circumstances, well-known structures, materials, circuits, processes, and interfaces have not been shown or described in detail in order not to unnecessarily obscure the description.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.
In one embodiment, the inbound queue 308 receives I/O requests 301 from external devices coupled to one or more root ports. The I/O requests may generate address translation requests (also known as translation requests) in the inbound queue 308. The inbound queue 308 is coupled to the GPA queue 310 to forward address translation requests 304 needed to process the incoming I/O requests to the GPA queue 310, where the address translation requests 304 are temporarily held. To temporarily hold the address translation requests 304, the GPA queue 310 may store the address translation requests 304 in a buffer until the address translation requests 304 have been serviced. Then the address translation requests 304 in the buffer may be over-written by other address translation requests 304 arriving at the GPA queue later. The GPA queue 310 is coupled to the TLB 330 and the allocation/de-allocation logic 320. In response to the incoming address translation requests, the GPA queue 310 sends control signals, top—of_queue signal 314 and tlb_allocate signal 312, and TLB requests 316 with request identification 318 (such as, the index of the GPA queue entry) to the allocation/de-allocation logic 320 and the TLB 330, respectively. The TLB requests 318 contain relevant information, such as the guest physical address, the source identifier (also known as Source ID) of the requesting I/O device, and the requesting root port in configurations where the DMA remap engine is shared by multiple root ports. Note that the DMA remap engine may be shared by multiple root ports as illustrated in
In some embodiments, the GPA queue 310 is deeper than the TLB 330. Consequently, the TLB 330 may receive more TLB requests 316 to unique (4K or 2M) ranges from the GPA queue 310 than the number of TLB entries in the TLB 330. As discussed in Background, this may lead to over subscription and/or thrashing in the TLB 330. To avoid over subscription and/or thrashing, the allocation/de-allocation logic 320 uses an allocation window and a de-allocation window to manage allocation and de-allocation of TLB entries, respectively. Details of these techniques are described below.
In some embodiments, the TLB 330 includes a tag memory 332 and a register file 334. The tag memory 332 receives TLB requests 316 and holds GPAs of the address translation requests that need to be translated along with the Source ID of the requesting I/O device. The register file 334 holds either the valid translation for the GPA in the corresponding entry in the tag memory 332 or intermediate information needed to complete a page walk to load valid translation for the GPA in the corresponding entry in the tag memory 332. If the address translation of a GPA already exists in the TLB 330, the corresponding page-aligned translated address (also referred to as host physical address (HPA)) may be looked up from the register file 334 at a TLB entry associated with the GPA. If the address translation does not exist, but a page walk is already under way to load the needed, translation, the TLB 330 sends a retry response back to the GPA queue. In both the above cases, the TLB 330 does not have to allocate another TLB entry to the address translation request.
On the other hand, if a TLB request results in a miss in the TLB 330, the TLB 330 attempts to allocate a TLB entry to the address translation request. The GPA of the TLB request may be held in the tag memory 332 at a location associated with the TLB entry allocated. Furthermore, a sequence of cache lookups and/or memory reads may be performed to retrieve the address translation of the GPA. The sequence of cache lookups and/or memory reads is also referred to as a page walk. During the page walk, the intermediate page walk states may be held by the TLB entry allocated.
However, the TLB 330 may not be able to allocate a TLB entry to a TLB request under certain circumstances, and a retry response may be sent back to the GPA queue 310 requesting it to retry later. In one embodiment, the TLB 330 cannot allocate TLB entries when all TLB entries are already allocated to prior translation requests. Alternatively, the TLB 330 cannot allocate TLB entries when the TLB 330 is busy with some other operations related to page walks already in progress. This may happen because of limitations in the ability of the TLB memory structures 332 or 334 to handle multiple operations in the same clock. When all TLB entries are already allocated, the TLB 330 asserts a tlb_full signal 322 to indicate so. Likewise, when the TLB 330 is busy with some other operation and cannot service the current translation request, the TLB 330 asserts a tlb_busy signal 324 to indicate so. Both tlb_full signal 322 and tlb_busy signal 324 may be driven to the allocation/de-allocation logic 320.
In some embodiments, the allocation/de-allocation logic 320 manages the allocation and de-allocation of TLB entries in response to tlb_full signal 322, tlb_busy signal 324, top_of_queue signal 314 and tlb_allocate signal 312. Both tlb_allocate signal 312 and top_of_queue signal 314 may be used to qualify address translation requests in the GPA queue 310. The top-of-queue signal 314 may be implemented using a pointer to indicate that a translation request pointed at by the pointer is the critical one for the associated root port to make forward progress. When an address translation request is sent to the TLB 330 with top_of_queue signal 314 asserted, the allocation/de-allocation logic 320 logically opens an allocation window to allow a TLB entry to be allocated to the address translation request. While the allocation window remains open, the TLB 330 may continue to allocate TLB entries as needed to subsequent address translation requests.
In some embodiments, the tlb_allocate signal 312 is a secondary signal to indicate that the root port associated with an address translation request is restarting the root port's translation request pipeline, which has been halted earlier in response to the tlb_busy signal 324. The tlb_allocate signal 312 may further cause the TLB 330 to start allocating TLB entries if possible.
In one embodiment, the allocation/de-allocation logic 320 closes the allocation window when either tlb_full signal 322 or tlb_busy signal 324 is asserted in response to an address translation request from the GPA queue 310. Once the allocation window is closed, any subsequent address translation request that needs allocation of a TLB entry may be forced to retry till the allocation window is reopened. In one embodiment, the allocation/de-allocation logic 320 logically reopens the allocation window when the root port sends another translation request with either top_of_queue signal 314 or tlb_allocate signal 312 asserted.
In some embodiments, translation requests are tagged with unique request identifiers, which may be included in the request identification 318. These identifiers are returned to the GPA queue 310 with the TLB responses 336 as part of the response identification 338. The GPA queue 310 may use these identifiers to appropriately restart the translation request pipeline when it receives the tlb_busy signal 324 along with the address translation response. Using the request identifiers allows for quick restart of the translation request pipeline when the allocation window is closed due to the TLB 330 being busy.
In addition to managing TLB entry allocation, the allocation/de-allocation logic 320 may manage de-allocation of TLB entries as well. In one embodiment, TLB entries are put into the “lock-down” state upon completion of page walks associated with the TLB entries. Entries in the “lock-down” state cannot be de-allocated and hence the translations associated with these TLB entries are guaranteed to be available in the TLB. A de-allocation window is opened when a translation request is received with top_of_queue signal 314 asserted that results in a hit in the TLB 330. The TLB entry hit by the translation request is moved from the “lock-down” state to the Least Recently Used (LRU) realm. Once the TLB entries are in the LRU realm, they may be de-allocated and a timer based pseudo-LRU algorithm may be used to prioritize TLB entries for de-allocation. Successive requests that hit other TLB entries in the lock-down state cause those entries to be moved to the LRU realm as well.
In some embodiments, the de-allocation window is closed when a translation request results in a miss or hits a TLB entry that has not yet completed its page walk. By closing the de-allocation window, TLB entries in the “lock-down” state that result in hits to incoming translation requests continue to remain in the “lock-down” state. Thus, valid translation in the corresponding TLB entry may be protected from being discarded before the earliest address translation request in the GPA queue is serviced. Thus, the de-allocation window helps to prevent thrashing of TLB entries. In one embodiment, the de-allocation window is reopened when a translation request is received with top_of_queue signal 314 asserted.
In one embodiment, processing logic waits for an address translation request from the GPA queue (processing block 210). When processing logic receives an address translation request, it checks if the needed translation already exists in the TLB (processing block 211a). If it does, the translation is sent back to the GPA queue (processing block 211b). If the address translation request hits a TLB entry that still has not completed the needed page walk, the TLB sends a retry response back to the GPA queue (processing block 211c). If the translation request misses the TLB, a new entry needs to be allocated and processing logic checks if allocation window is open (processing block 212). If the allocation window is not open, processing logic checks whether at least one of the signals, top_of_queue (also referred to as tlb_toq) signal or tlb_allocate signal, is asserted (processing block 214). If neither signal is asserted, processing logic sends a retry response to the GPA queue (processing block 216) and transitions back to processing block 210 to wait for another address translation request. On the other hand, if either tlb_toq signal or tlb_allocate signal is asserted, processing logic opens the allocation window (processing block 218) and transitions to processing block 220.
If processing logic determines that the allocation window is open at processing block 212 or processing logic opens the application window at processing block 218, processing logic checks whether the TLB is full (processing block 220). If the TLB is full, processing logic closes the allocation window, sends a retry response to the GPA queue, and asserts the tlb_full signal (processing block 222). Then processing logic transitions back to processing block 210 to wait for another address translation request.
If processing logic determines that the TLB is not full at processing block 220, processing logic checks whether the TLB is busy (processing block 224). If the TLB is busy, processing logic closes the allocation window, sends a retry response to the GPA queue, and asserts the tlb_busy signal (processing block 226). Then processing logic transitions back to processing block 210 to wait for another address translation request. Otherwise, the TLB is neither busy nor full. So processing logic allocates a TLB entry to the address translation request (processing block 228). Then processing logic returns to processing block 210 to wait for another address translation request.
In one embodiment, processing logic waits for an address translation request from the GPA queue (processing block 250). When processing logic receives an address translation request, processing logic checks if a de-allocation window is open (processing block 252). If the de-allocation window is not open, processing logic checks whether the tlb_toq signal is asserted (processing block 254). If tlb_toq signal is not asserted, processing logic returns to processing block 250 to wait for another address translation request. If tlb_toq signal is asserted, processing logic opens the de-allocation window (processing block 256). Then processing logic transitions to processing block 258.
Alternatively, if processing logic determines that the de-allocation window is open in processing block 252, processing logic transitions to processing block 258 to check if there is a hit in the TLB. If there is no hit in the TLB, processing logic closes the de-allocation window (processing block 264) and returns to processing block 250 to wait for another address translation request. If there is a hit in the TLB, processing logic checks whether the TLB entry that hit has completed its page walk, and hence, has a valid translation available (processing block 260).
If the TLB entry hit has completed its page walk, processing logic moves the TLB entry hit from the “lock-down” state into the LRU realm (processing block 262) and returns to processing block 250 to wait for another address translation request. Otherwise, processing logic closes the de-allocation window (processing block 264) and returns to processing block 250 to wait for another address translation request.
In one embodiment, the address translation requests are sent to the TLB 410 in first-in-first-out (FIFO) order. Request A 423a is first sent to the TLB 410 with a signal, top_of_queue signal asserted. Because of the asserted top_of_queue signal, the allocation window is opened. In the current example, suppose the TLB 410 is busy with some other operations when the TLB 410 receives Request A 423a. Because the TLB 410 is busy, the TLB 410 closes the allocation window and sends a response with tlb_busy signal 413 asserted to the GPA queue 420. Likewise, the TLB 410 closes the allocation window and sends a response with tlb_full signal asserted to the GPA queue 420 if the TLB 410 is full when the TLB 410 receives Request A 423a.
In one embodiment, the response from the TLB 410 takes four clock cycles to reach the GPA queue 420. As a result, Request B 423b, Request C 423c, and Request D 423d are sent to the TLB 410 following Request A 423a. However, the TLB 410 does not allocate any entries to Requests B, C, and D 423b-423d because the allocation window has been closed already. Thus, Requests B, C, and D 423b-423d may not be serviced by the TLB 410 before Request A 423a is serviced.
By the time the GPA queue 420 is ready to send Request E to the TLB 410, the response with tlb_busy signal 413 or tlb_full signal asserted reaches the GPA queue 420. In response to tlb_busy signal 413 or tlb_full signal, the GPA queue 420 returns to Request A instead of sending Request E to the TLB 410. The GPA queue 420 may send Request A again with top_of_queue asserted to the TLB 410. In response to top_of_queue signal being asserted in conjunction with a translation request, the allocation window may be reopened. After Request A has been serviced by the TLB 410, the top_of_queue pointer 422 is moved to point to the next request in the GPA queue 420, i.e., Request B. As illustrated in the above example, the allocation window together with the top_of_queue pointer 422 may allow the requests in the GPA queue 420 to be serviced by the TLB 410 in the order the requests are held in the GPA queue 420. Furthermore, over subscription of TLB entries may be avoided because TLB entries are not allocated to incoming address translation requests once the allocation window is closed. This forces TLB entries to be allocated only to the first N translation requests to unique 4K ranges, where N is the number of entries in the TLB, irrespective of the depth of the GPA queue.
In addition to the allocation window, a de-allocation may be used in the DMA remap engine 400. One example of using the de-allocation window is described below with reference to
In one embodiment, Request A 423a with the top_of_queue signal asserted is sent to the TLB 410. In response to the asserted top_of_queue signal, the deallocation window is opened. Suppose Request A 423a results in a miss in the TLB 410, which causes the de-allocation window to be closed. In some embodiments, Entry X 413 in the TLB 410 is allocated to Request A 423a and a page walk is initiated to retrieve the address translation for Request A 423a to be put into Entry X 413. Once the address translation is written into Entry X 413, Entry X 413 is put into the “lock-down” state.
Suppose Request J 423j is sent to the TLB 410 subsequent to Request A 423a and Request J 423j hits the same page as Request A 423a. Thus, Request J 423j results in a hit of Entry X 413 in the TLB 410. However, the de-allocation window has already been closed by the time the TLB 410 receives Request J 423j. Therefore, Entry X 413 may not be moved from the “lock-down” state into the LRU realm to be de-allocated even though Request J 423j results in a hit on Entry X 413. The de-allocation window may be reopened later when the TLB 410 receives another request with the top_of_queue signal asserted. As illustrated in this example, the de-allocation window together with the top_of_queue signal helps to prevent thrashing in the TLB 410 and thus avoids the performance penalty caused by thrashing.
In one embodiment, the DMA remap engine may be shared by multiple root ports within an I/O hub as shown in
In some embodiments, the memory controller 530 is integrated with the I/O hub 540, and the resultant device is referred to as a memory controller hub (MCH) 630 as shown in
Furthermore, the chip with the processor 510 may include only one processor core or multiple processor cores. In some embodiments, the same memory controller 530 may work for all processor cores in the chip. Alternatively, the memory controller 530 may include different portions that may work separately with different processor cores in the chip.
Referring back to
In some embodiments, the I/O hub 540 receives address translation requests from the peripheral I/O devices coupled to the I/O ports 550. In response to the I/O requests, the DMA remap engine within the I/O hub 540 performs address translation using a translation lookaside buffer (TLB), an allocation/de-allocation logic module, and a queuing structure (GPA queue) within the I/O hub 540. Details of some embodiments of the DMA remap engine within the I/O hub 540 and some embodiments of the process to manage allocation and de-allocation of TLB entries have been described above.
Note that any or all of the components and the associated hardware illustrated in
Some portions of the preceding detailed description have been presented in terms of symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the tools used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. 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 kept in mind, 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 above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, 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.
Embodiments of the present invention also relate to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a machine-accessible storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the operations described. The required structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings as described herein.
The foregoing discussion merely describes some exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion, the accompanying drawings and the claims that various modifications can be made without departing from the spirit and scope of the subject matter.
