Re: [PATCH 5/5] kexec: X86: Pass memory ranges via e820 table insteadof memmap= boot parameter

From: HATAYAMA Daisuke
Date: Mon Apr 15 2013 - 00:53:32 EST

(2013/04/13 7:17), Dave Hansen wrote:
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the current kernel, which is what the oldmem device
seems to be intended to od.

It varies from arch to arch of course.

But, /dev/mem has restrictions on it, like CONFIG_STRICT_DEVMEM or the
ARCH_HAS_VALID_PHYS_ADDR_RANGE. There's a lot of stuff that depends on
it, *and* folks have tried to fix it up so that it's not _as_ blatant of
a way to completely screw your system.

/dev/mem also tries to be nice to arches that have restrictions like:

* On ia64 if a page has been mapped somewhere as
* uncached, then it must also be accessed uncached
* by the kernel or data corruption may occur

I think /dev/oldmem isn't so nice and could actually cause some real
problems if used on ia64 where the cached/uncached accesses are mixed.

This sounds like there's no such issue on x86 cache mechanism. Is it correct? If so, what is the difference between ia64 and x86 cache mechanisms?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at