From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels Date: Mon, 14 Oct 2013 15:14:13 +0100 Message-ID: <525BFC35.70801@citrix.com> References: <1381251310-29449-1-git-send-email-david.vrabel@citrix.com> <20131009152616.GB30387@router-fw-old.local.net-space.pl> <52557E4A.2000500@citrix.com> <20131010154538.GA22446@router-fw-old.local.net-space.pl> <5256D75B.5090504@citrix.com> <20131010212433.GX3626@debian70-amd64.local.net-space.pl> <5257BB9102000078000FA6F2@nat28.tlf.novell.com> <5257CB49.4030005@citrix.com> <20131011111521.GB3626@debian70-amd64.local.net-space.pl> <525805D1.3040900@citrix.com> <20131014135338.GD3626@debian70-amd64.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131014135338.GD3626@debian70-amd64.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: Keir Fraser , Daniel Kiper , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 14/10/13 14:53, Daniel Kiper wrote: > On Fri, Oct 11, 2013 at 03:06:09PM +0100, David Vrabel wrote: >> On 11/10/13 12:15, Daniel Kiper wrote: >>> >>>> + * - Register values are undefined. >>> >>> If Linux and kexec guys state that they do not care then I do not care too. >>> Let's wait what will happen in "kexec: Clearing registers just before >>> jumping into purgatory" thread. >> >> How about we get the current series in as-is (plus the extra docs) and >> then, since you feel so strongly about this minor point, you post a >> follow patch to change the behaviour? >> >> Does that work for you? If so and if you're happy with everything else, >> can I get your Reviewed-by on the whole series? > > What do you think about last Eric comments? Should we continue our discussion? > If yes I could do final tests of latest series now and put my Tested-by and > Reviewed-by as needed. Later we could establish details and put follow up patches > (one for zeroing registers and one fixing/aliging calling convention for > relocate_pages). It will be nice if we finish this stuff by the of this week. I think there are two[*] sensible options: A. Registers are specified as undefined, register values are not initialized. B. Registers are specified as zeroed (%rsp, %rax excepted), register values are initialized to zero. If A is merged, then Xen can move to B later. If B is merged, Xen cannot go back to A. Therefore, I think we should merge A and discuss moving to B (or perhaps even C) as a separate item. (FYI, I've already fixed up relocate_pages() to go into v10 since I need to post v10 with the extra docs anyway.) David [*] There is a third way: C. Registers are specified as undefined, but register values are initialized to zero. But I don't think the specification should diverge from the implementation.