What's the difference between the bus-relative address and device(logic) address?

I am reading WDK documentation. The following two topics confused me:
1st, Map Registers
2nd, Mapping Bus-Relative Addresses to Virtual Addresses

In the first topic, it refers to physical addresses, virtual addresses and device(logical addresses), and in the second topic, it refers to bus-relative addresses. I do understand the physical addresses and virtual addresses, and i think the bus-relative addresses has the same meaning as the device(logical) addresses in the two topics, isn’t it?

For devices are always attached to the system board through certain bus, from device point of view, the addresses it access or be accessed are always bus-relative addresses, but the WDK use two different expressions in two topics make me confirm that they are two different addresses(after all, the documentation is not a novel, it should express the meanings accurately and does not change the expression for the same object without notation)

Thanks in advance.

> I do understand the physical addresses and virtual addresses, and i think the bus-relative

addresses has the same meaning as the device(logical) addresses in the two topics, isn’t it?

You should not be really bothered about it - bus-relative address applies only to the architectures that support MMU. However, x86 and x86_64 are not among them. Therefore, bus address == physical address on x86…

Anton Bassov

I have to correct this post on several things. First MMU nomally means
memory management unit, which the x86 and amd64 architectures certainly
support. The common terms for what Anton is referring to is IOMMU or
hardware map registers, which have been implemented on x86 platforms
including Windows in the past, and hardware wise can be done now. Of
course they had problems mainly with drivers where people assumed “bus
address == physical address” or that map registers were only a software
concept.

To answer the OP’s question, for most machines bus address == physical
address but it is possible to have mapping in hardware to make the bus
address different than the physical address. In these cases you can have a
contigous address range on the bus that maps into a bunch of physical pages,
none of which have the same address as the bus address. This is why you
need to deal with them seperately and use the bus address for programming
the hardware device, since it may be behind an IOMMU.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
>> I do understand the physical addresses and virtual addresses, and i think
>> the bus-relative
>> addresses has the same meaning as the device(logical) addresses in the
>> two topics, isn’t it?
>
> You should not be really bothered about it - bus-relative address applies
> only to the architectures that support MMU. However, x86 and x86_64 are
> not among them. Therefore, bus address == physical address on x86…
>
>
> Anton Bassov
>

As an example of what Don is saying, imagine a large system with two root PCI buses exposed by the chipset. In this system, when memory accesses happen on the CPU to the range 4GB-8GB, they are passed by the chipset to PCI bus 0. When memory accesses happen on the CPU to the range 8GB-12GB, they are passed by the chipset to PCI bus 1. However, the chipset converts these accesses so that on the PCI bus they always appear in the range 0-4GB, in both cases. So you could have two devices with a BAR at address 2GB, since they are on different buses, and since they can be accessed with two different CPU-relative addresses (6GB and 10GB for PCI bus 0 and 1, respectively).

In this example, the 0-4GB addresses that appear on the PCI bus to access device registers are bus-relative addresses, and the 4-8GB and 8-12GB addresses that are used at the CPU to access those same registers are system-relative, or translated addresses.

This sort of thing can happen if there is an IOMMU like Intel and AMD are building, but can also happen with custom chipset support. I’ve seen this used on some large server systems.

Dave

Don Burn wrote:
->To answer the OP’s question, for most machines bus address == physical address but it is possible to have mapping in hardware to make the bus address different than the physical address.

Can i understand the above like this:in the machines that only use pci bus as the system bus, because from pci device point of view,the address space is 4GBytes or more, it can be the same as x86(or ppc) CPU’s addressable physical address space, meanwhile, the addresses of the memory in pci device internal can be located in anywhere of the 4Gbytes space, in this case, bus address(pci bus)= physical address. In the board that has ISA bus, from ISA device point of view, the address space is 16 MBytes, while x86 or ppc may has 4Gbytes address space, thus, the hardware designer may let certain16MBytes(maybe 32M-48MBytes) address space of the CPU decode to the ISA device’s 16MBytes address space, in this case, from CPU point of view,it access memory address between 32Mbytes and 48Mbytes while in the device point of view, it is been accessed in its 0-16MBytes address space, thus, the device address or bus-relative address 0-16Mbytes(i consider they are the same with each other) not equal to the physical address 32-48Mbytes(cpu addressable space)?

No, there have been ISA bus controllers that have mappings so that devices
that did not support scatter/gather DMA (i.e. one transfer to N random
pages) could perform better. The wise developer assumes that he may have a
unique bus address versus a physical address.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
Don Burn wrote:
->To answer the OP’s question, for most machines bus address == physical
address but it is possible to have mapping in hardware to make the bus
address different than the physical address.

Can i understand the above like this:in the machines that only use pci bus
as the system bus, because from pci device point of view,the address space
is 4GBytes or more, it can be the same as x86(or ppc) CPU’s addressable
physical address space, meanwhile, the addresses of the memory in pci device
internal can be located in anywhere of the 4Gbytes space, in this case, bus
address(pci bus)= physical address. In the board that has ISA bus, from ISA
device point of view, the address space is 16 MBytes, while x86 or ppc may
has 4Gbytes address space, thus, the hardware designer may let
certain16MBytes(maybe 32M-48MBytes) address space of the CPU decode to the
ISA device’s 16MBytes address space, in this case, from CPU point of view,it
access memory address between 32Mbytes and 48Mbytes while in the device
point of view, it is been accessed in its 0-16MBytes address space, thus,
the device address or bus-relative address 0-16Mbytes(i consider they are
the same with each other) not equal to the physical address 32-48Mbytes(cpu
addressable space)?

From Davis, for bus-relative address(or device address according to WDK), it is maybe first translated(or decoded) by the chipset to the system address(also called cpu addressable address?) ,then the translated (decoded) address is supplied in the IRP_MN_START_DEVICE, then driver must map them to virtual address to access the device memory, am i right?
Further more, when driver receives IRP_MN_START_DEVICE, OS supplies AllocatedResources and AllocatedResourcesTranslated, somebody may call the former raw resource, and the later translated resource, for memory resource, here, what’s the raw resource means? Is it the device address(also called bus-relative address mentioned above) or other things?

thanks

You are confused it has nothing to do with START_DEVICE! Bus addresses are
for DMA, this is the address you feed the device to perform DMA, as was
stated many times this is the same as the physical address, but you cannot
rely on this.

I strongly recommend you take an OSR class on drivers. Years ago they had
the best set of slides explaining this I have ever encountered.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> From Davis, for bus-relative address(or device address according to WDK),
> it is maybe first translated(or decoded) by the chipset to the system
> address(also called cpu addressable address?) ,then the translated
> (decoded) address is supplied in the IRP_MN_START_DEVICE, then driver must
> map them to virtual address to access the device memory, am i right?
> Further more, when driver receives IRP_MN_START_DEVICE, OS supplies
> AllocatedResources and AllocatedResourcesTranslated, somebody may call the
> former raw resource, and the later translated resource, for memory
> resource, here, what’s the raw resource means? Is it the device
> address(also called bus-relative address mentioned above) or other things?
>
> thanks
>

Don,

The common terms for what Anton is referring to is IOMMU or hardware map registers,
which have been implemented on x86 platforms including Windows in the past,

Am I wrong that this is just a legacy from the times when Windows was meant to run on various hardware platforms, including the ones with IOMMU support ?

Anton Bassov

YOU ARE VERY WRONG. I know of current architectures that are looking at
this now.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Don,
>
>> The common terms for what Anton is referring to is IOMMU or hardware map
>> registers,
>> which have been implemented on x86 platforms including Windows in the
>> past,
>
> Am I wrong that this is just a legacy from the times when Windows was
> meant to run on various hardware platforms, including the ones with IOMMU
> support ?
>
> Anton Bassov
>
>

xxxxx@gmail.com wrote:

From Davis, for bus-relative address(or device address according to WDK), it is maybe first translated(or decoded) by the chipset to the system address(also called cpu addressable address?) ,then the translated (decoded) address is supplied in the IRP_MN_START_DEVICE, then driver must map them to virtual address to access the device memory, am i right?
Further more, when driver receives IRP_MN_START_DEVICE, OS supplies AllocatedResources and AllocatedResourcesTranslated, somebody may call the former raw resource, and the later translated resource, for memory resource, here, what’s the raw resource means? Is it the device address(also called bus-relative address mentioned above) or other things?

In addtion to Mr. Burn’s reply: Please see WDK docum on
AllocateCommonBuffer:

So, the “Logical address” returned by this function, can be not same as
physical address returned by MmGetPhysicalAddress for same virtual
address. And this is exactly the bus-relative address you program into
device’s DMA registers.

–PA

> I know of current architectures that are looking at this now.

Do you mean that they are thinking about introducing IOMMU support to x86_64, as Davis’s post suggests?

Anton Bassov

xxxxx@hotmail.com wrote:

Don,

> The common terms for what Anton is referring to is IOMMU or hardware map registers,
> which have been implemented on x86 platforms including Windows in the past,
>

Am I wrong that this is just a legacy from the times when Windows was meant to run on various hardware platforms, including the ones with IOMMU support ?

I wouldn’t put it that way. The distinction was designed in because the
designers knew there were hardware platforms like this, and as I/O
systems increase in complexity, the odds are good there will need to be
systems like this in the future.

Several of the Alpha systems that ran NT 3.51 and NT 4.0 used serious
dark magic to translate a physical address to a bus-ready address.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yes, mainly for reliability and backwards compatible device support.
Reliability in that they limit the addresses a device can DMA to, and
backwards compatibility for devices that don’t know about more than 4GB.
On a similar note, I have not really looked at hypervisor implementations
enough, but both AMD and Intel are putting in IOMMU like capabilites in the
hardware to both limit the addresses a device can access and map the DMA.
Whether these get exposed in a way relavent to this discussion I don’t know.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
>> I know of current architectures that are looking at this now.
>
> Do you mean that they are thinking about introducing IOMMU support to
> x86_64, as Davis’s post suggests?
>
> Anton Bassov
>

It would much easier to explain F2F with whiteboard and expo. I’ll try…

Physical addresses get asserted to Front Side Bus (FSB). If the target of a transaction is memory, physical addresses are routed to the memory module/bank through the Memory Controller (MC). If the target is device and the address is valid/assigned, the North bridge(NB) or PCIe Root Complex (RC) will claim it and routes to its destination. You can see the activity with an very expensive FSB analyzer on the cpu leads and a bus analyzer on the device side. Only one company I’ve worked for in my 10+ years career as driver programmer can afford such luxury toys – FSB analyzers. They rocks, you’ll learn more than you want to.

Logical Addresses (MSFT terms) are asserted by devices when they act as master agent in a transaction. As a numerical example: let’s say a device wants to do DMA_READ (Mrd in PCI term) from main memory location at 0xdeadbeef (which is the physical address), or in plain English “hey chipset, give me something from memory 0xdeadbeef.”

On systems where physical addr==logical addr, the device will assert 0xdeadbeef on its bus address pins. If you hook up a logic analyzer between the device and bus, you see exactly 0xdeafbeef on the address pins.

On systems where physical addr!=logical addr, there is some sort of address mapping unit (mapped register) that maps the addresses asserted by the device from downstream to system bus signals upstream towards the chipset. The mapping is programmable. For instance, the “mapper” is programmed to map device asserted address 0x123456 to 0xdeadbeef upstream. The mapper will asserts 0xdeadbeef to the chipset upon decoding 0x123456 from the device. The 0xdeadbeef (asserted by the mapper) will eventually get asserted to the memory bank. In this case, 0x123456 is “logical address” and 0xdeadbeef is “physical address”. Or put it simple, in order for the device to access physical memory at location 0xdeadbeef, the device asserts 0x123456 instead. The os has the knowledge of the mapping. In this example, given a physical address of 0xdeadbeef, MapTransfer and buildsgl will give you 0x123456 which your device can assert to address the target physical address. That’s one of several other reasons why we are warned not to use physical address to do DMA.

Again, this is very obvious if you hook up a logic analyzer and/or scope on your device. I used to watch those pins to check signal integrity (raising edge, falling edge, overshoot, rippling, ringing etc) on daily basis. I observed and confirmed the bits and nuts many times to enforce my understanding of what address is what and it became my second nature. Although with PCIe, we don’t see a/d pins but differential pairs being fed to the PCIe PHY, SEDES combo which one can’t decode them directly in time-domain with a scope, but the idea doesn’t change.

I did see ancient NT systems on DEC Alpha where logical!=physical many years ago.

The idea of IOMMU is similar to GART on a modern graphics chips or agp bridges which is another interesting beast. I would coin it “Generic GART”. I thought of building one myself with FPGA to handle zero-copy on receive path without needing L4 offload long before IOMMU was announced-:frowning: Wouldn’t just keep dreaming next time.


Calvin Guan
NetXtreme II 10Gbps Converged NIC
Broadcom Corporation
Connecting Everything(r)

wrote in message news:xxxxx@ntdev…
>I am reading WDK documentation. The following two topics confused me:
> 1st, Map Registers
> 2nd, Mapping Bus-Relative Addresses to Virtual Addresses
>
> In the first topic, it refers to physical addresses, virtual addresses and device(logical addresses), and in the second topic, it refers to bus-relative addresses. I do understand the physical addresses and virtual addresses, and i think the bus-relative addresses has the same meaning as the device(logical) addresses in the two topics, isn’t it?
>
> For devices are always attached to the system board through certain bus, from device point of view, the addresses it access or be accessed are always bus-relative addresses, but the WDK use two different expressions in two topics make me confirm that they are two different addresses(after all, the documentation is not a novel, it should express the meanings accurately and does not change the expression for the same object without notation)
>
> Thanks in advance.
>

Guan, i highly agree with you. Your explanation is very right i think. In your example, when the device wants the main memory location at 0xdeadbeef, according to system architecture, on some system, it will assert 0xdeadbeef on its bus address pins(which physical addr = logical addr), and one some system architecture(physical addr!=logical addr), the device may assert 0x123456 on its bus address pins.
In a word, the address that the device asserts on its bus address pins is the logical address(also called bus address) in MSFT term, while the physical addresses get asserted to Front Side Bus (FSB) is the physical address in MSFT term, am i right? Hope anyone wrote the WDK document will assure this.

Continue with the last post, when the driver want to read or write the device registers or data buffer(not using dma) in the device internal, suppose the register or data buffer that the driver want to access needs the chipset(e.g host to pci bridge) asserts 0x123456 address pins on the device address bus. Again, there may two cases(in my opinion), on systems that physical addr = logical addr, physical address gets asserted to FSB is 0x123456 to get the registers or the data buffer in the device internal, on the systems that physical addr != logical addr, the physical address gets asserted to FSB may be 0xdaffcded to get the register or data buffer in the device internal.
Then i get the next question: in the example i mentioned, when driver received IRP_MN_START_DEVICE, it got the raw and translated resource to access the device, the address 0x123456 will be supplied to the raw resource or the 0xdaffcded will be supplied as the raw resource in the system that physical addr != logical addr?

Hi,Calvin
Very exciting to see your reply. I am looking forwards to hear from you again and hope this will not bother you.
It seems that you have good experience on hardware. I have two questions need your help to understand them.
1st, in your reply, you mentioned on some system physical addr != logical addr, while on some physical addr = logic addr, what’s the difference between the two types of the system?? CPU??chipset, bus type(ISA or PCI, i used to hear that in PCI bus system, logic addr = physical addr) or other factors determine whether the physical addr = or != logical addr?
2nd, as a driver writer, you know that a device(either ISA or PCI device) may has io port and internal memory, and if the driver want to access the port or memory in the device internal, it must save the resource which it use to access the device port and internal memory when it receives IRP_MN_START_DEVICE(DMA is another way to accesss the device internal memory). Just for example, if the driver want to access one memory unit in the device internal for which 0x123456 need to be asserted on device bus pins, on the system that physical addr != logical addr, physical addr 0xdeafbeef may be asserted on FSB. If there really has a example like this, when the driver received IRP_MN_START_DEVICE, the AllocatedResources(also call raw resource) member of the Parameters.StartDevice of the irpstack means what? Here, in above example, 0x123456 should be the AllocatedResources or 0xdeafbeef should be that supplied by the system?

??2008-09-12??xxxxx@yahoo.ca wrote??

It would much easier to explain F2F with whiteboard and expo. I’ll try…

Physical addresses get asserted to Front Side Bus (FSB). If the target of a transaction is memory, physical addresses are routed to the memory module/bank through the Memory Controller (MC). If the target is device and the address is valid/assigned, the North bridge(NB) or PCIe Root Complex (RC) will claim it and routes to its destination. You can see the activity with an very expensive FSB analyzer on the cpu leads and a bus analyzer on the device side. Only one company I’ve worked for in my 10+ years career as driver programmer can afford such luxury toys – FSB analyzers. They rocks, you’ll learn more than you want to.

Logical Addresses (MSFT terms) are asserted by devices when they act as master agent in a transaction. As a numerical example: let’s say a device wants to do DMA_READ (Mrd in PCI term) from main memory location at 0xdeadbeef (which is the physical address), or in plain English “hey chipset, give me something from memory 0xdeadbeef.”

On systems where physical addr==logical addr, the device will assert 0xdeadbeef on its bus address pins. If you hook up a logic analyzer between the device and bus, you see exactly 0xdeafbeef on the address pins.

On systems where physical addr!=logical addr, there is some sort of address mapping unit (mapped register) that maps the addresses asserted by the device from downstream to system bus signals upstream towards the chipset. The mapping is programmable. For instance, the “mapper” is programmed to map device asserted address 0x123456 to 0xdeadbeef upstream. The mapper will asserts 0xdeadbeef to the chipset upon decoding 0x123456 from the device. The 0xdeadbeef (asserted by the mapper) will eventually get asserted to the memory bank. In this case, 0x123456 is “logical address” and 0xdeadbeef is “physical address”. Or put it simple, in order for the device to access physical memory at location 0xdeadbeef, the device asserts 0x123456 instead. The os has the knowledge of the mapping. In this example, given a physical address of 0xdeadbeef, MapTransfer and buildsgl will give you 0x123456 which your device can assert to address the target physical address. That’s one of several other reasons why we are warned not to use physical address to do DMA.

Again, this is very obvious if you hook up a logic analyzer and/or scope on your device. I used to watch those pins to check signal integrity (raising edge, falling edge, overshoot, rippling, ringing etc) on daily basis. I observed and confirmed the bits and nuts many times to enforce my understanding of what address is what and it became my second nature. Although with PCIe, we don’t see a/d pins but differential pairs being fed to the PCIe PHY, SEDES combo which one can’t decode them directly in time-domain with a scope, but the idea doesn’t change.

I did see ancient NT systems on DEC Alpha where logical!=physical many years ago.

The idea of IOMMU is similar to GART on a modern graphics chips or agp bridges which is another interesting beast. I would coin it “Generic GART”. I thought of building one myself with FPGA to handle zero-copy on receive path without needing L4 offload long before IOMMU was announced-:frowning: Wouldn’t just keep dreaming next time.


Calvin Guan
NetXtreme II 10Gbps Converged NIC
Broadcom Corporation
Connecting Everything(r)

As was stated multiple times here, your driver really shouldn’t care if
physical addr and logical addr are the same or not.
Also, this whole discussion is about bus-master DMA, i.e. when the
memory access is initiated by a PCI device.
Don’t confuse it with target access, when the host initiates the access.

As a driver writer, you create DMA’able buffers in the host memory using
DMA_ADAPTER::xxx calls
like DMA_ADAPTER::AllocateCommonBuffer().
The driver should not attempt to figure out if RAM address and DMA
address are the same or not (physical addr VS logical addr
in your terminology).
Just rely on DMA_ADAPTER callbacks, they are ok, you can be sure of that.

As for target access, you get all the PCI memory resources in
IRP_MN_START_DEVICE.
At this point you should map PCI memory to kernel virtual addresses,
then you access the PCI memory via the kernel virtual addresses. Though
you can simply dereference a pointer, it’s a better practice to use
WRITE_REGISTER_ULONG,
READ_REGISTER_ULONG and the like.

Alexey

activism wrote:

Hi,Calvin
Very exciting to see your reply. I am looking forwards to hear from
you again and hope this will not bother you.
It seems that you have good experience on hardware. I have two
questions need your help to understand them.
1st, in your reply, you mentioned on some system physical addr !=
logical addr, while on some physical addr = logic addr, what’s the
difference between the two types of the system?? CPU??chipset, bus
type(ISA or PCI, i used to hear that in PCI bus system, logic addr =
physical addr) or other factors determine whether the physical addr =
or != logical addr?
2nd, as a driver writer, you know that a device(either ISA or PCI
device) may has io port and internal memory, and if the driver want to
access the port or memory in the device internal, it must save the
resource which it use to access the device port and internal memory
when it receives IRP_MN_START_DEVICE(DMA is another way to accesss the
device internal memory). Just for example, if the driver want to
access one memory unit in the device internal for which 0x123456 need
to be asserted on device bus pins, on the system that physical addr !=
logical addr, physical addr 0xdeafbeef may be asserted on FSB. If
there really has a example like this, when the driver received
IRP_MN_START_DEVICE, the AllocatedResources(also call raw resource)
member of the Parameters.StartDevice of the irpstack means what? Here,
in above example, 0x123456 should be the AllocatedResources or
0xdeafbeef should be that supplied by the system?

??2008-09-12??xxxxx@yahoo.ca wrote??
>It would much easier to explain F2F with whiteboard and expo. I’ll try…
>
>Physical addresses get asserted to Front Side Bus (FSB). If the target of a transaction is memory, physical addresses are routed to the memory module/bank through the Memory Controller (MC). If the target is device and the address is valid/assigned, the North bridge(NB) or PCIe Root Complex (RC) will claim it and routes to its destination. You can see the activity with an very expensive FSB analyzer on the cpu leads and a bus analyzer on the device side. Only one company I’ve worked for in my 10+ years career as driver programmer can afford such luxury toys – FSB analyzers. They rocks, you’ll learn more than you want to.
>
>Logical Addresses (MSFT terms) are asserted by devices when they act as master agent in a transaction. As a numerical example: let’s say a device wants to do DMA_READ (Mrd in PCI term) from main memory location at 0xdeadbeef (which is the physical address), or in plain English “hey chipset, give me something from memory 0xdeadbeef.”
>
>On systems where physical addr==logical addr, the device will assert 0xdeadbeef on its bus address pins. If you hook up a logic analyzer between the device and bus, you see exactly 0xdeafbeef on the address pins.
>
>On systems where physical addr!=logical addr, there is some sort of address mapping unit (mapped register) that maps the addresses asserted by the device from downstream to system bus signals upstream towards the chipset. The mapping is programmable. For instance, the “mapper” is programmed to map device asserted address 0x123456 to 0xdeadbeef upstream. The mapper will asserts 0xdeadbeef to the chipset upon decoding 0x123456 from the device. The 0xdeadbeef (asserted by the mapper) will eventually get asserted to the memory bank. In this case, 0x123456 is “logical address” and 0xdeadbeef is “physical address”. Or put it simple, in order for the device to access physical memory at location 0xdeadbeef, the device asserts 0x123456 instead. The os has the knowledge of the mapping. In this example, given a physical address of 0xdeadbeef, MapTransfer and buildsgl will give you 0x123456 which your device can assert to address the target physical address. That’s one of several other reasons why we are warned not to use physical address to do DMA.
>
>Again, this is very obvious if you hook up a logic analyzer and/or scope on your device. I used to watch those pins to check signal integrity (raising edge, falling edge, overshoot, rippling, ringing etc) on daily basis. I observed and confirmed the bits and nuts many times to enforce my understanding of what address is what and it became my second nature. Although with PCIe, we don’t see a/d pins but differential pairs being fed to the PCIe PHY, SEDES combo which one can’t decode them directly in time-domain with a scope, but the idea doesn’t change.
>
>
>I did see ancient NT systems on DEC Alpha where logical!=physical many years ago.
>
>The idea of IOMMU is similar to GART on a modern graphics chips or agp bridges which is another interesting beast. I would coin it “Generic GART”. I thought of building one myself with FPGA to handle zero-copy on receive path without needing L4 offload long before IOMMU was announced-:frowning: Wouldn’t just keep dreaming next time.
>
>–
>Calvin Guan
>NetXtreme II 10Gbps Converged NIC
>Broadcom Corporation
>Connecting Everything(r)
>
>
>


[???] ???ض???ߣ??Ϸ??ϴ???“???ַ?”???Ϸ?չ??
http: — NTDEV is
> sponsored by OSR For our schedule of WDF, WDM, debugging and other
> seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</http:>