Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in low memory

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrew Cooper  12/23/11 12:59 PM >>>
>On 23/12/11 09:06, Jan Beulich wrote:
>>>>> On 22.12.11 at 18:36, Andrew Cooper  wrote:
>>> On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
>>> as the CPU crash notes will go into the xenheap, which tends to be in
>>> upper memory.  This causes problems on machines with more than 64GB
>>> (or 4GB if no PAE support) of ram as the crashkernel physically cant
>>> access the crash notes.
>> What use is a crash dump taken with a 32-bit kernel on a machine
>> with more than 64G (or more than 4G is the crash kernel doesn't
>> support PAE)?
>
>Very little use at all, which is the reason for this change.

With this change, the usefulness doesn't significantly increase imo.

>The correct solution is indeed to use a 64bit dom0 kernel, but while
>politics is preventing that from happening, another solution has to be
>found.  I doubt that XenServer is the only product which would benifit,
>which is why the changes are presented for upstreaming.
>
>>>  3) Change the conring buffer to use lower memory when instructed.
>> Why does this one need moving, but none of the other Xen data
>> structures? If anything, I would have expected you to limit the Xen
>> heap altogether, so that automatically all allocations get done in a
>> way so that at least Xen's data structures are available in the
>> (truncated) dump.
>
>This is part of the "min" option which is trying to have the least
>possible impact.  The idea is to have this in low memory, use the
>"console_to_ring" boot option to copy dom0 dmesg into conring, and pass
>its physical address and size in a crash note, so that the crash kernel
>environment grab it all.

Why is the console ring *that* important? I would have thought
that proper register values and stack contents are much more
significant for analysis of a crash.

Jan


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