Query regarding x86_64 purgatory and IA32-e compatibility mode
Vivek Goyal
vgoyal at redhat.com
Thu Oct 25 16:54:08 EDT 2012
Hi Eric,
I am reading up x86_64 purgatory code to understand how transition to
32bit protected mode happens.
My understanding is that we enter in purgatory_start (setup-x86_64.S).
Then we jump to entry64 in entry64.S.
We run following code in arch/x86_64/entry64.S
movq $stack_init, %rsp
pushq $0x10 /* CS */
pushq $new_cs_exit
lretq
new_cs_exit:
/* Load the registers */
movq rax(%rip), %rax
movq rbx(%rip), %rbx
movq rcx(%rip), %rcx
movq rdx(%rip), %rdx
movq rsi(%rip), %rsi
movq rdi(%rip), %rdi
movq rsp(%rip), %rsp
movq rbp(%rip), %rbp
movq r8(%rip), %r8
movq r9(%rip), %r9
movq r10(%rip), %r10
movq r11(%rip), %r11
movq r12(%rip), %r12
movq r13(%rip), %r13
movq r14(%rip), %r14
movq r15(%rip), %r15
Will above lretq call not switch us in compatibility mode (from 64bit
mode)? We have taken a long jump and our new CS seems to have L bit
0.
Following is our gdt.
gdt: /* 0x00 unusable segment
* 0x08 unused
* so use them as the gdt ptr
*/
.word gdt_end - gdt - 1
.quad gdt
.word 0, 0, 0
/* 0x10 4GB flat code segment */
.word 0xFFFF, 0x0000, 0x9A00, 0x00AF
/* 0x18 4GB flat data segment */
.word 0xFFFF, 0x0000, 0x9200, 0x00CF
gdt_end:
I see that bit 21 in second doubleword is 0. IIUC, that means that we
will switch to compatibility mode. If yes, we are still continuing to
use 64bit instructions and continue to access registers (rip, r8-15)
which are available in 64bit mode only. Is this correct? How does this
work?
Thanks
Vivek
More information about the kexec
mailing list