use of alloc_bootmem for a PCI-e device

[Jean-Francois Dagenais <jeff.dagenais@gmail.com>]

Hello fellow hackers,

I am maintaining a kernel for an embedded product. We have an FPGA
acquisition device interfaced through PCI-e on different intel platforms.
The acquisition device needs an extra large physically contiguous memory
area to autonomously dump acquired data into.

In a previous product, VT-d was available and I made use of it to allocate
128MB+ using vmalloc, then mapping it so it forms a contiguous address
chunk from the device side.

We are doing another incarnation of the product on an Atom E6xx which has
no such IOMMU and am looking into ways of allocating a huge chunk of ram.
Kind of like integrated gfx chips do with RAM, but I don't have the assistance
of the BIOS.

Based on suggestions to try using alloc_bootmem, I have started looking into
it by first making a platform (under arch/x86/platform) built-in module using
"pure_initcall" to get an early hook to allocate this memory. This approach
failed because the call would happen after SLUB init.

I then proceeded to hack "mm_init()" in init/main.c so that I do the alloc_bootmem
call after "mem_init()" but before "kmem_cache_init()". I successfully get the huge
chunk I request, and test that it is really physically contiguous.

My joy was not long lived, it was too easy. Once fully booted, I load a module
which tests a patter I wrote in memory to see if the memory got touched since
the early init moment, and it did. A crude test, but right away tells me the
allocation was not respected.

Any thoughts on how to achieve this?

We are targeting v3.1 64 or 32 bits, testing with 3.2-rc1 on x84_64. I noticed this
means "nobootmem.c" is used.

Thanks
/jfd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>