Maybe someone who’s more familiar with the hardware can explain it to me ?
I’m having trouble visualizing how it works.
On a Xeon platform, because DMA doesn’t go through the front-side bus, the
processors cannot snoop DMA cycles, and hence the MESI protocol doesn’t take
those transfers into consideration. Unless of course the bridge has some
mechanism to warn processors, but then, that would defeat the point of doing
DMA, no ? I mean, instead of generating data cycles on the FSB we generate
snoop cycles instead ? Going out may be negotiated with writethrough, but
going in may be a problem, how are the processors going to know that
physical memory has changed under their caches ? And when it does, the
processors will need to invalidate the caches, so, what’s the point of
having a cacheable region for the common buffer ? Furthermore, data that
goes out in a DMA transfer must be resident in physical memory, so, wouldn’t
it be the case that some sequencing instruction would be required to flush
the write buffers ?
I’m a bit rusty on all that jazz, so, I may be wrong !
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Thursday, November 13, 2003 2:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with
AllocateCommonBuffer
-
the OP should consider why he needs a cached common buffer.
-
on all current platforms (i.e. not alpha or mips or powerpc,) running
NT all memory is by default cache coherent, including memory written by
peripheral devices, from the perspective of the processors on the
system. The only possible issue is writes from the CPU to the common
buffer where the common buffer is cached. I’m not convinced there is a
problem here, but see point one above. -
common buffers are ‘special’. They are platform specific designed to
be used for dma. The documentation in the DDK does not require that you
flush common buffers.
Note that on x86 platforms KeFlushIoBuffers is a NOP. Draw your own
conclusions.
===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
-----Original Message-----
From: “Doug”
To: “Windows System Software Devs Interest List”
Date: Wed, 12 Nov 2003 11:46:17 -0500
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with
AllocateCommonBuffer
> Data written by the cpu to a device can exists in the cache (unless
> this is
> write-through cache) and needs to get flushed to the actual physical
> memory
> so the device can bus master it.
>
> Data written by a device can exist in the memory but the cache lines
> may
> have old data in them so they need to be invalidated before the cpu can
> ‘read’ the data.
>
> Direct is not direct when caches are involved…
>
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > Think of it: it’s called “direct” memory access because it doesn’t
> involve
> > the processors. Caches belong in the processors. Ergo…
> >
> > Alberto.
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.