From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754100Ab3AGQVA (ORCPT ); Mon, 7 Jan 2013 11:21:00 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:35762 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753727Ab3AGQU7 (ORCPT ); Mon, 7 Jan 2013 11:20:59 -0500 Date: Mon, 7 Jan 2013 11:20:18 -0500 From: Konrad Rzeszutek Wilk To: Daniel Kiper Cc: Jan Beulich , Andrew Cooper , "x86@kernel.org" , "tglx@linutronix.de" , "kexec@lists.infradead.org" , "virtualization@lists.linux-foundation.org" , "xen-devel@lists.xensource.com" , "maxim.uvarov@oracle.com" , "mingo@redhat.com" , "vgoyal@redhat.com" , "linux-kernel@vger.kernel.org" , "Eric W. Biederman" , "H. Peter Anvin" Subject: Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation Message-ID: <20130107162018.GJ3219@phenom.dumpdata.com> References: <50DBC856.6030208@zytor.com> <791b4922-078f-4adc-b3f3-0651f2266147@email.android.com> <50DC58C4.3000307@citrix.com> <874nj7qsor.fsf@xmission.com> <50E41973.9050705@citrix.com> <20130104142257.GC3346@host-192-168-1-59.local.net-space.pl> <50E6F81D02000078000B3245@nat28.tlf.novell.com> <20130104170751.GB3472@host-192-168-1-59.local.net-space.pl> <20130104191146.GC6721@phenom.dumpdata.com> <20130107123404.GA2927@host-192-168-1-59.local.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130107123404.GA2927@host-192-168-1-59.local.net-space.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote: > On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote: > > On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote: > > > On Fri, Jan 04, 2013 at 02:41:17PM +0000, Jan Beulich wrote: > > > > >>> On 04.01.13 at 15:22, Daniel Kiper wrote: > > > > > On Wed, Jan 02, 2013 at 11:26:43AM +0000, Andrew Cooper wrote: > > > > >> /sbin/kexec can load the "Xen" crash kernel itself by issuing > > > > >> hypercalls using /dev/xen/privcmd. This would remove the need for > > > > >> the dom0 kernel to distinguish between loading a crash kernel for > > > > >> itself and loading a kernel for Xen. > > > > >> > > > > >> Or is this just a silly idea complicating the matter? > > > > > > > > > > This is impossible with current Xen kexec/kdump interface. > > > > > > > > Why? > > > > > > Because current KEXEC_CMD_kexec_load does not load kernel > > > image and other things into Xen memory. It means that it > > > should live somewhere in dom0 Linux kernel memory. > > > > We could have a very simple hypercall which would have: > > > > struct fancy_new_hypercall { > > xen_pfn_t payload; // IN > > ssize_t len; // IN > > #define DATA (1<<1) > > #define DATA_EOF (1<<2) > > #define DATA_KERNEL (1<<3) > > #define DATA_RAMDISK (1<<4) > > unsigned int flags; // IN > > unsigned int status; // OUT > > }; > > > > which would in a loop just iterate over the payloads and > > let the hypervisor stick it in the crashkernel space. > > > > This is all hand-waving of course. There probably would be a need > > to figure out how much space you have in the reserved Xen's > > 'crashkernel' memory region too. > > I think that new kexec hypercall function should mimics kexec syscall. > It means that all arguments passed to hypercall should have same types > if it is possible or if it is not possible then conversion should be done > in very easy way. Additionally, I think that one call of new hypercall > load function should load all needed thinks in right place and > return relevant status. Last but not least, new functionality should We are not restricted to just _one_ hypercall. And this loading thing could be similar to the micrcode hypercall - which just points to a virtual address along with the length - and says 'load me'. > be available through /dev/xen/privcmd or directly from kernel without > bigger effort. Perhaps we should have a email thread on xen-devel where we hash out some ideas. Eric, would you be OK included on this - it would make sense for this mechanism to be as future-proof as possible - and I am not sure what your plans for kexec are in the future? > > Daniel