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

HATAYAMA Daisuke d.hatayama at jp.fujitsu.com
Mon Apr 15 00:52:54 EDT 2013

(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 


More information about the kexec mailing list