[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels



On Mon, Oct 14, 2013 at 08:13:52PM +0200, Daniel Kiper wrote:
> On Mon, Oct 14, 2013 at 03:14:13PM +0100, David Vrabel wrote:
> > 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.
>
> OK.
>
> > (FYI, I've already fixed up relocate_pages() to go into v10 since I need
> > to post v10 with the extra docs anyway.)
>
> Thanks.
>
> > 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.
>
> I agree but I think that we could solve that problem by adding comment
> which precisely explains what is going on and what callee should expect
> (uninitialized registers). Eric comment is nice and could be used by us
> as a starting point. Additionally, I think that similar comment should
> be added to Linux Kernel source and purgatory entry (I could do that).

Now I think that we are at point in which we should solve this issue. A option
is merged now with short comment. Personally I prefer C with Eric Biederman 
comment.
However, if you are not convinced we could stay with A but I prefer that current
comment would be extended with clear statement why we decided to deviate from 
Linux
implementation (which we used as a base for our development).

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.