Thread (29 messages) flat view 29 messages, 5 authors, 2011-08-25
STALE5500d

Revision v4 of 9 in this series.

Revisions (9)
  1. v1 [diff vs current]
  2. v2 [diff vs current]
  3. v3 [diff vs current]
  4. v4 [diff vs current]
  5. v4 [diff vs current]
  6. v4 [diff vs current]
  7. v4 [diff vs current]
  8. v4 current
  9. v4 [diff vs current]

[PATCH v4 0/8] MMU disabling code and kexec fixes

From: Will Deacon <hidden>
Date: 2011-08-24 17:45:37

On Wed, Aug 24, 2011 at 06:30:07PM +0100, Nicolas Pitre wrote:
On Wed, 24 Aug 2011, Will Deacon wrote:
quoted
On Wed, Aug 24, 2011 at 03:53:44PM +0100, Nicolas Pitre wrote:
quoted
On Wed, 24 Aug 2011, Will Deacon wrote:
quoted
On top of that, I'd like to use the bottom of this page as a holding pen
for secondary CPUs when doing an SMP kexec. In this case, the new kernel
needs to take care not to allocate the page for general use. I suppose we
could fix this with a new ATAG / FDT property but that seems a bit overkill.
Is it?
Well it means re-encoding a DT blob from within the kernel so that we can
tell the next kernel not to allocate from a given page of physical memory.
If we already have this infrastructure, then great, but it looks to me like
it only lives within dtc (as libfdt) at the moment.
Hmmm... The kexec user space tools know how to manipulate a device tree 
for the next kernel, right?  So it's only a matter for it to ask the 
current kernel what the physical address for that page is and stuff it 
into the FDT it is preparing already.
oo-er, it seems a bit odd telling userspace about that address but it does
fix the problem. I can't think of a better idea, so I'll start looking for a
sane interface for passing this address back.

Thanks for the help,

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help