Figuring out physical memory regions from a kernel module

Figuring out physical memory regions from a kernel module

[Hanson, Jonathan M]

	Is there a reliable way to tell from a kernel module (currently
written for 2.4 but will need to work under 2.6 in the future) which
regions of physical memory are actually available for the kernel and
processes to use? For example, the following command tells me the
regions of physical memory that are available to use:

cat /proc/iomem | grep 'System RAM'

This yields something like the following on my x86 system:

00000000-0009ffff : System RAM
00100000-1ffd5857 : System RAM

I need to be able to determine these regions from within a kernel
module. The e820 data structures configured at kernel boot-time are not
exported so I can't see them from a kernel module, otherwise they would
be perfect. For my purposes, I'm operating under the assumption that all
physical memory can be mapped by the kernel (under 896 MB of physical
memory). Can anyone recommend a way to get to this data? I would greatly
appreciate it.

Re: Figuring out physical memory regions from a kernel module

[Arjan van de Ven]

On Wed, 2004-12-08 at 10:44 -0700, Hanson, Jonathan M wrote:
> 	Is there a reliable way to tell from a kernel module (currently
> written for 2.4 but will need to work under 2.6 in the future) which
> regions of physical memory are actually available for the kernel and
> processes to use? For example, the following command tells me the
> regions of physical memory that are available to use:


ehhh what do you need it for???
without knowing that it's hard to give recommendations

RE: Figuring out physical memory regions from a kernel module

[Hanson, Jonathan M]

-----Original Message-----
From: Arjan van de Ven [mailto:arjan@infradead.org] 
Sent: Wednesday, December 08, 2004 10:50 AM
To: Hanson, Jonathan M
Cc: linux-kernel@vger.kernel.org
Subject: Re: Figuring out physical memory regions from a kernel module

On Wed, 2004-12-08 at 10:44 -0700, Hanson, Jonathan M wrote:
> 	Is there a reliable way to tell from a kernel module (currently
> written for 2.4 but will need to work under 2.6 in the future) which
> regions of physical memory are actually available for the kernel and
> processes to use? For example, the following command tells me the
> regions of physical memory that are available to use:


ehhh what do you need it for???
without knowing that it's hard to give recommendations

[Jon M. Hanson] I'm writing a kernel module that dumps out the contents
of physical memory and the state of the CPU(s) based on an event. I
don't want to traverse memory that isn't actually used as system RAM
(like the 1 M hole, devices, etc.).

Re: Figuring out physical memory regions from a kernel module

[Dave Hansen]

On Wed, 2004-12-08 at 09:44, Hanson, Jonathan M wrote:
> 	Is there a reliable way to tell from a kernel module (currently
> written for 2.4 but will need to work under 2.6 in the future) which
> regions of physical memory are actually available for the kernel and
> processes to use?

Is this a rehashing of the "Walking all the physical memory in an x86
system" thread? :)

Why don't you just tell us what you're actually trying to do in your
module.  There's probably a better way.

-- Dave

RE: Figuring out physical memory regions from a kernel module

[Hanson, Jonathan M]

-----Original Message-----
From: Dave Hansen [mailto:haveblue@us.ibm.com] 
Sent: Wednesday, December 08, 2004 10:58 AM
To: Hanson, Jonathan M
Cc: Linux Kernel Mailing List
Subject: Re: Figuring out physical memory regions from a kernel module

On Wed, 2004-12-08 at 09:44, Hanson, Jonathan M wrote:
> 	Is there a reliable way to tell from a kernel module (currently
> written for 2.4 but will need to work under 2.6 in the future) which
> regions of physical memory are actually available for the kernel and
> processes to use?

Is this a rehashing of the "Walking all the physical memory in an x86
system" thread? :)

Why don't you just tell us what you're actually trying to do in your
module.  There's probably a better way.

-- Dave

[Jon M. Hanson] The module is dumping the contents of physical memory
and saving the architecture state of the system to a file when triggered
(ioctl call). What I have works but I need to extend it to systems other
than my own where I have hard-coded the system RAM regions into the
code. I need the physical addresses of memory because the tool I feed
this output into requires this. Here is an example of what the memory
file looks like:

/origin 00000000
00000001
f0005646
f000e2c3
    .
    .
    .

Memory contents that are all zero are not printed out but another origin
statement must be printed out when a non-zero memory location is
encountered after the optionally multiple locations with zero. All
origin addresses are double-word physical addresses.

Initially I mistakenly thought I could just write a loop that began at
__pa(PAGE_OFFSET) and went to total_ram_pages * PAGE_SIZE. This worked
somewhat but was not traversing all of the memory due to the "holes" in
the RAM (like the 1 M hole and memory-mapped I/O). I hard-coded the
actual "System RAM" locations obtained via:

cat /proc/iomem | grep 'System RAM'

into the code and now I can be sure that I'm getting all of the RAM I'm
intending to get. This will work on this one system only reliably so now
I'm trying to figure out those arbitrary ranges automatically from my
kernel module.

I'm currently trying to figure out these ranges by just traversing the
mem_map array and recording what addresses are in use there. I'm not
sure that's going to work out, though.

RE: Figuring out physical memory regions from a kernel module

[Dave Hansen]

On Wed, 2004-12-08 at 10:28, Hanson, Jonathan M wrote:
>  The module is dumping the contents of physical memory
> and saving the architecture state of the system to a file when triggered
> (ioctl call). What I have works but I need to extend it to systems other
> than my own where I have hard-coded the system RAM regions into the
> code. I need the physical addresses of memory because the tool I feed
> this output into requires this. Here is an example of what the memory
> file looks like:

Sounds like crash dumping.  I think they've already run into and
addressed the same general problems.  

See crashdump-*.patch in here:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm4/broken-out/

-- Dave

RE: Figuring out physical memory regions from a kernel module

[Hanson, Jonathan M]

-----Original Message-----
From: Dave Hansen [mailto:haveblue@us.ibm.com] 
Sent: Wednesday, December 08, 2004 11:40 AM
To: Hanson, Jonathan M
Cc: Linux Kernel Mailing List
Subject: RE: Figuring out physical memory regions from a kernel module

On Wed, 2004-12-08 at 10:28, Hanson, Jonathan M wrote:
>  The module is dumping the contents of physical memory
> and saving the architecture state of the system to a file when
triggered
> (ioctl call). What I have works but I need to extend it to systems
other
> than my own where I have hard-coded the system RAM regions into the
> code. I need the physical addresses of memory because the tool I feed
> this output into requires this. Here is an example of what the memory
> file looks like:

Sounds like crash dumping.  I think they've already run into and
addressed the same general problems.  

See crashdump-*.patch in here:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc
2/2.6.10-rc2-mm4/broken-out/

-- Dave

[Jon M. Hanson] Even looking at the implementation of the crashdump
code, I still encounter the same problem I've run into up until now: the
crashdump code is a part of the kernel so it has access to all of the
kernel's data structures and functions; as a kernel module, I'm
hamstrung by what is exported by the kernel. I know that I can modify
the kernel to export whatever I want but I don't want to have to do
that. I want to be able to run my kernel module without having to patch
the kernel itself.

RE: Figuring out physical memory regions from a kernel module

[Dave Hansen]

On Wed, 2004-12-08 at 13:26, Hanson, Jonathan M wrote:
> [Jon M. Hanson] Even looking at the implementation of the crashdump
> code, I still encounter the same problem I've run into up until now: the
> crashdump code is a part of the kernel so it has access to all of the
> kernel's data structures and functions; as a kernel module, I'm
> hamstrung by what is exported by the kernel. I know that I can modify
> the kernel to export whatever I want but I don't want to have to do
> that. I want to be able to run my kernel module without having to patch
> the kernel itself.

There's some design effort not to expose kernel *internals* to modules. 
Seems like your module requirements are different from the current
design direction of the kernel.

-- Dave

Re: Figuring out physical memory regions from a kernel module

[Vivek Goyal]

How about reading /proc/iomem with some user space utility, parse it and
pass it to your module as parameters during insmod.

On Wed, 2004-12-08 at 23:14, Hanson, Jonathan M wrote:
> 	Is there a reliable way to tell from a kernel module (currently
> written for 2.4 but will need to work under 2.6 in the future) which
> regions of physical memory are actually available for the kernel and
> processes to use? For example, the following command tells me the
> regions of physical memory that are available to use:
> 
> cat /proc/iomem | grep 'System RAM'
> 
> This yields something like the following on my x86 system:
> 
> 00000000-0009ffff : System RAM
> 00100000-1ffd5857 : System RAM
> 
> I need to be able to determine these regions from within a kernel
> module. The e820 data structures configured at kernel boot-time are not
> exported so I can't see them from a kernel module, otherwise they would
> be perfect. For my purposes, I'm operating under the assumption that all
> physical memory can be mapped by the kernel (under 896 MB of physical
> memory). Can anyone recommend a way to get to this data? I would greatly
> appreciate it.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>