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

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

quoted

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?  Where does the device tree (and
memreserve list) come from
that you're passing to kexec?  My 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.

That is one way to get a good working copy. What is wrong with this
mechanism?

Should we duplicate everything u-boot does in kexec to build up a flat
device tree? Or is there another way to get a good tree? Ideally, we
don't make the end user manually edit a device tree.

quoted

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.

You can build one up yourself and it will still work out fine. Or you
can pull one from debugfs to get yourself started. Or you can pull it
every time. 

quoted

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.

Yes. Where would we get a list of memreserve sections? Should we export
the reserve sections instead of the device tree location? We just need a
way to preserve what was there at boot to pass to the new kernel.

-M