> On a Xeon platform, because DMA doesn’t go through the front-side bus, the
processors cannot snoop DMA cycles
Maybe this is not so?
Let’s suppose it is so. Then the device driver will need to sync the DMA
area/CPU cache by some call. This call is KeFlushIoBuffers. It is no-op on x86.
The conclusion: Microsoft assumes all x86 CPUs to maintain the cache/DMA
coherency automatically in the hardware (by MESI or such), Xeons included.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Ouch! In that case, be sure to limit CPU reads/writes to this memory to
the absolute required minimum. Non-cached memory reads and writes can
incur huge CPU stall times.
Chuck
----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 15, 2003 12:20 AM
Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateCommon
Buffer
> Look up the DDK docs for “Dma Verification”. This is a new
functionality of
> DriverVerifier. Here’s its definition of common-buffer DMA:
>
> Common-buffer DMA
>
> Common-buffer DMA is performed when the system can allocate a single
buffer
> that is accessible by both the hardware and the software. The driver
is
> responsible for synchronizing accesses to the buffer. The memory
is
> not cached, making this synchronization easier for the driver. After
setting
> up a common buffer, both the driver and the hardware can write
directly to
> the addresses in the buffer without any intervention from the HAL.
>
> Well, it specifically says, the memory is not cached to simplify
> synchronization.
>
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Calvin Guan
> Sent: Friday, November 14, 2003 12:03 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Flushing DMA Buffer Allocated with AllocateC
> ommonBuffer
>
>
>
> If you are writing NDIS drivers, you can use NdisMUpdateSharedMemory
to
> flush shared memory which is not described by any NDIS_BUFFER (MDL).
Packet
> descriptor structure accessed by both NIC and CPU falls into this
category.
>
> I couldn’t find the KeXxx counterpart of it. It’s defined as no-op for
now
> though.
>
> Calvin Guan, Software Developer xxxxx@nospam.ati.com
> SW2D-Radeon NT Core Drivers
> ATI Technologies Inc.
> 1 Commerce Valley Drive East
> Markham, Ontario, Canada L3T 7X6
> Tel: (905) 882-2600 Ext. 8654
> Find a driver: http://www.ati.com/support/driver.html
> http:
>
>
> > -----Original Message-----
> > From: Doug [mailto:xxxxx@hotmail.com
mailto:xxxxx]
> > Sent: Friday, November 14, 2003 11:05 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: Flushing DMA Buffer Allocated with
> > AllocateCommonBuffer
> >
> >
> > The documentation does require it. While the page in the DDK
> > help labeled
> > “Using Common-Buffer Bus-Master DMA” makes no mention of
> > allocating an MDL
> > and passing it to KeFlushIoBuffers, the page “Flushing Cached
> > Data during
> > DMA Operations” infers it if you mark the buffers as CacheEnabled.
> >
> > Problem in the DDK docs?
> >
> > “Mark Roddy” wrote in message
> news:xxxxx@ntdev news:xxxxx …
> > 3) 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.
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> http:
>
> You are currently subscribed to ntdev as: xxxxx@ati.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.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></http:></news:xxxxx></mailto:xxxxx></http:>