I do not understand paging at all, Please help!

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
gideond
Posts: 17
Joined: Wed Oct 23, 2013 9:02 am

I do not understand paging at all, Please help!

Post by gideond »

Hey folks,

I've been reading about paging for 2 weeks now and I really don't get it.

There are bits I get and other bits I don't get. (Pun intended)

I'll just post some questions from the osdev wiki on paging: http://wiki.osdev.org/Paging

It says:
Many prefer to map the last PDE to itself. The page directory will look like a page table to the system. To get the physical address of any virtual address in the range 0x00000000-0xFFFFF000 is then just a matter of:

Code: Select all

// All in all I don't understand even slightly where the MMU is in all of this and when does it kick in? 
// If the address translation is transparent to code then the function below doesn't make sense to me at all!
void * get_physaddr(void * virtualaddr)
{
    //So this means currently the last page dir entry is mapped to itself?
    //so this virtualaddr can represent a 0 to 4GB address right,
    //but it's virtual, I mean, it really maps to a physical address so how do the below lines works?
    unsigned long pdindex = (unsigned long)virtualaddr >> 22; //this is like dividing by 2^22 right?
    unsigned long ptindex = (unsigned long)virtualaddr >> 12 & 0x03FF; // why divide by 12 and & with 1023 ?
    //both these operations don't make sense at all, you have a virtual address that is mapped to a physical addr
    //WHEN? does the MMU kick in and really translate these? If they are transparent to code
    //how will bit twiddling ever get the pde/pdt ? The actual physical addresses are something else right? 
 
    unsigned long * pd = (unsigned long *)0xFFFFF000; //I understand the address is the last 1KB in 0-4GB
    //but again, that's a virtual address right? Wouldn't the MMU translate that into a physical address?
 
    unsigned long * pt = ((unsigned long *)0xFFC00000) + (0x400 * pdindex);
    //again this looks as if the pde and pdt were in virtual memory, or the virtual addresses are NOT virtual addresses?
    // Or the MMU doesn't translate these? So when does it translate them! :/
 
    return (void *)((pt[ptindex] & ~0xFFF) + ((unsigned long)virtualaddr & 0xFFF));
}
As you can see I'm thoroughly baffled. There is probably something simple that just hasn't clicked for me, but I have done my research and I've never been so bloody frustrated before! Please help.

Regards,
Gideon
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: I do not understand paging at all, Please help!

Post by Combuster »

// All in all I don't understand even slightly where the MMU is in all of this and when does it kick in?
// If the address translation is transparent to code then the function below doesn't make sense to me at all!
Nope, nope, nope.

What good is "transparency" in paging if you think it means everything should be identity-mapped? The whole point about paging is that application code does not need to care which physical memory is used, as long as it has a virtual address of something that behaves like physical memory. This all breaks in the context of the kernel, which is actually responsible for not having applications care - and thus has to do the job of managing physical memory and virtual addresses, and pointing the right addresses at the right memory.

The kernel still runs with paging enabled so that it too can enjoy the advantages of it, but it still needs access to the page tables so that it can do the relevant management, and therefore you need to have virtual addresses pointing to page tables. This method is just one of those, but it also happens to be the most popular one.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
gideond
Posts: 17
Joined: Wed Oct 23, 2013 9:02 am

Re: I do not understand paging at all, Please help!

Post by gideond »

Combuster wrote:
The kernel still runs with paging enabled so that it too can enjoy the advantages of it, but it still needs access to the page tables so that it can do the relevant management, and therefore you need to have virtual addresses pointing to page tables. This method is just one of those, but it also happens to be the most popular one.
Thanks very much for your answer.


Q1 > Does this mean each process running can have paging off/on? Do they also have individual mappings?
Q2 > From the OSDev article, it seems like 4GB of virtual memory is mapped sort of "in-line" to the page directory and page entries. Or maybe I'm just seeing it wrong.

> unsigned long * pt = ((unsigned long *)0xFFC00000) + (0x400 * pdindex);
What is 0xFFC00000 for? And if I can get to any page dir entry like this then should mean that if a userspace app did this "unsigned long * pd = (unsigned long *)0xFFFFF000;" which gets the last page dir entry then it should ideally fail right, because it points to the address of the PDE (and is marked kernel). OR, I wonder if paging is a per process thing?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: I do not understand paging at all, Please help!

Post by Brendan »

Hi,
gideond wrote:Q1 > Does this mean each process running can have paging off/on? Do they also have individual mappings?
Each processor is separate. If you want to (and have enough CPUs); you can have some CPUs in real mode, some in protected mode with paging off, some in protected mode with paging on, and some in long mode (with paging on), all at the same time. Of course it's much easier to have all CPUs operating in the same mode, and much easier to have paging enabled (or disabled) in all CPUs.
gideond wrote:Q2 > From the OSDev article, it seems like 4GB of virtual memory is mapped sort of "in-line" to the page directory and page entries. Or maybe I'm just seeing it wrong.
Tutorials are tutorials. If a tutorial did things like a real OS would, then the tutorial would end up too complex for beginners to learn from. Identity mapping 4 GiB is a short-cut that makes it easier to understand (but you wouldn't do that for a real OS).
gideond wrote:> unsigned long * pt = ((unsigned long *)0xFFC00000) + (0x400 * pdindex);
What is 0xFFC00000 for?
Before you understand what that code is doing, you need to understand paging (in general), and then understand what happens when the page directory entry points to the page directory itself (this creates a mapping of all of the virtual address space's paging structures). 0xFFC00000 would be the virtual address for the "mapping of all paging structures".
gideond wrote:And if I can get to any page dir entry like this then should mean that if a userspace app did this "unsigned long * pd = (unsigned long *)0xFFFFF000;" which gets the last page dir entry then it should ideally fail right, because it points to the address of the PDE (and is marked kernel).
Yes - you'd prevent that by marking the "mapping of all paging structures" (and everything else in kernel space) as "supervisor only" in the paging structures, so that code running at CPL=3 can't access any of it.
gideond wrote:OR, I wonder if paging is a per process thing?
Paging is normally a per-process thing (each process gets its own virtual address space; where the kernel-space is mapped into all virtual address spaces).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply