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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2006-11-29 at 17:17 +0900, Magnus Damm wrote:
> On Wed, 2006-11-29 at 07:54 +0000, Keir Fraser wrote:
> > On 29/11/06 4:30 am, "Magnus Damm" <magnus.damm@xxxxxxxxx> wrote:
> > > 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.
> > 
> > How does kexec discover how many cpus is 'all cpus'?
> 
> The kexec tool creates (at load time) one PT_NOTE program header per
> note exported through /proc/iomem. The number of PT_NOTE program headers
> is the same as the NR_CPUS constant in the hypervisor.

The guest kernel creates entries in /proc/iomem by calling
kexec_get_cpu(cpu) until it returns EINVAL. This currently happens when
cpu>NR_CPUS.

I think this function should return EINVAL for cpu>num_present_cpus()
instead. Xen doesn't currently do PCPU hotplug and this wouldn't be the
only thing that would need fixing if it ever does (percpu data would be
another one I think ;-)).

This would cause the tools to create notes only for CPUs which really
exist. That would make the loop in machine_crash_kexec() unnecessary.

Cheers,
Ian.


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