From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: kexec's v1 compatibility code Date: Fri, 8 May 2015 14:45:48 +0100 Message-ID: <554CBE0C.1090409@citrix.com> References: <554CD78D0200007800078477@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YqibR-0007Zj-NI for xen-devel@lists.xenproject.org; Fri, 08 May 2015 13:46:09 +0000 In-Reply-To: <554CD78D0200007800078477@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , David Vrabel Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 08/05/15 14:34, Jan Beulich wrote: > David, > > now that we're putting Xen 4.4.x underneath an older distro (SLE11) > we've got to see that kexec doesn't work there. Initial investigation > of our kexec person revealed that the destinations attempted to be > written to by kexec_reloc()'s code following the is_source and > is_zero labels have no mappings in the kexec page tables. Comparing > kexec_do_load_v1() with kexec_load() I wonder whether the former > isn't simply lacking a call to kimage_load_segments(). > > He worked around this (I haven't seen the code yet that he used) > to then find that the dump kernel (other than an "ordinary" kexec > one) also expects at least the low 640k to be mapped. He's > suggesting that Linux'es kexec code sets up an identity mapping of > all memory, and that we should do the same. I can't say I'm > convinced of this though, as it seems bogus to me that the dump > kernel should depend on anything beyond a bare minimum > environment it is being handed control in; I would instead expect > the crash kernel to be responsible for any such specific needs. > > May I also ask whether that compatibility code got tested? This is all from a while ago. It is quite possible that we didn't actually tested the compatibility case with a 64bit dom0 kernel, although I certainly did test earlier versions of the series with a 32bit dom0 kernel. The work was done long before XenServer moved to a 64bit dom0, and was done by deleting everything and starting from scratch. IIRC, the low 640k mappings is a purgatory bug rather than Linux, and has been fixed upstream in kexec-tools since. (I recall that it used to take a backup copy of the IVT for some reason) ~Andrew