BACKGROUND
As processing resources have increased, demands to run multiple software programs and operating systems on a single microprocessor have also increased. To meet these demands virtual environments have been developed to allocate a single computer system's resources to various software application and operating systems. Typically, in a virtual environment, a virtual machine monitor (VMM) program interfaces with one or more software programs, such as a virtual machine (VM) program, and hardware resources available in a computer system. A VM may include guest software, such as an operating system (OS) or other software applications. Usually, to allow multiple VMs to run on a single processor the state information and control information for the VMM and each VM program is stored in memory.
One technique of virtualization ensures security between multiple VMs running on a single platform by assigning each VM an isolated portion of memory, which is also referred to as a domain or container. An illustration of this type of virtualization is shown in FIG. 1a. Virtual machine monitor (VMM) 100 interfaces with VM 110 and VM 115, also referred to as guest software, as well as underlying physical hardware 105. As explained above, VM 110 is assigned to domain 125 and VM 115 is assigned to domain 130 in system memory 120. VMM 100 may also be assigned a domain within system memory 120. In one implementation, accesses from I/O devices 145, 150, 155, and 160 are trapped by VMM 100 to ensure unauthorized accesses by the I/O devices are not made. However, this requires all accesses by I/O devices to be trapped by the VMM, emulated, and then submitted to the underlying physical device hardware 105, which introduces potential delays.
In another implementation, I/O devices 145-160 are assigned or associated with domains or portions of memory by direct memory access (DMA) remapping engine 140, as illustrated in FIG. 1a. DMA remapping engine may be present in chipset 135, which is often distributed among multiple integrated circuits and controller hubs. DMA remapping engine 140 is capable of translating between guest physical addresses, the logical view of an address space from the guest software or device's perspective, and host physical addresses, the actual address space of underlying hardware 105. The term guest physical address is commonly used in an environment utilizing virtualization. However, it is apparent that the term guest physical address is a form of a device virtual address (DVA), where the DVA space is the device's or guest software's view of a physical address space.
I/O device 145 and 150 are mapped/assigned to domain 125, I/O device 155 is assigned to domain 130, and I/O device 160 is assigned to a shared portion of system memory 120. Device drivers 165, 170, 175, and 180 corresponding to I/O devices 145, 150, 155, and 160, respectively, are present in domains assigned to each of the I/O devices. Therefore, each I/O device may potentially access system memory 120 directly without emulation by the VMM 100. DMA remapping is discussed in more detail in co-pending application with Ser. No. 10/956,198 entitled, "Address Translation for Input/Output Devices using Hierarchical Translation Tables."
A typical hierarchal structure of I/O devices 145-160 are shown in FIG. 1b. I/O device 155 and bridge, also referred to as a switch, 185 is locally coupled to chipset 135. I/O device 160 and bridge 190 is locally coupled to bridge 185. Locally coupled to bridge 190 is I/O devices 145 and 150. As noted above, device 145 and device 150 are also assigned to the same domain, domain 125. However, when a memory request or access meant for I/O device 150 is initiated by I/O device 145, the access is typically blindly forwarded upstream towards DMA engine 140. DMA engine 140 translates the address. If the translated address is a peer-to-peer request, as in this example, the access is sent back downstream to the appropriate destination, which is I/O device 150.
Therefore, accesses among peer I/O devices, which may be coupled locally to the same bridge or coupled in the hierarchal structure, are sent all the way upstream and either remapped or trapped by the VMM limiting the potential performance of peer-to-peer accesses.
DETAILED DESCRIPTION
In the following description, numerous specific details are set forth such as specific virtual machines, logic placement, and device hierarchy in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice the present invention. In other instances, well known components or methods, such well-known functional blocks of a computer system, a primary DMA remapping engine, etc., have not been described in detail in order to avoid unnecessarily obscuring the present invention.
A method and apparatus for supporting peer-to-peer I/O device accesses is described herein. As discussed below, the method and apparatus described will be discussed in specific reference to a virtual environment. However, the method and apparatus described herein is not so limited.
FIG. 2 illustrates an embodiment of a computer system that supports peer-to-peer input/output (I/O) device accesses. Computer system 200 may be a single or multiple processor system capable of operating in a virtual machine environment; however, computer system 200 is not so limited.
Turning to FIG. 3a, the operation of bridge 245 and translation logic 280 will be discussed in more detail. Although bridge 245, which includes translation logic 280, is specifically discussed, the following discussion also relates to bridge 230, which includes logic 270 and ICH 200, which includes logic 260. As illustrated in FIG. 3a, bridge 245 has ports 300, 305, and 310 for coupling of I/O devices. In one embodiment, any single or plurality of the ports is/are operable to connect to ICH 220, as well as another bridge or switch. In FIG. 3a, port 300 is coupled to bridge 230, as shown in FIG. 2. Remapping logic 240 comprises upstream logic 315, downstream logic 320, and remapping logic 325.
Microprocessor 205 is coupled to memory controller hub (MCH) 210 through interconnect 207. Interconnect 207 is typically a front-side-bus (FSB). In one embodiment, interconnect 207 is a common standard interface (CSI) bus that implements CSI protocols. MCH 210 interfaces with system memory 215 through memory bus 213. In addition, MCH 210 has primary direct memory access (DMA) remapping engine 212, which will be discussed in more detail below. MCH is coupled to interconnect controller hub (ICH) 220, also referred to as an input/output hub (IOH), through interconnect 214. Often the combination of MCH 210 and ICH 220 is referred to as a chipset.
System memory 215 may be any type of access memory used in a system. In one embodiment, system memory 215 is a random access memory (RAM) device such as a static random access memory (SRAM), a dynamic random access memory (DRAM), a single data rate (SDR) RAM, a double data rate (DDR) RAM, any other multiple data rate RAM, or any other type of access memory.
As illustrated, computer system 200 includes virtual machine monitor (VMM) 201 to interface guest software, also known as a virtual machine (VM) or a virtual machine program, with underlying hardware, such as microprocessor 205 and system memory 215. VMM 201 may be implemented in software, hardware, firmware, or any combination of software, hardware and firmware. As an example, VMM 201 is assigned, not shown, to a portion of system memory 215. VMM 201 usually has a high-level privilege allowing guest software, i.e. virtual machines (VMs), to interface with underlying hardware. As an example, there is a single VMM to interface multiple VMs with hardware. In an alternate implementation, there are a plurality of VMMs organized in any manner. For example, a first VMM interfaces all of the network related VMs, while a second VMM interfaces all of the storage related VMs.
Specifically, FIG. 2 depicts a first virtual machine 202 and a second virtual machine 203. Virtual machines 202 and 203 may be any one of or any combination of the following: an operating system, an operating system specific application, a general application, software routines, a group of related applications, a group of related drivers, related code, or any other program that may be executed on microprocessor 205. As a specific example, VM 202 is a Windows operating system and VM 203 is a Linux operating system. In another embodiment, VM 202 includes all of the input/output (I/O) device drivers for network devices, while VM 203includes all of the I/O device drivers for storage devices.
VMs 202 and 203 are assigned to portions of system memory 215; specifically, domain 216 and domain 217. Typically portions of memory assigned to VMs or VMMs are called domains or containers. Isolation and security between domain 216 and 217 is typically enforced by VMM 201. However, as discussed below, primary DMA remapping engine 212, as well as other hardware and software is also used to ensure security among domains 216 and 217.
Also illustrated in FIG. 2 are I/O devices 225, 235, 240, 250, and 255. An I/O device is usually any device for interfacing or communicating with devices or users external to a computer system, as well as devices, such as switches, bridges, and controller hubs used to couple I/O devices to a computer system. Examples of I/O devices include network interface controllers (NICs), other network devices, audio devices, video controllers, video capture devices, TV tuner devices, mass storage devices, short-term storage devices, other storage devices, serial devices, wireless devices, local peripheral component interconnect (PCI) devices, PCI switches, PCI bridges, peripheral component interconnect express (PCI-X) devices, PCI-X bridges, and PCI-X switches.
A peer-to-peer access includes any access between the aforementioned I/O devices. A few limited examples of types of peer-to-peer accesses include console re-direction (including peer to peer accesses to keyboard and video frame buffers), I/O processing (including peer accesses from I/O processors to adapters such as for RAID acceleration), client usages such as video capture and picture-in-preview (including peer accesses between graphics and video capture devices).
I/O devices 225, 235, 240, 250, and 255, herein referred to as devices 225-255, may be arranged in any manner. In one embodiment, as illustrated in FIG. 2, devices 225-255 are coupled in a hierarchical manner. At the first local level, I/O device 225 and bridge/switch 230 is coupled to ICH 220. At the second local level, I/O device 235, I/O device 240, and Bridge 245 are coupled locally to bridge 230. At the third local level, I/O device 250 and 255 are coupled locally to bridge 245. Devices 225-255 are coupled to a controller hub, such as ICH 220, using a peripheral interconnect bus. In one embodiment, a PCI bus is used to connect devices 225-255 to computer system 200. As another example, a PCI-X bus is used to coupled devices 225-255 to computer system 200.
As used herein, the term upstream, refers to a direction up the hierarchy of connection, i.e. towards a primary remapping engine for translating guest addresses to host addresses for accesses to system memory. As an example, bridge 230 forwarding an access upstream would be forwarding the access to ICH 220, which is at the first level of the hierarchy, in the example above, as well as being between bridge 230 and primary remapping engine 212/system memory 215. Inversely, downstream, as used herein refers to a direction down the hierarchy of coupling, i.e. away from a primary remapping engine/system memory. From the example above, forwarding downstream from bridge 230 would include forwarding an access to bridge 245, which is the third level of hierarchy, as well as a direction away from primary DMA engine 212 and system memory 215.
Every memory location within system memory 215 has an associated physical memory address, also referred to host physical memory address. As guest software or VMs typically view a domain assigned to it as a contiguous address space, guest software logically views a domain's address spaces as a device virtual address (DVA) space, also referred to as a guest physical address (GPA) space. Therefore, the resources assigned or associated with each domain, such as domain 216 and domain 217, may have a different view of physical memory than the system's view of physical memory.
As a simplified example, system memory 215 has host physical addresses (HPAs) 0 to 10,000. In this example, domain 216 includes HPAs 1000 to 2000. However, I/O device 250 and driver 251 assigned to domain 216 logically view domain 216 as having GPAs 0 to 1000. Consequently, when referencing GPA 0, the actually physical memory location has HPA of 1000. In this instance, where a domain's guest physical address space is translated to achieve the host physical address space, the domain is referred to as a relocated domain. However, when a domain's guest physical address space is the same as, or a subset of, the system's host physical address space the domain is referred to as a non-relocated domain. A GPA space or HPA space does not have to be contiguous. As an example, an HPA space includes a plurality of non-contiguous windows logically viewed by guest devices as a contiguous address space.
Primary DMA engine 212, herein referred to as engine 212, illustrated in MCH 210 is capable of logically assigning/mapping I/O devices 225, 235, 240, 250, and 255 to domains in system memory 215. As an example, I/O devices 250 and 255 are mapped to domain 216, I/O devices 225 and 240 are mapped to domain217, and I/O device 235 is mapped to a shared portion of system memory 215. Engine 212 is not limited to being located in MCH 210, and in fact, may be placed anywhere between devices 225-255 and system memory 215.
Engine 212 filters accesses to system memory, as well as includes logic to translate accesses to system memory from the guest physical addresses (GPAs) to host physical addresses (HPAs). To ensure security between the domains, engine 212 may allow accesses from specific devices to access certain ranges/windows of memory, not allowing access to other ranges/windows. Primary DMA engine and translation of system memory accesses from GPAs to HPAs is discussed in more detail in co-pending application with Ser. No. 10/956,198 entitled, "Address Translation for Input/Output Devices using Hierarchical Translation Tables."
Also illustrated is secondary DMA translation logic 260, 270 and 280 in ICH 260, bridge 230, and bridge 245, respectively. Secondary translation logic is also referred to as secondary remapping engine, remapping logic, translation logic, or other variance of logic to remap guest addresses to host addresses. As an example, remapping logic 260 remaps a first address, such as a guest address, referenced by an access received by ICH 220, to a second address, such as a host address, if the first address is within a window or range of addresses associated with I/O device 225. However, if the first address is not within the window of addresses associated with I/O device 225, then the access is forwarded upstream to MCH 210.
Turning to FIG. 3a, the operation of bridge 245 and translation logic 280 will be discussed in more detail. Although bridge 245 and translation logic 280 is specifically discussed, the discussion relates to bridge 230 having logic 270 and ICH 200 having logic 260. As illustrated in FIG. 3a, bridge 245 has ports 300, 305, and310 to couple I/O devices to. In one embodiment, any single or plurality of the ports is/are operable to connect to ICH 220, as well as another bridge or switch. In FIG. 3a, port 300 is coupled to bridge 230, shown in FIG. 2. Remapping logic 240 comprises upstream logic 315, downstream logic 320, and remapping logic325.
In one embodiment, upstream accesses, i.e. accesses generated from an I/O device, such as I/O devices 250 and 255, reference a guest address. Inversely, downstream accesses, i.e. accesses flowing downstream to access an I/O device reference a host address. As one example, an I/O device driver present in system memory and executed on the microprocessor generates a downstream access to access an I/O device, such as I/O device 250. This downstream access either initially references or is translated into a host address.
Downstream logic 320 in bridge 245 associates a range or window of host addresses with each I/O device coupled to bridge 245 through ports 305 and 310. For example, downstream logic 320 may associate host addresses 0 to 500 with device 250 and 501 to 1000 with device 255. Consequently, if a downstream access references host address with a value of 300, then the access is forwarded to device 250 being in the range of 0 to 500. As another more specific example, I/O device 250 is another bridge having 2 devices associated with host addresses 0-500 and 501-1000, respectively, and I/O device 255 is a network interface controller associated with host addresses 1001-1500. Then, downstream logic 320 associates host addresses 0-1000 with port 305, the port bridge 250 is coupled to, and addresses 1001-1500 with port 310, the port network interface controller 255 is coupled to. Downstream logic 320 is not discussed in detail, as it is well-known in the art.
An I/O device, such as device 250 may also generate a memory request/access, which is meant for system memory or a peer I/O device. In prior art implementations described above, since the access references a guest physical address, it is forwarded upstream to a primary DMA remapping engine. Once at the primary DMA remapping engine, the guest address referenced by the access is translated to a host address. If the host address indicates a peer I/O access, the access is forwarded back downstream. This potentially limits I/O device to I/O device transfer rates.
Upstream logic 315 associates a window or range of guest addresses for each I/O device coupled to bridge 245. Therefore, from the example above, if I/O device 205 generates an access referencing a guest physical address, which if translated to the corresponding host physical address, is associated with device 255, then the guest physical address is translated/remapped and forwarded to device 255, without forwarding the access all the way upstream and back down.
In one embodiment, upstream logic 320 comprises at least one register, but potentially a plurality of registers, to store a source identifier (ID) to identify a source of an access, a guest address base to establish a base for an associated window of guest addresses, a size of the associated window of guest addresses, and a base for an associated host address.
For example, device 250 and 255 are local devices to each other being coupled to bridge 245 at the same hierarchal level. Consequently, a context register in upstream logic 320 associates a window or a plurality of ranges of guest addresses associated with device 255, i.e. guest addresses that if translated would be in a range of host addresses that would be forwarded to device 255. The context register stores a source ID to represent device 250, a base guest address to establish the base of the window of guest addresses associated with device 255, a size of the guest window, and the host address base for device 255.
To continue the example with extremely simplified numbers, assume that device 255 is associated with host addresses 1000-1500 and the guest addresses corresponding to those host addresses are 0-500. First, an access generated by device 250 referencing guest address 100 is received on port 305. The source id representing device 250 is matched in a context register in upstream logic 320. The guest window size associated with local device 255 is determined based at least in part on the stored guest base and guest size. In this case, the guest size of 500 is added to a stored base of 0 to establish the guest window of 0-500. Since the referenced guest address is within the window, the guest address in remapping logic 325 is remapped/translated to a host address based at least in part on the stored base host address. Here, the offset of the guest address from the stored guest base, (100-0), is added to the stored host base address of 1000 to establish the host address of 100. Being between the host address 1000-1500 associated with device 255, the access is then forwarded to device 255.
Upstream logic 315 and downstream logic 320 may be written to upon initialization to establish the stored values, such as the source IDs, base address, sizes, and other information. Additionally, both may be written to during execution of a VMM or VM. Moreover, as a new input/output device is connected the stored values may either be dynamically updated at that point or statically updated later upon an event, such as restart, power-on, or some other execution event.
Turning to FIG. 3b, another embodiment of placing logic 280 in bridge 245 is shown. Instead of centralizing the logic 280 in bridge 245, logic 280 may be distributed throughout bridge 245, including within ports 305 and 310. In this embodiment, context logic 350 and 355, discussed above in reference to upstream logic315, are present in ports 305 and 310, respectively. In one embodiment, context logic 350 and 355 comprises a plurality of context registers. As a specific example, context logic 350 and context logic 355 comprises a context register for every port on bridge 245, except for the port the context register is present in. Therefore, if there are N I/O devices or N ports on bridge 245, there are N−1 context registers. In another embodiment, context logic 350 and 355 comprises table logic for storing a table indexed by a source ID.
An example of context register 350's contents is shown in table 360. Table 360 comprises a source ID 365. From the example above, when identifying an access or memory request from device 250, source ID 365 stores a source ID that represents device 250. Table 360 also comprises guest physical address windows/ranges 370, 375, and 380. Context register 350 may store any number of windows or ranges to be associated with another device, such as device 255. In a specific embodiment, context register 350 stores up to six ranges. Each window, such as window 370, stores a guest physical address (GPA) base, such as GPA base 371, guest physical address (GPA) window size, such as GPA size 372, and a host physical address (HPA) base, such as HPA base 373. For example, if device 250 generates an access referencing a GPA, then it is determined if the GPA is within window 370, window 375, or window 380. If the GPA is within window 370, window 375, or window 380, then the GPA is translated to an HPA based at least in part on the GPA, the GPA base address, or the HPA base address. Translation logic or remapping logic may be present in port 350 and 355, distributed between port 350, 355, and other logic within bridge 245, or present in other logic associated with bridge 245.
Above, examples were given of a specific implementation of bridge 245 with accesses received by and generated from I/O devices 250 and 255. However, the apparatus and method described herein are not so limited. In fact, any integrated circuit having an I/O device coupled to it within computer system 200 may implement the apparatus and method described herein. Consequently, to demonstrate a broader implementation another example in reference to FIG. 2 is discussed immediately below. GPAs and HPAs as discussed above and below are extremely simplified examples illustrating different GPAs and HPAs using numerals, such as 1000 or 10,000. However, GPAs and HPAs may be the same values, a subset of values, or differently offsetting values, as well as being represented by binary values, hexadecimal values, logical values, or other values representative of addresses and memory locations.
In this example, referring to FIG. 2, I/O device 240, which is assigned to domain 217, generates an access referencing a guest address, 1400, associated with device 225, which is also assigned to domain 217 but coupled to ICH 220. It is assumed that initialization or other method of storing source IDs, GPA bases, GPA sizes, and HPA bases have been completed. It is further assumed that device 225 is associated with a GPA window of 1000-2000 and a HPA window of 5500-6500, while device 235, 250, and 255 are not associated with GPA window 1000-2000.
Bridge 230 receives the access on port 239. Logic 270 in bridge 230, which may include but is not required to include context registers in port 239 or context table logic, determines the source of the access as device 240, by matching a source ID representing device 240 to a source ID stored in the context logic. A GPA window is determined for values stored in context logic with source ID representing 240. In this example, a guest window for device 235 is determined, which is assumed to be 20,000-21,000 having a GPA base of 20,000 and a GPA window size of 1,000. Optionally, context logic may also include GPA windows for downstream devices, such as device 250 and 255. However, as to not obscure this example, those devices will not be specifically discussed.
Therefore, since the access references GPA 1400, assuming that is not associated with devices 235, 250, and 255, then the access is forwarded upstream to ICH 220. ICH 220 receives the access on port 221 and performs similar functions with logic 260 as logic 280 performed in bridge 230, which include matching the source ID, determining a GPA window based at least in part on a stored GPA base and GPA size. Here, the GPA base is 1000 and the GPA size is 1000, so the GPA window is 1000-2000. GPA 1400 is within the GPA range; therefore, GPA 1400 is translated to an HPA based at least in part on a stored base HPA. Here, the stored HPA base is 5500, representing the base HPA address associated with device 225. An offset of 400 is determined from the offset of GPA 1400 from GPA base of 1000. The offset of 400 is added to the base of 5500 to establish a HPA of 5900. Since this is in the range of HPA's associated with device 225, the access is forwarded/routed to device 225.
As can be seen from this example, the peer-to-peer access between I/O device 240 and 225 is not a "local" access, as device 225 and device 240 are not locally coupled to the same bridge. However, the guest address of 1400 does not have to be routed to primary DMA engine 212, translated, and then routed back downstream to device 225. Rather, the access is able to forward to the peer I/O device.
Additionally, a translation field may be included to indicate when a translation has occurred. For example, when ICH 220, at port 221, translates the guest address, also referred to as a device virtual address, to a host address, the translation field is updated to represent the address has been translated. This allows for logic260 to avoid attempting primary translation on an already translated address. The translation field may be extended to the bridges as well. As an example, if bridge 230 translated the guest address and then forwarded it to port 221, the translation field is used to indicate the translation has already been done and the access/request need only be forwarded to device 225, instead of translated. A translation field may be implemented in numerous different ways. In one embodiment, the translation field is a portion of an address, where the portion has a first value when untranslated and a second value when translated. In another embodiment, the translation field is in a protocol header for used for the peripheral bus.
Furthermore, the logic in a bridge, such as logic 280 in bridge 245 may be enabled and disabled. When enabled, logic 280 performs operations as in the examples and embodiments discussed above. Moreover, when disabled, logic 280 or other logic in bridge 245 may "blindly" forward the access upstream. Therefore, some bridges/switches may have translation logic enabled, while others have translation logic disabled. Or, translation logic in the bridges may be all disabled, as well as all enabled. As an example, logic 280 is enabled and disabled by software. Software, a VMM, or VM enables logic 280 after determining that hardware, such as the I/O devices, are trusted. This allows for the logic to be disabled, by the software, when an I/O device is not trusted to prevent malicious programming to be able to directly access peer I/O devices.
Referring next to FIG. 4, an embodiment of a method for supporting direct memory accesses between I/O devices is illustrated. In block 405, it is determined if an access generated by a first I/O device references a first address within a range of addresses associated with a local I/O device. In one embodiment, as discussed above, a range of addresses associated with a local I/O device includes determining the range of addresses associated with the local I/O device by adding a stored size to a stored base address associated with the local I/O device. As a specific example, the first address is a guest physical address (GPA) and the stored base address references a stored base GPA. As described above, the bounds of the range/window may be obtained by adding the GPA size to the GPA base.
Next, if the first address is within the range of addresses associated with the local I/O device, then in block 410, the access is forwarded to the local I/O device. As an example forwarding includes translating the first address to a second address based at least in part on a base address. Specifically, an offset of a GPA from a stored base GPA is taken. The offset is added to a stored base HPA to establish the translated HPA.
However, if the first address is not within the range of addresses associated with the local I/O device, then in block 415, the access is forwarded upstream toward primary translation logic, also referred to as a primary DMA remapping engine, which may be in a chipset or between I/O devices and system memory. Furthermore, if the GPA does not reference an addresses associated with any peer I/O device, but rather, is meant to access system memory, then when the primary translation logic receives the access, the GPA is translated to an HPA to access system memory. Additionally, if the GPA is an invalid GPA, then the it may be filtered by the primary translation logic.
Turning to FIG. 5, another embodiment of a method for supporting direct memory accesses between peer I/O devices is illustrated. In block 505, it is determined if a first address referenced by a memory request is within a window of addresses associated with a first I/O device of a plurality of I/O devices coupled to a switch, the switch operable to be coupled in a peripheral bus hierarchy. As discussed above the peripheral bus may be a PCI, PCI-X, or other bus for connecting input/output devices, such as a universal serial bus (USB), a serial ATA bus, or a common standard interface (CSI) bus.
Next, in block 510 if the first address is within the range of addresses associated with the first I/O device, the first address is translated to a second address based at least in part on a base address associated with the first I/O device. However, in block 515, if the first address is not within the range of addresses associated with the first I/O device, then the memory request is forwarded upstream. From the discussion above, the same determination of whether a GPA is within a window of GPA's associated with a first I/O device may be used, as well as the same translation methods.
In addition, for all of the apparatuses and methods described herein, translation is not limited to a barebones offset translation. A hierarchal translation or other commonly used translation method for translating between virtual memory addresses and physical memory addresses or guest addresses and host addresses may be used.
As can be seen from above, the apparatus and method described for supporting peer-to-peer direct memory accesses potentially increase the speed at which peer-to-peer transfers occur. Instead of blindly forward upstream all accesses, as in the prior art, which may result in deadlock and long access times, because of the full upstream and downstream routing, a peer-to-peer access is enabled.