Query regarding x86_64 purgatory and IA32-e compatibility mode
Vivek Goyal
vgoyal at redhat.com
Fri Oct 26 09:19:34 EDT 2012
On Thu, Oct 25, 2012 at 08:14:58PM -0700, Eric W. Biederman wrote:
[..]
> > 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?
>
> /* 0x10 4GB flat code segment */
> .word 0xFFFF, 0x0000, 0x9A00, 0x00AF
>
> The high 16bits of that are:
> 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
> 0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 1
>
> Since L is bit 21 I read that as L=1.
>
> I don't know how you see L=1 there.
My bad. I did not take care of little endianness and read the bits in
reverse order.
0x00AF
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 0 0 0 0 0 0 1 0 1 0 1 1 1 1
And concluded that bit 21 is 0.
>
> The transition happens in entry64-32.S
> We get there via:
> jmp *rip(%rip)
>
> The default value of rip is entry32.
>
> That is where we clear bit 21 in
> ljmp *lm_exit_addr(%rip)
Ok, now I understand. In entry64-32.S we load a different GDT
where bit 21, L = 0. Hence long jump will put it in compatibility
mode.
0x00CF
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 1
Thanks for explaining this.
Thanks
Vivek
More information about the kexec
mailing list