Hi Peter,
Sorry I missed your first posting and thank you very much for clarifying things up.
Using the host controller to do DMA over USB is exactly what I meant and wanted. Unfortunately the words “DMA over USB” was not used correctly. So the final question (I promise) is that does KMDF support using host controller to do DMA over USB? is there some sample code I can use as reference?
Anyway, I like your book of “Windows NT device driver development”.
Thanks a lot!
Best regards,
John
The host controller driver below your kmdf driver takes care of the DMA. You communicate with that driver, telling it what to do, by sending URBs down the stack. Kmdf helps you send URBs.
d
Bent from my phone
From: xxxxx@yahoo.commailto:xxxxx
Sent: ?5/?31/?2013 9:22 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] DMA over USB
Hi Peter,
Sorry I missed your first posting and thank you very much for clarifying things up.
Using the host controller to do DMA over USB is exactly what I meant and wanted. Unfortunately the words “DMA over USB” was not used correctly. So the final question (I promise) is that does KMDF support using host controller to do DMA over USB? is there some sample code I can use as reference?
Anyway, I like your book of “Windows NT device driver development”.
Thanks a lot!
Best regards,
John
—
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
Forget the acronym “DMA”. It has nothing at all to do with USB. True, a
DMA root hub interface chip MIGHT use DMA to transfer a USB packet into
computer memory, but please, please understand: How a USB root hub
controller works is none of your business. It is handled by te USB
minidriver, which is AT LEAST two kevels below you! You cannot access it,
modify its behavior in any way, or in general, even discover if it uses
DMA or not. Simple: DMA is not your concern. Your snipe hunt in the URB
structure for a nonexistent bit says that you have not been paying
attention to anything we’ve been telling you. The creator of a URB cannot
control how the USB root hub controller is implemented, not even USBD, the
USB Class driver, has a clue.
You cannot do this. Trying to do it is wasting your time, and ours.
joe
Hi Peter,
Sorry I missed your first posting and thank you very much for
clarifying things up.
Using the host controller to do DMA over USB is exactly what I meant
and wanted. Unfortunately the words “DMA over USB” was not used
correctly. So the final question (I promise) is that does KMDF support
using host controller to do DMA over USB? is there some sample code I
can use as reference?
Anyway, I like your book of “Windows NT device driver development”.Thanks a lot!
Best regards,John
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> For the KMDF driver’s DMA part, DMA over USB and DMA over PCI should be similar
Surely not so. Looks like you don’t understand what is USB and PCI.
PCI is an onboard bus. The DMA-capable PCI device can really address the RAM directly (provided the arbitration phases are done OK) at device’s own will.
The memory controller (slave-only FSB-connected device) just can be a slave of both the CPU and the root PCI-to-FSB bridge. This usually requires only some trivial amount of software setup, usually done once by the BIOS at boot.
With PCIe, the things are the same, just the wiring between device<->PCI-to-FSB bridge (called “root complex” for PCIe) is serial and not parallel.
The new hardware (especially the one emulated for guests by hypervisors) also contains the device called IOMMU, which is an address translator between the DMAing PCI device and the memory controller, requiring some software setup on each transaction (not once at boot).
The IOMMU is managed by the OS transparently to the device driver - the driver just should use the OS’s DMA APIs properly.
Now about USB. First of all, USB is a polled bus. The device is always a slave, it cannot do any activities by its own.
Second, the USB transactions are more conceptually like TCP socket operations then like RAM addressing. There is no 1-to-1 mapping of USB to RAM.
Third, USB requires the rather complex host controller, which is a USB<->PCI bridge, and a complex device driver for it. Lots of software setup for each transaction.
Thus the very question of “USB DMA” is funny. USB host controller is yes, a PCI device, and does PCI DMA a lot, but all of this is hidden from the USB device and its driver. The USB protocol just has no notion of addressable memory, only about packets, pipes and transactions. USB is a protocol-based bus.
There is (was? is it still alive after death of MiniDV and with USB3-attached external hard drives?) also an interesting bus called 1394. It is a serial external protocol-based bus like USB, but… its protocol is much more complex and has the notion of addressable memory. Actually, any async 1394 transaction is a memory access to some addresses - read/write 32bit words, read/write blocks of memory and also interlocked operations on 32bit words.
This means that, with the most trivial software setup of the 1394 controller done once at boot, the 1394-connected device can really do DMA over the host’s RAM. In fact, the 1394 controller does this, but in this mode it just transparently maps the incoming 1394 transactions to PCI ones.
This mode is used by kernel debuggers (Windows for sure, and not only Windows I think), since it allows the debugger to read/write to the target memory without using any code running on a target CPU.
This also opens lots of security issues 
(plug in a special 1394 device and save the snapshot of the host’s memory to it for later analyzis) but IIRC they were dealt with.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> I have used “DMA over PCIe” for Windows. Both PCIe and USB use “packets” (not “wired”) to do
communication, so if we can do “DMA over PCIe”, we should be able to do “DMA over USB”, is this
correct?
No.
Even though you’re correct in this amount of conceptual similarity of PCIe and USB, there are major differences.
PCIe packets/transactions do have the concept of addressable memory, while USB ones do not.
Also, PCIe packets/transactions are executed by the PCIe root complex which requires minimal amount of software setup done by the BIOS at boot. Later, the PCIe is just transparent for the code.
USB, unlike PCIe, requires you to call complex code in the USB driver stack for each transaction.
Except that PCIe can use MSI interrupts, but there is no similar thing for USB.
There is a similar thing for USB called “interrupt pipes”
Nevertheless, again you cannot do an interrupt message to some CPU or to assert some IRQ line from the USB device. You can only complete the pending read done by the host software, and, at read completion, the software can do some stuff just like in the DpcForIsr. The name “interrupt” for USB is only about latency guarantee and nothing else. It is just a read from device to host.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> Examples of protocol-based buses are USB, SCSI, SATA, 1395, etc.
Even though 1394 is a protocol-based bus, its protocol (at least the async one, the isoch one is more complex) is just like the memory access protocol of PCIe - read/write 32bit word, read/write a block of 32bit words, and interlocked compare/swap and fetch/add (and some more similar stuff) on a 32bit word.
So, with a trivial amount of HC setup done once and forever, the HC becomes the 1394<->PCI bridge and yes, after this, the external 1394 device can do DMA over the host’s RAM.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> If you could give me a brief explanation about why we can do “DMA over PCIe” but we can’t do
“DMA over USB”, it would be really helpful.
If this thread is not enough for you, read a bit of the USB spec. Version 1.0 is enough, and only the conceptual part of it - what is endpoint, pipe, what are bulk/isoch/interrupt/control kinds of traffic, what are the USB packets formats etc.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com