[PATCH v2 0/8] Initial implementation of kdump for ARM

[per.xx.fransson@stericsson.com (Per Fransson)]

On 07/09/2010 05:38 AM, Simon Horman wrote:
>>> And it would still be nice to not corrupt the page table of the
>>> crashing context.
>>
>> What you're then asking for is the crashing kernel to allocate 16K of
>> memory to setup some page tables, and then context switch to that table
>> so that the MMU can be turned off.
>>
>> That's never going to be anywhere near reliable.
>
> Can this be addresses by allocating the memory at the time that kdump
> is loaded rather than when it is executed (because of a crash)?
>
> IIRC, x86 uses a double page table approach and it is done reliably.
>
>

We could do that.

Admittedly, this is getting very "hacky", but if we want to set up a new 
L1 page table in which we really only need one entry (for the code 
running until we're sure the MMU is off), we could set up this one entry 
all by itself placed at just the right offset within a page and then set 
the PGD to point at the start of that page (since we're talking about 
mappings for 0x00000000-0x40000000). The rest of the page could still be 
used for other stuff - and even if this turns out to be more trouble 
than it's worth, the other 12KB do not need to be allocated.

However, I still think we could work within the old L1 table and:

1) only modify one entry

2) save that entry before overwriting it

Regards,
Per