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

[David Vrabel <david.vrabel@citrix.com>]

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.