Prev: Unclear fakemodem kmdf sample behavior
Next: Mirror Driver-Use mapviewoffile in DrvEscape
From: BubbaGump on 20 Oct 2006 20:21
I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
is defined to do nothing, absolutely nothing. I know x86 cache's are
already coherent with respect to DMA, but isn't there still the
possibility of out-of-order loads and stores? Is this a bug? Are
driver's supposed to do a KeMemoryBarrier() explicitly?

Even if the x86 still does program ordered stores, and Microsoft will
update KeFlushIoBuffers() at some point in the future when that
ordering is no longer true, the compiler's memory accesses might not
be ordered so at least a compiler memory barrier is needed for DMA out
to a device.

What about after a DMA? In order to account for speculative loads
during DMA in from a device, does the call to FlushAdapterBuffers()
have a memory barrier or should the driver also do a KeMemoryBarrier()
explicitly here?

From: soviet_bloke on 20 Oct 2006 21:30
> I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
> is defined to do nothing, absolutely nothing.

What do you mean by "defined"?????? After all, KeFlushIoBuffers() is a
function, rather than macro. What do you expect to see, apart from
function's prototype, in a header file?????

Anton Bassov


BubbaGump wrote:
> I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
> is defined to do nothing, absolutely nothing. I know x86 cache's are
> already coherent with respect to DMA, but isn't there still the
> possibility of out-of-order loads and stores? Is this a bug? Are
> driver's supposed to do a KeMemoryBarrier() explicitly?
>
> Even if the x86 still does program ordered stores, and Microsoft will
> update KeFlushIoBuffers() at some point in the future when that
> ordering is no longer true, the compiler's memory accesses might not
> be ordered so at least a compiler memory barrier is needed for DMA out
> to a device.
>
> What about after a DMA? In order to account for speculative loads
> during DMA in from a device, does the call to FlushAdapterBuffers()
> have a memory barrier or should the driver also do a KeMemoryBarrier()
> explicitly here?

From: BubbaGump on 20 Oct 2006 22:21
On 20 Oct 2006 18:30:35 -0700, soviet_bloke(a)hotmail.com wrote:

>> I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
>> is defined to do nothing, absolutely nothing.
>
>What do you mean by "defined"?????? After all, KeFlushIoBuffers() is a
>function, rather than macro. What do you expect to see, apart from
>function's prototype, in a header file?????

I see a macro, defined to nothing:


#if defined(_X86_)

....

#define KeFlushIoBuffers(Mdl, ReadOperation, DmaOperation)

....

From: Jonathan Morrison on 20 Oct 2006 22:53
IIRC - it is only implemented on IA64. x86 and x64 (I think) use serializing
instructions for IO reads and writes so there is an implicit barrier.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
<BubbaGump> wrote in message
news:ir0jj2t1j3k3qhgtoavsj1qdof7100obn1(a)4ax.com...
> On 20 Oct 2006 18:30:35 -0700, soviet_bloke(a)hotmail.com wrote:
>
>>> I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
>>> is defined to do nothing, absolutely nothing.
>>
>>What do you mean by "defined"?????? After all, KeFlushIoBuffers() is a
>>function, rather than macro. What do you expect to see, apart from
>>function's prototype, in a header file?????
>
> I see a macro, defined to nothing:
>
>
> #if defined(_X86_)
>
> ...
>
> #define KeFlushIoBuffers(Mdl, ReadOperation, DmaOperation)
>
> ...
>


From: BubbaGump on 20 Oct 2006 23:15
The barrier done on I/O writes (like WRITE_REGISTER_ULONG) is
performed _after_ the write, which means all operations before and
including the write to the DMA "Go" bit will be serialized together
with no predictable ordering relative to each other. This doesn't
guarantee the write will be the very last operation, which means a
write to part of the DMA'd buffer may happen after the "Go" bit is
set.

The barrier for the DMA'd buffer needs to be after the DMA'd buffer is
written but before the write to the "Go" bit. This is where
KeFlushIoBuffers() normally goes (and it would be nice if it did the
barrier instead of nothing).

(I'm aware that practically speaking there will probably be a few I/O
writes between the last write to the DMA'd buffer and the write to the
"Go" bit so there will be at least one barrier, but strictly speaking
KeFlushIoBuffers() should be providing the barrier)




On Fri, 20 Oct 2006 19:53:53 -0700, "Jonathan Morrison"
<jonathanm(a)mindspring.com> wrote:

>IIRC - it is only implemented on IA64. x86 and x64 (I think) use serializing
>instructions for IO reads and writes so there is an implicit barrier.
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Use of any included script samples are subject to the terms specified at
>http://www.microsoft.com/info/cpyright.htm
><BubbaGump> wrote in message
>news:ir0jj2t1j3k3qhgtoavsj1qdof7100obn1(a)4ax.com...
>> On 20 Oct 2006 18:30:35 -0700, soviet_bloke(a)hotmail.com wrote:
>>
>>>> I noticed in my DDK header files (3790.1830) that KeFlushIoBuffers()
>>>> is defined to do nothing, absolutely nothing.
>>>
>>>What do you mean by "defined"?????? After all, KeFlushIoBuffers() is a
>>>function, rather than macro. What do you expect to see, apart from
>>>function's prototype, in a header file?????
>>
>> I see a macro, defined to nothing:
>>
>>
>> #if defined(_X86_)
>>
>> ...
>>
>> #define KeFlushIoBuffers(Mdl, ReadOperation, DmaOperation)
>>
>> ...
>>
>

 |  Next  |  Last
Pages: 1 2 3 4
Prev: Unclear fakemodem kmdf sample behavior
Next: Mirror Driver-Use mapviewoffile in DrvEscape