From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 3 of 3] KEXEC: Allocate crash structures in low memory Date: Thu, 29 Dec 2011 15:51:15 +0000 Message-ID: <4EFC8C73020000780007C160@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: andrew.cooper3@citrix.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> 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