From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 3 of 3] KEXEC: Allocate crash structures in low memory Date: Tue, 3 Jan 2012 11:58:58 +0000 Message-ID: <4F02ED82.9080907@citrix.com> References: <4EFC8C73020000780007C160@nat28.tlf.novell.com> <4EFE533D.5020307@citrix.com> <4EFEBBDD020000780007C25E@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EFEBBDD020000780007C25E@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 31/12/11 07:38, Jan Beulich wrote: >>>> Andrew Cooper 12/31/11 1:12 AM >>> >> The register contents of the pcpus which were running will be available >> in the PR_STATUS notes which are also deliberately allocated in low >> memory by this patch. To the best of my understanding; to get to the >> dom0 vcpu state, the crashkernel needs access to the domain structs and >> vcpu structs (which I believe are actually allocated below 4GiB) and the > The vCPU ones are, while the domain one isn't. Right - that is useful to know. >> Xen page tables which dom0 uses (which inspecting CR3 from the crash >> notes is certainly not in lower memory). I suspect that there is also >> more which needs to be allocated in lower memory to get a full register >> dump, stack dump, stack trace etc. >> >> The plan is to also have the "all" option from the command line which >> will also allocate the page tables (and other structures where relevant) >> in lower memory, but this is rather more of an overhead than just the >> console ring and crash notes, which will have a more visible impact to >> customers running 32bit PV guests. This is the reason for separating >> the two via a command line argument. > I'm wondering whether, with much less impact on existing code, and as > already pointed out, restricting the allocation range of > alloc_xenheap_pages() (by way of a command line option) wouldn't get > you what you want. > > Jan Assuming that all relevant structures do in fact get allocated by alloc_xenheap_pages() (which is probably a safe assumption looking at the code, but I am not certain) then yes, it would have much less impact on the existing code. However, it would have a much bigger impact on the other memory restricted items. It might be possible (and perhaps a good idea when extreme debugging is needed) to have a 3rd command line option for low_crashinfo= which does this, but I dont like it as the general solution to this problem. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com