Makes sense. Ljmpq it is. A comment might be useful. Borislav Petkov <b...@alien8.de> wrote:
>On Sun, Dec 23, 2012 at 10:00:26AM -0800, Yinghai Lu wrote: >> On Sun, Dec 23, 2012 at 6:33 AM, H. Peter Anvin <h...@zytor.com> >wrote: >> > Explanation please? >> >> you have following change in the patch >> >> /* Finally jump to run C code and to be on real kernel >address >> * Since we are running on identity-mapped space we have to >jump >> * to the full 64bit address, this is only possible as >indirect >> * jump. In addition we need to ensure %cs is set so we make >this >> - * a far return. >> + * a far jump. >> */ >> - movq initial_code(%rip),%rax >> pushq $0 # fake return address to stop >unwinder >> - pushq $__KERNEL_CS # set correct cs >> - pushq %rax # target address in negative space >> - lretq >> + /* gas 2.22 is buggy and mis-assembles ljmpq */ >> + rex64 ljmp *initial_code(%rip) >> >> #ifdef CONFIG_HOTPLUG_CPU >> /* >> >> remove that change, AMD systems works again. > >Right, the original code did a RET FAR by popping CS and rIP from the >stack. And we did prepare the stack properly before that so it worked. > >Now, the ljmp translates to a JMP FAR: > >ffffffff8100016e: 48 ff 2d ab a5 7f 00 rex.W ljmpq >*0x7fa5ab(%rip) # ffffffff817fa720 <initial_code> >ffffffff81000175: 66 66 2e 0f 1f 84 00 data32 nopw >%cs:0x0(%rax,%rax,1) >ffffffff8100017c: 00 00 00 00 > >and in 64-bit mode it has for an operand a 16-bit selector followed by >a >32-bit offset. > >Now, Intel SDM says also this: > >REX.W + FF /5 JMP m16:64 A Valid N.E. Jump far, absolute indirect, >address given in m16:64. > >And I don't think AMD supports a 64-bit offset. At least I don't see it >in the APM where it has only: > >JMP FAR mem16:16 FF /5 Far jump indirect, with the target specified by >a far > pointer in memory. >JMP FAR mem16:32 FF /5 Far jump indirect, with the target specified by >a far >pointer in memory. > >This is at least what I can see at a quick scan. I could ask around if >AMD actually supports that FF /5 with a REX.W prefix and it is not only >a documentation omission. > >HTH. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
