[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 10.10.13 at 23:24, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> On Thu, Oct 10, 2013 at 05:35:39PM +0100, David Vrabel wrote:
>> The register state on executing the image is undefined (this is the
>> specified ABI), so there is no need to set the registers to any
>> particular value.
> 
> So let's look into the docs.

"docs"?

> I have found at least two interesting source
> files for us. linux/arch/x86/kernel/relocate_kernel_64.S (let's focus
> on 64-bit; 32-bit is quite similar) contains something like:
> 
>         /*
>          * set all of the registers to known values
>          * leave %rsp alone
>          */
> 
>         testq   %r11, %r11
>         jnz 1f
>         xorl    %eax, %eax
>         xorl    %ebx, %ebx
>         xorl    %ecx, %ecx
>         xorl    %edx, %edx
>         xorl    %esi, %esi
>         xorl    %edi, %edi
>         xorl    %ebp, %ebp
>         xorl    %r8d, %r8d
>         xorl    %r9d, %r9d
>         xorl    %r10d, %r10d
>         xorl    %r11d, %r11d
>         xorl    %r12d, %r12d
>         xorl    %r13d, %r13d
>         xorl    %r14d, %r14d
>         xorl    %r15d, %r15d
> 
>         ret

This is all source code, not documentation.

> Comment clearly states: set all of the registers to known values; leave %rsp 
> alone.
> So registers states, just before jump into purgatory, are clearly defined.

The implementer of this code wanted them to be, but none of the
above in any way says that there's a requirement. One could as
well load ~0 into all of them, or some random or garbage pattern.

> Now look into kexec-tools/purgatory/arch/x86_64/setup-x86_64.S. There is
> no any single word about registers states. Even any instruction assumes 
> their
> states. Excluding %rsp which should point to jump_back_entry. In our case
> %rsp should point to 0UL stored at the stack (we have missed that and it
> should be fixed by us).

So then where's your problem with David leaving the register
values alone?

>> If the implementation did zero the registers then an image could rely on
>> this.  It would then be impossible to change the implementation to do
> 
> This is bogus. Any sane developer or maintainer do not assume any register
> state if it is not clearly described by existing docs. And it is not. Such
> brain dead code would not be accepted at least at kexec list. Guys doing
> that are crazy and I do not care about them. They are just asking for 
> problems.

So you seem to contradict yourself: First you demand the registers
to be zeroed, and then you explain why there's no need to? What's
your position then after all?

Jan


_______________________________________________
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®.