identity mapped paging (Vaibhav Jain)

Vaibhav Jain vjoss197 at gmail.com
Tue Apr 17 06:37:13 EDT 2012


On Fri, Apr 13, 2012 at 2:15 AM, Vaibhav Jain <vjoss197 at gmail.com> wrote:

>
>
>> > I am not clear about the use of identity mapped paging while paging is
>> > being enabled by the operating system. Also I don't understand at what
>> > point are the
>> > identity mappings no longer useful.According to this article
>> > http://geezer.osdevbrasil.net/osd/mem/index.htm#identity - "The page
>> > table
>> > entries used to identity-map kernel memory can be deleted once paging
>> > and
>> > virtual addresses are enabled." Can somebody please explain?
>> >
>>
>> Identity mapping is when VA(Virt Address)=PA(Physical address).
>>
>> So basically when you set up your page tables you need to make sure they
>> map identically. This is very easily done if you consider each 4KB block as
>> a page beginning from location 0 upto whatever you've found to be the
>> highest memory available either thru BIOS or GRUB.
>>
>> Remember that while setting up your PTEs and PDE every address is a
>> physical one. So if you thought that your kernel would be linked initially
>> to a higher VA since you would remap it to a lower memory physically then
>> that would be WRONG!. Without PTEs and PDEs installed don't do that!.
>>
>> Why would you want it? Well for a simple reason, when your kernel starts
>> to boot there's no translator,(No PTEs/PDEs and the Paging Enabled bit of
>> processor is also cleared AFAIK just after the BIOS is done), yet since
>> you've not enabled your processor for that but you'll be doing that in a
>> moment.
>>
>> So let's say you made your kernel to be linked to higher VA like 3Gigs.
>> Now the addresses would be generated beginning 3Gigs however you still
>> don't have the Page tables installed since your kernel just started. So in
>> that case the address is the physical address. And if you've not loaded
>> your kernel beginning 3Gigs then it would definitely come crashing down.
>>
>> To avoid the crash in case you made your kernel to link to higher half of
>> the memory, you can use GDT trick since segmentation is always on and you
>> can make the overflow of the address addition to translate to a lower
>> physical memory even if paging is not enabled yet. Thus it is possible to
>> load the kernel at lower memory addresses while the linkage would be for
>> higher VMA. And once your PTEs/PGD are enabled then you can use those
>> instead of the GDT trick.
>>
>> Here's a link to that http://wiki.osdev.org/Higher_Half_With_GDT
>>
>> > Thanks
>> > Vaibhav Jain
>>
>
>
> Hi,
>
> Thanks for replying but I am still confused. I continued reading about
> this thing and what
> I have understood is the following :
> After the kernel executes the instruction to enable paging the instruction
> pointer will contain the
> address of the next instruction which will now be treated as a virtual
> address. So for the next instruction to be executed
> the page table should map this address to itself.
> Please correct me if I am wrong.
> I am confused by the point about linking  the kernel to higher address.
> Could you please put that in a step by step manner
> to make it clear what  happens before paging is enabled and what happens
> after that.
> Also, please explain at what point during the execution of kernel code are
> the identity-mapped addresses no longer useful ?
>
>
>
>
> Thanks
> Vaibhav
>
Hi,

I am somewhat understanding your point. But I have some other queries now
in my mind.

If the kernel is linked to 3Gigs is there a way other than the GDT trick.?

In fact I am wondering that if the kernel is linked to 3Gigs and Grub loads
it at 1MB physical, how will even the first instruction of kernel
execute ?  I mean if all the address generated by kernel are above 3 Gigs
and paging is not enabled how will it start
running ?

Thanks
Vaibhav Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120417/dfdaa0be/attachment-0001.html 


More information about the Kernelnewbies mailing list