2

I am studing operating systems and I have one question. Does a virtual address always translates to a physical one and if so why ?

cs_student3438779
  • 35
  • 5

2 Answers2

3

No.

You can see this similarly to physical memory. If your CPU can address like 64 GiB of memory (as with x86 and PAE), are you required to have 64 GiB of memory installed? No.

If you have an (x86) instruction addressing memory, like

mov eax, [1234h]

the double word at the virtual address 1234h = 0x1234 is attempted to be accessed. Now, roughly the following happens:

  1. The page table is checked whether it defines a corresponding page frame for the page addressed by 0x1234.

  2. If not, a page fault is raised. In this case, the virtual address 0x1234 does not translate to a physical one.

  3. If yes, the MMU calculates the physical address from the virtual address and returns the double word located there. The execution flow proceeds normally.

After all, not all pages are necessarily mapped to page frames, i.e., physical memory. This case is indicated by a page fault, which is handled by a page fault handler.
You should also read this on how paging works.

Community
  • 1
  • 1
cadaniluk
  • 15,027
  • 2
  • 39
  • 67
  • 2
    Common reasons for page faults to occur: the requested page has been moved to disk ("paging file" or "swap partition") to free up RAM for use by other programs, or the requested address is bogus and hasn't been mapped to anything. In the latter case, the OS will typically kill the process with an error such as "invalid page fault", "access violation", or "segmentation fault". – Wyzard Nov 18 '15 at 07:13
0

In spite of the numerous questions about page tables asked by students here (who apparently have the same useless textbook), the answer is NO.

When you access memory location the basic process followed is:

  1. Extract the logical page number from the address.

  2. Locate the page table entry corresponding to the page table. If the system uses nested page tables, there will be multiple lookups here.

  3. Check to see if a table entry exists at all. (Yes, readers of bad textbooks, the page table does not have to span the entire logical address space). If there is no page table entry for the address, the CPU triggers usually triggers a trap.

  4. Inspect the page table entry. Does it refer to a page mapped to the address space. If not, the CPU usually triggers a trap. Usually, the first page in the address space has a page table entry without having a page mapped to it so that applications can catch references to NULL pointers.

  5. Inspect the page table entry. Is the page mapped to memory?

If not, the CPU triggers a page FAULT (not a trap). The CPU responds to the fault by finding where the memory is stored on disk, loading it into physical memory, and updating the page table entry so that it points to that physical memory location. The CPU restarts the instruction that caused the trap.

One additional step (not part of your question) is the CPU checks the page table to ensure the type of access (read/write/execute) being attempted is permitted by the access mode (e.g., kernel/user/ ...).

There are several places in this process that can trigger an exception (fault or trap).

Am_I_Helpful
  • 18,735
  • 7
  • 49
  • 73
user3344003
  • 20,574
  • 3
  • 26
  • 62
  • You shouldn't claim that they *apparently have the same useless textbook*! – Am_I_Helpful Nov 18 '15 at 14:36
  • Most of this answer is good, except for: "the CPU responds to the fault by finding where the memory is stored on disk, loading it into physical memory, and updating the page table entry so that it points to that physical memory location." Actually, the CPU starts running the operating system's page-fault handler, which (typically) does those things. The CPU itself does not have built-in code for communicating with a disk controller to read from a paging file or swap partition. – Wyzard May 14 '16 at 13:13