Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

Hi Ian,

On 11/29/06, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Wed, 2006-11-22 at 16:10 +0900, Magnus Damm wrote:
> > [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)
>
> I've been playing a bit more and found a problem.
>
> You define a per CPU variable crash_notes and on crash you loop over
> NR_CPUS and clear the notes for CPUS which don't exist. Unfortunately
> the percpu regions for CPUs which aren't physically present is returned
> to the heap on boot (see percpu_free_unused_areas) -- this means that
> you zero out heap pages on crash :-(
Ouch. Let's not do that then. =) I wondered why the data areas were
something else than just zero...

We need unique data areas for each cpu, online or not, and these areas
should be zero if the cpus don't exist. This is because we export the
machine address and size of each note to dom0 which in turn exports
the ranges through /proc/iomem to user space.

In user space the kexec-tool then builds an elf header which points
out where the notes are located in machine address space (using
/proc/iomem). This header is then passed on to the secondary crash
kernel which (for some reason) compacts all per-cpu PT_NOTE program
headers into one which will be present in the final vmcore image. At
this compacting stage we need to have data present for _all_ cpus, and
the data for cpus that are not present should contain just zeros.

This scheme should work for cpu hotplug as well.

> You need to use num_{possible,present,online}_cpus() in
> machine_crash_kexec() and kexec_get_cpu() instead of NR_CPUS.
But wouldn't that leave us with machine address in /proc/iomem that
point out heap data instead of notes? I think that using and array in
bss is a simple and good solution:

crash_note_t crash_notes[NR_CPUS];

How does that sound? WIth a comment why we are not using per-cpu data of course.

Thanks for reviewing!

/ magnus

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel