Re: [Xen-devel] KEXEC: allocate crash note buffers at boot time v5

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.12.11 at 17:27, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/12/11 16:11, Jan Beulich wrote:
>>>>> On 02.12.11 at 16:59, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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 my

I 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


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