questions on high half kernel II

[asmboozer]

finaly, i got why there should set two page dir when gdt trick used.

1, to set page dir[0], it is because when in protected mode,
a)whether paging enabled or not ,the cpu always use CS:EIP to look for the physical address,
which is cs->baseaddress + eip(the offset from baseaddr) ,

this is linear address, when paging is diabled, it's also the physical address.

b)when paging enabled, there is one more translation step,which use the page table to translate the linear address to physical address.

consider the code below:

Code: Select all

  __asm__ volatile (  "mov %0, %%eax\n"
                        "mov %%eax, %%cr3\n"
                        "mov %%cr0, %%eax\n"
                        "orl $0x80000000, %%eax\n"
                        "mov %%eax, %%cr0\n" :: "m" (kernelpagedirPtr));

after mov cro,eax,
assume the CS:EIP is 08:0xc01000xx,
if page dir[0] is not set,

08->baseaddress = 0x40000000;
the linear address of EIP:08->baseaddress+0xc01000xx = 0x001000xx.

now the next translation step is to look for the page table dir, it would fail.

the same reason can explain why page dir[768] must be set.

look at the gdt_flush call.
in this call, there is a jmp,

Code: Select all

c01002f4 <gdt_flush>:
c01002f4:       0f 01 15 00 40 10 c0    lgdtl  0xc0104000
c01002fb:       66 b8 10 00             mov    $0x10,%ax
c01002ff:       8e d8                   movl   %eax,%ds
c0100301:       8e c0                   movl   %eax,%es
c0100303:       8e e0                   movl   %eax,%fs
c0100305:       8e e8                   movl   %eax,%gs
c0100307:       8e d0                   movl   %eax,%ss
c0100309:       ea 10 03 10 c0 08 00    ljmp   $0x8,$0xc0100310

this call is made after the newer gdt(zero-based gdt) is used.
so ljmp 8:0xc0100310, would be translated as
8->baseaddress = 0;
0+0xc0100310 = 0xc0100310,

if there was no matched page dir ,this address 0xc0100310 would not be translated into physical address.

that's all.

hope my english can be understood by you all.

thanks you all anyway.

[asmboozer]

i'm having trouble understanding your responses as well, but i will try again:

2, if ignore the all the address of concept, they last point to the same physical memory address? if so I do not care what the address type it is. only where is the physical address I care about.

3,as the info cpu dumps the eip register,
the value of it is 0xc0xxyyzz when the exception occurs.

i think the cpu would translate the address into right physical address because now the paging is enabled. and the page directory is rightly set.

as i thought... this shows a fundumental misunderstanding of the difference -- let me try to explain it better:

2, if ignore the all the address of concept, they last point to the same physical memory address? if so I do not care what the address type it is. only where is the physical address I care about.

while the addresses eventually do become physical addresses, you can never ignore the different types, because they are generated differently, and if you are not translating them correctly, they will not point to the same addresses

i think the cpu would translate the address into right physical address because now the paging is enabled. and the page directory is rightly set.

no, the CPU doesnt care what the physical address is, it will give an error only if the page directory is wrong -- and in this case the page directory is not rightly set, because you have set the wrong page directory:

3,as the info cpu dumps the eip register,
the value of it is 0xc0xxyyzz when the exception occurs.

no -- EIP contains a logical address, which is never seen by the page tables --

first:
EIP -- contains -- 0xc012 3456

modified by GDT entry:
0xc012 3456 + CS.base = 0x0012 3456

lookup in page tables: 0x0012 3456 -- this is the address which must be mapped into the page tables, and you dont have it mapped -- the high address never reaches the page tables

the entry in the page table must then map the address 0x0012 3456 to the physical address 0x0012 3456 where your code must be



later after you modify the GDT to alter your CS.base, and reload it with jmp cs:here, then it will be like this:

first:
EIP -- contains -- 0xc012 3456 -- same as before

modified by GDT entry: -- cs.base has changed, and is now 0
0xc012 3456 + CS.base = 0xc012 3456

lookup in page tables: 0xc012 3456 -- this is the address which must be mapped into the page tables

the entry in the page table must then map the address 0xc012 3456 to the physical address 0x0012 3456 where your code must be

only now are you using the higher half page tables



hopfully this will help -- try to follow what i said on paper, and look at figure 3-1 in the intel volume 3 (tried to find an equivelant in AMD for a different perspective, but they didnt seem to have one)

thanks.
last i think of that the intel cpu always use cs:eip to look for the physical address.
i think this is most important, but I have always ignore the fact.

thanks ya.

[Colonel Kernel]

thanks.
last i think of that the intel cpu always use cs:eip to look for the physical address.
i think this is most important, but I have always ignore the fact.

thanks ya.

This is why I discourage the use of the GDT trick. With the plain HigherHalfBareBones you can just ignore segmentation almost completely. Sorry if my lax use of the terms "physical address" and "virtual address" confused you.

[asmboozer]

This is why I discourage the use of the GDT trick. With the plain HigherHalfBareBones you can just ignore segmentation almost completely. Sorry if my lax use of the terms "physical address" and "virtual address" confused you.

yes, it 's because the plain higherhalfbarebones is with zero-based segmentation.

even consider the segmentation, the physical address of both method(one consider the segmentation, another only paging ) is same. the segmentation is transparent in this case as if there were no segmentation address translation. only the direct paging translation.