Hi,


The user process want to access the PHY memory via virtual address, the MMU will translate VA(virtual address) to PA(physical address) by using process's page table.

This page table must itself locate in PHY memory. Thus, when kernel need to handle the process page table, it must use another page table for MMU to access the process page table memory. So, what is the another page table used?

Read the info available from this link
http://linux-mm.org/

I was rather disappointed with it myself. It is more a random collection of odd fractions of the information. It has neither a good overview nor a consistent level of detail.

But it does have useful information. And I don't know a better source. And you seem to need some of that information.

I've been annoyed in other threads where experts have referred people to that page for specific advanced MM info you can't get there. But, until some better page is posted that one should be considered required reading before you start asking MM questions.

True.

Maybe I'm misunderstanding the question.

You'd need to really dig in the code to find out exactly which page of the kernel's page table contains the entry that maps any given page of a given process's page table. Is that really what you want to know?

Remember there is a 1 to 512 ratio (for 64-bit or PAE) between page table space and the space mapped by those page tables. So the overhead of remapping the pages tables for kernel access isn't very great.

Long ago, when I wrote my own 32-bit kernel for 486's, I double used the user level page directory as part of the kernel page table to minimize the space and time cost of that mapping. In a 486, the page directory had a format consistent enough with a page table that it worked very well to use the same physical page as both the user's page directory and the page table page used by the kernel to map the user's full page table.
I'm not sure whether all the new interesting features in page tables and page directories would create a problem for that double use trick. But I am pretty sure Linux and Windows never used that double use trick, even back when the newest available hardware presented no disadvantages for that trick.

I think at the very begining of booting linux, there is only one page table established in arch/i386/kernel/head.S. Then all child/grandchild page tables for later processes are copy & write from the very first page table. Right??

In another word, Does a process's page table has the entry which map's to the page table physical memory location?

IIUC, the usual (not all build variants) Linux memory management puts all page tables into the kernel virtual address space and puts the entire kernel virtual address space into every process's virtual address space.

So from a hardware definition of page tables, that does mean a process's page table maps itself.

A page table typically takes many pages, so you seem to be misunderstanding something where you said "the entry".

Did you read things at that site I suggested? I think that would have answered your question.

Thanks, I should read the reference through, and ask based on reference part.
Thanks for suggestion.

The currently-active page and segment tables are located using control registers in the CPU hardware, which only privileged programs can reference.

When Linux switches from one task to another, it reloads these registers with the appropriate pointer-values for this particular task.

Reloading the control-registers also causes the TLB (translation lookaside buffer) to be flushed.

When this has been done, all subsequent virtual-address translation that takes place on this CPU will use the new segment/page tables.

If it is necessary to modify the page or segment table entries for a task, the appropriate TLB entries must be invalidated, thus forcing the modified entries to be picked-up and used. The Linux memory manager also handles this.

Page and segment tables must be located in real-memory; it cannot be virtual (for what are, if you think about it, perfectly-obvious reasons...). But page-tables, at least, can be "absent." A page-fault can occur either because the page-table says the page is not there, or because the segment-table says the page-table is not there.

Ok, it reloads the registers... I think there must be some codes (instructions) to accomplish the reloads and switches. These codes must be locate in the memory. And CPU fetch these codes via page table too. What kind of page table it use when task switch and reload the register. Is it the current process's page table??

If you understand the basic concepts, my quote above answered your question before you asked it.

The 32-bit x86 hardware architecture includes some very complicated mechanisms for doing things like interrupt service and task switching, using kernel code that is not in the address space of the tasks interrupted and switched. But Linux and Windows don't use that stuff.

The kernel code is mapped into every process's page table so it is available at the same address before, during and after a task switch.

The 64-bit hardware architecture eliminates a lot of those complicated features that Windows and Linux weren't using, so a 64-bit OS pretty much has no choice but to handle those things roughly the way Windows and Linux do.

This is one of the reasons why Linux maps the virtual-address space out the way that it does: every process's address-space map includes not only the process's private storage, but also stuff that is in-common to every process. "Linux itself," for example, is mapped there, even though processes might well have no access to it.

You're correct to observe that the addresses in the control-registers must be real addresses, not virtual ones. Quite obviously, "the address of the current page-table" cannot be a virtual address...

In this way, the CPU can take an interrupt, handle it, and do a certain amount of subsequent processing no matter what address-space is currently mapped by the hardware. The idea is that it might even be able to take the interrupt, do what has to be done, and return right back to the currently-running process without having to do a VM-switch.

Modern CPU architectures are heavily "pipelined." The CPU might have five or six (or more) different instructions at various stages of execution at the very same time. Fundamental events, like switching from one address-space to another, force that pipeline to be flushed, and this is something that the operating system doesn't want to do very often.