>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 02/12/11 15:43, Jan Beulich wrote: >> I just had another look at the Dom0 side of things, and I fail to see why >> you think boot time allocation is necessary: All Dom0 does with the >> provided info is set up the resource tree. The data doesn''t get stored >> for any post-boot use. What am I overlooking? > > /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets > the range values. This is how it grabs the locations to pack into its > magic binary package.So how does the hotplug scenario then get handled on native? I can''t imagine they expect things to remain stable across CPU unplug and re-activation. Jan
Andrew Cooper
2011-Dec-02 16:27 UTC
Re: KEXEC: allocate crash note buffers at boot time v5
On 02/12/11 16:11, Jan Beulich wrote:>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 02/12/11 15:43, Jan Beulich wrote: >>> I just had another look at the Dom0 side of things, and I fail to see why >>> you think boot time allocation is necessary: All Dom0 does with the >>> provided info is set up the resource tree. The data doesn''t get stored >>> for any post-boot use. What am I overlooking? >> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets >> the range values. This is how it grabs the locations to pack into its >> magic binary package. > So how does the hotplug scenario then get handled on native? I can''t > imagine they expect things to remain stable across CPU unplug and > re-activation. > > JanI am not how (or even if) the hotplug condition is handled on native. I guess it depends on what is put into the resource tree on boot. With my patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which covers all the cases. The worst that will happen is that some crash notes do not get written if certain cpus are offline at the time of a crash. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
>>> On 02.12.11 at 17:27, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 02/12/11 16:11, Jan Beulich wrote: >>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> On 02/12/11 15:43, Jan Beulich wrote: >>>> I just had another look at the Dom0 side of things, and I fail to see why >>>> you think boot time allocation is necessary: All Dom0 does with the >>>> provided info is set up the resource tree. The data doesn''t get stored >>>> for any post-boot use. What am I overlooking? >>> /sbin/kexec opens /proc/iomem and looks for "Crash note" and interprets >>> the range values. This is how it grabs the locations to pack into its >>> magic binary package. >> So how does the hotplug scenario then get handled on native? I can''t >> imagine they expect things to remain stable across CPU unplug and >> re-activation. > > I am not how (or even if) the hotplug condition is handled on native. I > guess it depends on what is put into the resource tree on boot. With myI don''t think native kexec depends on stuff being made visible in /proc/iomem - grep-ing for "Crash note" in 2.6.18 as well as a current tree hits exclusively the Xen instance. Native uses a per-CPU allocation (i.e. address and contents can''t be expected to survive offlining of a CPU).> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which > covers all the cases. The worst that will happen is that some crash > notes do not get written if certain cpus are offline at the time of a crash.And did you check that nothing in the producer or consumer chain gets confused by this new behavior? Jan
Andrew Cooper
2011-Dec-02 16:55 UTC
Re: KEXEC: allocate crash note buffers at boot time v5
On 02/12/11 16:38, Jan Beulich wrote:>> patch, Xen will give crash areas for all pcpus up to nr_cpu_ids, which >> covers all the cases. The worst that will happen is that some crash >> notes do not get written if certain cpus are offline at the time of a crash. > And did you check that nothing in the producer or consumer chain gets > confused by this new behavior? > > Jan >/proc/vmcore reported by the kdump kernel is fine, even with extra notes which have 0 contents (after I deliberately caused kexec_get_cpu to report 1 more cpu than was present for testing exactly this) The producer/consumer chain will not change. There was a case previously where a CPU which was present at boot and subsequently offlined would leave crash notes with 0''s in them. Therefore, if a tool couldn''t deal with that case, it wont be able to deal with this case. If a tool could deal with that case, it can deal with the new case. I would hazard a guess that most of the time, we will boot on all CPUs and crash with all of those CPUs still up, so it is more likely that there will be no 0''d notes. (When I say a 0''d note, I mean a note with correct header, type and name, but 0''s in the desc) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com