On 28-01-08 17:12, Peter Teoh wrote:
In Documentation/DMA-mapping.txt:
If you acquired your memory via the page allocator
(i.e. __get_free_page*()) or the generic memory allocators
(i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from
that memory using the addresses returned from those routines.
This means specifically that you may _not_ use the memory/addresses
returned from vmalloc() for DMA. It is possible to DMA to the
_underlying_ memory mapped into a vmalloc() area, but this requires
walking page tables to get the physical addresses, and then
translating each of those pages back to a kernel address using
something like __va().
My Question:
1. when any generic hardware (non-CPU) attempts to write to the
memory, they will access it via the physical address - right?
Right, with s/physical address/bus address/. On x86, those are the same but
on some architectures addresses as seen from the bus differ from physical
addresses from the CPU/MMU viewpoint (adding some fixed offset to convert
between the two).
2. when the CPU attempt to access the memory, they can access it via
the virtual address + MMU + pagetable mechanism to retrieve the data -
right?
Right.
3.. I don't understand this part - "this requires walking page tables
to get the physical addresses, and then translating each of those pages
back to a kernel address using something like __va(). ".
what is the difference between get_free_page()/kmem_cache_alloc() and
vmalloc() that makes the former dma-able, and latter not?
The former interfaces get you a region contiguous in physical space. For low
memory, also in virtual space due to the 1:1 mapping, but in physical is the
important point. vmalloc() gets you memory that's contiguous only in
_virtual_ space though: the underlying memory may be scattered all over
physical space. vmalloc() just creates a contigous _mapping_ (by mapping the
pages into the VMALLOC_RESERVE hole at the end of the addressspace).
With physically contiguous pages getting scarce after some time on a running
system, vmalloc() not requiring any is in fact the point of that interface.
Due to the limited mapping-range you have available for vmalloc()ed memory,
you shouldn't actually use it a lot, but in principle it's the saner
interface since most allocations don't need physically contiguous memory.
However, normally (or well, historically) hardware takes a (base, size) pair
as a specification only meaning it needs the memory contiguous in
bus/physical space. These days, some hardware supports what is known as
scather-gather DMA which means it has an MMU of its own that you can setup
for use with non-contiguous memory, in whatever granularity said piece of
hardware specifies, but the important difference here is the above:
vmalloc() gets you memory that's contiguous only in virtual terms (ie, from
the CPUs viewpoint, not from the hardware's) while the other interfaces get
you memory that's contiguous in bus/physical terms.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
