Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502) - Ian Campbell - com.xensource.lists.xen-devel

25 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH 00/04] Kexec /...

From	Sent On	Attachments
Magnus Damm	21 Nov 2006 23:10
Magnus Damm	21 Nov 2006 23:10
Magnus Damm	21 Nov 2006 23:10
Magnus Damm	21 Nov 2006 23:10
Magnus Damm	21 Nov 2006 23:11
Ian Campbell	22 Nov 2006 10:23
Magnus Damm	27 Nov 2006 01:18
Ian Campbell	27 Nov 2006 04:09
Dave Anderson	27 Nov 2006 07:27
Magnus Damm	28 Nov 2006 00:27
Magnus Damm	28 Nov 2006 00:30
Ian Campbell	28 Nov 2006 01:26
Dave Anderson	28 Nov 2006 06:01
Ian Campbell	28 Nov 2006 10:23
Keir Fraser	28 Nov 2006 10:50
Magnus Damm	28 Nov 2006 18:35
Magnus Damm	28 Nov 2006 20:30
Keir Fraser	28 Nov 2006 23:54
Magnus Damm	29 Nov 2006 00:17
Ian Campbell	29 Nov 2006 01:35
Ian Campbell	29 Nov 2006 01:36
Magnus Damm	29 Nov 2006 02:59
Ian Campbell	29 Nov 2006 03:06
Magnus Damm	29 Nov 2006 03:13
Ian Campbell	29 Nov 2006 03:42

Subject:	Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)
From:	Ian Campbell (Ian....@XenSource.com)
Date:	11/29/2006 03:42:14 AM
List:	com.xensource.lists.xen-devel

On Wed, 2006-11-29 at 20:13 +0900, Magnus Damm wrote:

On 11/29/06, Ian Campbell <Ian....@xensource.com> wrote:

On Wed, 2006-11-29 at 17:17 +0900, Magnus Damm wrote:

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.

I feel that using bss instead of per-cpu data is more robust and will make future cpu hotplug support a breeze to implement - at least in the case of kexec. Using bss also makes the loop in machine_crash_kexec() unnecessary.

Using num_present_cpus() will of course work as well, but I'd like to avoid adding code that likely needs to be rewritten in the near future.. But you know the future better than I do, so what do you think? =)

I don't think anyone is planning PCPU hotplug anytime soon (I've not even heard rumours about the distant future ;-)). I do think that using the existing infrastructure is the right way to go though rather than open coding a different per cpu mechanism to solve a problem which doesn't currently exist. If someone implements PCPU hotplug they will no doubt need to update the per cpu infrastructure and if kdump is using it then it can be taken into consideration at that time.

Cheers, Ian.