I have a customer who is trying to use our board’s DMA engine to
transfer data from our board to his board. I have implemented an IOCTL
using METHOD_OUT_DIRECT. When the IOCTL is called, the OS probes his
board’s memory to make sure it is writable. However, the OS seems to use
a byte-access to perform this probe. His board cannot handle
byte-accesses, and he gets memory corruption.
At least, it seems like this is what is going on.
Is there a way to tell the OS that the target memory for this operation
is 32-bit-aligned?
(Something in the back of my head seems to remember
FILE_FLAGS_NO_BUFFERING as being associated with 32-bit alignment. I
could tell him to try adding that flag to his CreateFile call. But that
just sounds crazy.)
Any ideas? I can always change the method to METHOD_IN_DIRECT, to
prevent the probe, but I would like to do it the rightr way, if there is a
right way!
-Dave Taylor
AJA Video Systems
wrote in message news:xxxxx@ntdev…
>
> I have a customer who is trying to use our board’s DMA engine to
> transfer data from our board to his board. I have implemented an IOCTL
> using METHOD_OUT_DIRECT. When the IOCTL is called, the OS probes his
> board’s memory to make sure it is writable. However, the OS seems to use
> a byte-access to perform this probe. His board cannot handle
> byte-accesses, and he gets memory corruption.
> At least, it seems like this is what is going on.
> Is there a way to tell the OS that the target memory for this operation
> is 32-bit-aligned?
>
No.
In fact, it’s not entirely clear to me that what you’re trying to do is even
supported by the operating system. Have you run this driver under the
checked build of the O/S and under Verifier?
If what you’re telling me is that you have a region of device-resident
memory that you’re trying to pass as an input buffer to another device,
using an METHOD_xxx_DIRECT IOCTL, this doesn’t seem legal to me. The probe
is the LEAST of your worries… consider that the LOCK operation is going to
attempt to increment the reference count on the page in which the user’s
data buffer resides. This count is kept in the PFN. So what’s the probelm?
There no PFN entries created for device memory!
Note that changing the transfer type to _IN_DIRECT instead of _OUT_DIRECT
doesn’t solve this problem.
Perhaps I’m missing something in your description. But, as I started out
asking: Please tell me you’ve tried to run this driver under the checked
build and under Verifier. If you indeed have, can you please provide us
with a more detailed description of the operations you’re undertaking and
with which you’re having the difficulty?
Peter
OSR
Lets pretend the customer is always right. You know that what he wants is
perhaps
not correct. Your boss wants you to make him happy, his boss wants you to
make him
happy. This unfortunate occurrence recurrs on a regular basis on the
planet.
Out of personal interest, how are these ideas viewed?:
You could map a user address for him and feed him just what he wants in
application memory space. Possibly you could memory map a file for him.
This
way you could share the data that you want to share without revealing
physical address space or I/O address space.
Just tell me if I am missing the point,
Asher
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dave Taylor
Sent: Wednesday, August 14, 2002 12:22 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_OUT_DIRECT: unwanted byte-access caused by
probe-and-lock?
I actually don’t know exactly what my customer is doing. I do know that
he is
somehow invoking my IOCTL from his driver. What my driver sees is a IOCTL
request to DMA a frame of video from my board to a virtual address, which
happens to be on his board. I don’t know if his driver runs under Verifier
(mine does), but whatever he is doing is working for him in the ‘Write’
direction (Writing to my board, using my METHOD_IN_DIRECT IOCTL), but not in
the
‘Read’ direction.
Perhaps since he’s calling my driver from his driver, the buffer
referencing
problems that you and Mark refer to do not exist? (Well, I like to hope for
the
best.)
Thanks for the response!
-Dave Taylor
AJA Video Systems
You are currently subscribed to ntdev as: xxxxx@aam-ch.com
To unsubscribe send a blank email to %%email.unsub%%
“Asher Hoodin” wrote in message news:xxxxx@ntdev…
>
> Lets pretend the customer is always right. You know that what he wants is
> perhaps not correct. Your boss wants you to make him happy, his boss
wants you to
> make him happy.
>
Precisely the reason I started my own company. I worked for two years for a
boss who had the IQ of a house plant.
>
> This unfortunate occurrence recurrs on a regular basis on the
> planet.
>
Workers of the world unite!
>
> Out of personal interest, how are these ideas viewed?:
>
I’m not sure if you’re asking for a critique of corporate stupidty, a
pontification on professional engineering ethics, or if you meant to use a
colon instead of a question mark.
Regarding the intersection of corporate stupidty and engineering ethics: It
is always my opinion that as long as a client (manager, marketeer, customer,
or suitably empowered empty suit) has heard – really heard and
understood – my professional opinion on an engineering issue, then I have
discharged my ethical responsibility. In that case, they may choose/need to
make a “business decision”. I believe this is perfectly valid and can be
well justified. Just let’s not all make believe we can merely wish the
technical issue away.
> You could map a user address for him and feed him just what he wants in
> application memory space. Possibly you could memory map a file for him.
> This
> way you could share the data that you want to share without revealing
> physical address space or I/O address space.
>
The customer wants to DMA from device-resident memory on device A to
device-resident memory on device B. As Mr. Roddy said, I’m not entirely
sure that Windows really, properly, supports this. But in any case, Your
Driver could be changed to handle this specific case, as Mr. Roddy also
outlined.
You set up an IOCTL that uses METHOD_NEITHER, and passes the address (KVA,
UVA, or Device Bus Logical Address) of the customer’s device-resident memory
buffer. Assuming you’re given the Device Bus Logical Address (his app would
get this returned from his driver) you’d call MmMapIoSpace(…) to map the
buffer into KV address space. With a valid virtual address (passed in or
thus obtained), you call MmBuildMdlForNonPagedPool(…) to build the MDL,
and use THAT as the basis for the DMA on your device.
Assuming that works without ASSERTing or failing verifier, it’s the method
that’s most likely to be valid. Though this sort of thing has been
technically “edgy” for so long, that I’d personally need to hear the memory
manager tell me that this is now okey-dokey before I’d recommend it as a
certifiable “good idea.”
Alternatively, you could be entirely cavalier about the whole thing, and
require the user pass in the Device Bus Logical Address of his
device-resident memory buffer. You could just merely declare that this is
the same as a physical address on the system in question, and setup your DMA
entirely manually.
Of course, this violates about 873 principals of Windows architecture (One
easy one to consider: Are both DMA devices 64-bit capable? If not, will they
be running on a system with PAE and more than 4GB of physical memory? If
so, you just screwed yourself, and scoobied all over memory). But it’ll
probably work. Probably. And under certain very limited circumstances,
it’d have no chance of crashing the system.
>
> Just tell me if I am missing the point,
>
If your point is that there’s a way around this that’s more valid than just
ducking the issue, then no… you haven’t missed it. If your point is that
there’s some way you can call MmProbeAndLockPages(…) on device memory,
then the answer is “you’ve missed the point.”
Peter
OSR
>Precisely the reason I started my own company.
AMEN!
If your point is that there’s a way around this that’s more valid than just
ducking the issue, then no… you haven’t missed it. If your point is that
there’s some way you can call MmProbeAndLockPages(…) on device memory,
then the answer is “you’ve missed the point.”
I am only saying that we should tell this guy how to get the information
that he
wants. We should also create an interface to give him that information
without violating NT. If Windows NT can’t do everything that DOS can do and
do it
better, maybe we are on the wrong platform. I am not saying how it should
be done,
I am just saying that it should be done.
Asher
>We should also create an interface to give him that information
without violating NT.
As stated by others, there is likely no way to do this.
If Windows NT can’t do everything that DOS can do and
do it
better, maybe we are on the wrong platform.
Sometimes not doing everything DOS could do IS better. For instance, inp
and outp leave a good bit to be desired on the security front 
–
Bill McKenzie
Windows DDK MVP
OSR - Windows System Software Development, Training, and Consulting
“Asher Hoodin” wrote in message news:xxxxx@ntdev…
>
>
> >Precisely the reason I started my own company.
> AMEN!
>
> >If your point is that there’s a way around this that’s more valid than
just
> >ducking the issue, then no… you haven’t missed it. If your point is
that
> >there’s some way you can call MmProbeAndLockPages(…) on device memory,
> >then the answer is “you’ve missed the point.”
>
> I am only saying that we should tell this guy how to get the information
> that he
> wants. We should also create an interface to give him that information
> without violating NT. If Windows NT can’t do everything that DOS can do
and
> do it
> better, maybe we are on the wrong platform. I am not saying how it should
> be done,
> I am just saying that it should be done.
>
> Asher
>
>
>
>
>