Hmmm, there always used to be a way to specify address limitations. In WDM the DEVICE_DESCRIPTION.DmaAddressWidth would do this. You could set that to 63, indicating that the MSB was out of range. There is very likely a way to do this through WDF as well. The common buffer allocation has to respect your DMA adapter properties. The WDF_DMA_ENABLER_CONFIG object has an AddressWidthOverride property that would appear to provide this capability. Then again I’ve never tried to do this so I don’t know if it does what it appears to claim to do.
You can set AddressWidthOverride in the WDF_DMA_ENABLER_CONFIG structure to 31.
If you need to work earlier than Windows 8, then the only available options for that fields are 64, 32, and 24, but the newer systems should accept any value.
Just as an aside: NT has always supported device physical memory address restrictions, as ISA could not address anything outside of a 24bit address. And as we know from other discussions here, there are still plenty of NT systems with ISA devices.
I must be missing something, but I thought the problem was that the device can’t properly address memory when performing DMA. If that’s the case, then the only thing that matters is the address from the point of view of the device?
“the only thing that matters is the address from the point of view of the device?”
Yes but bus address == physical address in general, and when it doesn’t that is a HAL problem not a driver problem. As long as the driver goes through the correct procedures, in this case by allocating a common buffer using a correctly configure dma adapter object, the platform guarantees that the ‘bus logical address’ will meet the dma adapter requirements.
All of which brings back memories of when common buffers were all fighting for ‘low memory’.
The situation you’re worried about (which can happen on high-end systems with odd I/O mappings) can be a problem when accessing DEVICE memory addresses, where the bus address is different than the physical address used by the CPU. But when a device needs access to the actual physical memory of the computer, there shouldn’t be any remapping.
In 33 years of PC driver work, I’ve only encountered one system where physical address did not equal bus address, and that was the very, very strange machines that ran Windows NT 3.51 on an Alpha processor. Imagine, if you will, a system where PCI bus addresses had to be shifted left by 3, so consecutive DWORDs were actually separated by 32 bytes. That’s why Alpha support didn’t last very long.
In 33 years of PC driver work, I’ve only encountered one system where physical address did not equal bus address
Yes, historically correct. But “the times, they are a-changing” (I just made that up). IOMMUs are becoming increasingly common… so your Device Bus Logical Address won’t BE your Physical Address for the purposes of DMA.
The times might be a changing (and they are but quite obviously not in a good way) , as long as the driver goes through the documented procedures, the bus logical address is going to meet the device requirements, IOMMU or no IOMMU, and how that happens is a problem only for the HAL.
as long as the driver goes through the documented procedures, the bus logical address is going to meet the device requirements, IOMMU or no
IOMMU, and how that happens is a problem only for the HAL
Absolutely agree.
After 30 years of banging on the table telling people that Device Bus Logical Addresses are not necessarily Physical Addresses, it’s nice to finally have something other than an esoteric example (and a driver verifier mode) that “proves” this.
