On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock [off-list ref] wr=
ote:

On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:

quoted

quoted

Thanks for taking a look. My first thought was to just blow away all

the

quoted

memreserve regions and start over. But, there are reserve regions

for

quoted

other things that I might not want to blow away. For example, on

mpc85xx

quoted

SMP systems we have an additional reserve region for our boot page.

What is your starting point? =A0Where does the device tree (and
memreserve list) come from
that you're passing to kexec? =A0My first impression is that if you have
to scrub the memreserve list, then the source being used to
obtain the memreserves is either faulty or unsuitable to the task.

I'm pulling the device tree passed in via u-boot and passing it to
kexec.

How?  (what mechanism?)  I hope you're not using the debugfs
flat-device-tree file.

It is the most complete device tree and requires the least amount
of fixup.

I have to scrub two items, the ramdisk/initrd and the device tree
because upon kexec'ing the kernel we have the ability to pass in new
ramdisk/initrd and device tree. They can also live at different physical
addresses for the second reboot.

This sounds like the model is backwards.  Rather than scrubbing items,
the memreserve list should be built up from a known good source.

The initrd addresses are already exposed, so we can update/remove/reuse
that entry, we just need a way for kexec to determine the current device
tree address so it can replace the correct memreserve region for the
kexec'ing kernels' device tree.

The whole problem comes from repeatedly kexec'ing, we need to make sure
we don't keep losing blobs of memory to reserve regions (so we can't
just blindly add). We also need to make sure we don't lose other
memreserve regions that might be important for other things (so we can't
just blow them all away).

Right, so you need to have a known-good list of reserve sections.
Trying to go the other way sounds very fragile.

g.

-M

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.