diff --git a/content/call/index.md b/content/call/index.md
index 2d3e173..8cbd097 100644
--- a/content/call/index.md
+++ b/content/call/index.md
@@ -157,7 +157,7 @@ The loader does several things to run a program. To learn more, we strongly reco
 
 **1. Load program into a newly created address space** in memory.[^vm]
 
-[^vm]: We discuss virtual memory in a later chapter.
+[^vm]: We discuss virtual memory in a [later chapter](#sec-virtual-memory).
 
 * Read `a.out` file header for sizes of text, data segments.
 * Create new address space for program large enough to hold **text and data segments**, along with a stack segment.
diff --git a/content/vm/address-translation.md b/content/vm/address-translation.md
index 29dbec2..80d0df2 100644
--- a/content/vm/address-translation.md
+++ b/content/vm/address-translation.md
@@ -1,13 +1,14 @@
 ---
 title: "Address Translation"
-subtitle: Coming soon. Thanks for your patience!
 ---
 
-<!-- ## Learning Outcomes
+(sec-vm-address-translation)=
+## Learning Outcomes
+
+* Use a pre-populated page table to translate virtual addresses into physical addresses.
+* Define a page fault and identify when an address translation scenario triggers a page fault.
+* Explain, at a high-level, the operating system's role in address translation and handling page faults with context switches.
 
-* TODO
-* TODO -->
-(sec-memory-manager)=
 ::::{note} 🎥 Lecture Video
 :class: dropdown
 
@@ -18,65 +19,120 @@ subtitle: Coming soon. Thanks for your patience!
 
 ::::
 
-<!-- to facilitate **demand paging**.
+:::{note} Address translation
+:label: block-address-translation
 
+A "memory manager" (see [this section](#sec-memory-manager)) translates virtual addresses to physical addresses as follows:
 
-## Revisiting the Library Analogy
+1. A process requests a memory access at a given virtual address (VA).
+1. Translate the virtual address to the physical address:
+    * Extract virtual page number (VPN) from VA
+    * Access the **page table entr**y corresponding to this VPN to look up the corresponding physical page number (PPN).
+1. Construct the physical address (PA):
+    * If the corresponding page table entry is valid, obtain the PPN from the page table entry and construct the PA by concatenating the PPN and the page offset.
+    * If the corresponding page table entry is **not** valid, trigger a **page fault**. After the page is loaded from disk into memory, repeat this step.
+1. Access memory at the physical address in memory and return to the process.
 
-Book title like virtual address
-Library of Congress call number like physical address
-Card catalogue like page table, mapping from book title to call number
-On card for book, in local library vs. in another branch like valid bit indicating in main memory vs. on disk (storage)
-On card, available for 2-hour in library use (vs. 2-week checkout) like access rights
+:::
 
-## Visuals
+In this section we discuss:
 
-:::{figure} images/page-table.png
-:label: fig-page-table
-:width: 50%
-Each process has a page table.
-:::
+* How to do address translation when the data requested is in memory, i.e., no page fault occurs.
+* How to do address translation when the data requested is **not** in memory, i.e., a page fault occurs.
+* What is the "memory manager," i.e., the system performs address translation (see [this section](#sec-memory-manager)).
 
-:::{figure} images/page-tables-are-in-memory.png
-:label: fig-page-tables-are-in-memory
-:width: 60%
-Page tables are stored in memory.
-:::
+## Page Tables, Briefly
+
+A page table keeps tracks of the VPN-to-PPN mappings for a given process. There is one page table per process.
+
+* Each entry in a page table corresponds to a virtual page number (VPN) for this process. In this course, the number of entries in a process's page table is equivalent to the total number of virtual pages for the process.[^hierarchical-pt]
+* If a page is in memory, the entry is valid and has the corresponding physical page number. Otherwise, it may have garbage, and accessing this entry should trigger a page fault.
+
+[^hierarchical-pt]: We assume a single-level page table hierarchy in this course. In practice, multi-level (hierarchical) page tables are used to reduce the size of the page table. Read more in the [extra section](#sec-hierarchical-page-table).
+
+We discuss the fine-grained details of page tables in [another section](#sec-page-table).
+
+## Address Translation, Conceptually
+
+### Case I: Page Is In Memory
+
+Consider a scenario where a process has a 32-bit virtual address space, and physical memory is 16 KiB and paged into four 4 KiB pages. There are four steps to address translation, as shown by @fig-address-translation-i's animation. Fow now, conceptually, a page table entry is valid if it has a physical page number (PPN) and invalid if it is labeled "disk".
 
-:::{figure} images/address-translation-1.png
-:label: fig-address-translation-1
-:width: 70%
-Example of page table walk (no page fault).
+::::{figure}
+:label: fig-address-translation-i
+:alt: "Embedded slide deck animating address translation for virtual memory, Case I: the target page is in memory."
+:::{iframe} https://docs.google.com/presentation/d/e/2PACX-1vQOMr3azgvCiLNd6mZyisZqT4gs0-P6I7phPyt7o5KNOE3fJCqPJ-yiyyKixNPxbyMF0CjazcKaAxEH/pubembed?start=false&loop=false
+:width: 100%
+:enumerated: false
+:title: "Animation that steps through the enumerated text in this section about address translation . Access [original Google Slides](https://docs.google.com/presentation/d/1GtFuG_Oyo6V_ZrY37R5UM7arrzluN5nnuiUuSus-RLE/edit?usp=sharing)"
 :::
+Address Translation, Case I: The target page is in memory.
+::::
+
+:::{note} Explanation for @fig-address-translation-i
+:class: dropdown
 
-:::{figure} images/address-translation-2.png
-:label: fig-address-translation-2
-:width: 70%
-Example of page table walk: get VPN.
+1. **Program requests a memory access at a virtual address (VA).** Here, load byte @ address `0xFFFF F004` to register `t0`. The value `0xFFFF F004` is a virtual address (VA).
+2. **Translate the virtual address to physical address** (i.e., location in memory).
+    * Extract the virtual page number (VPN) from the VA. The lower 12 bits of each address are reserved for the page offset (4 KiB pages = $2^{12}$ B pages), so the VPN is the upper 20 bits of VA, or `0xFFFFF`.
+3. **Construct the physical address (PA).** The entry associated with VPN `0xFFFFF` has a valid page table entry. Access the entry for the physical page number (PPN, `0x2`) and concatenate it with offset `0x004` to construct physical address `0x1004`.
+4. **Access memory at the physical address in memory and return to the process.** Here, the byte @ address `0x1004` is read and returned to the  process.
 :::
 
-:::{figure} images/address-translation-3.png
-:label: fig-address-translation-3
-:width: 70%
-Example of page table walk: look up PPN.
+This case is predicated on our page table entry being valid. A valid page table entry means that the virtual page has a corresponding physical page number, and therefore the page is in memory. Next, let's explore when the page is _not_ in memory.
+
+### Case II: Page Fault
+
+We continue our scenario with the same process. Now, suppose that the next memory access triggers a page fault, as shown in @fig-address-translation-ii's animation.
+
+::::{figure}
+:label: fig-address-translation-ii
+:alt: "Embedded slide deck animating address translation for virtual memory, Case II: the target page is not in memory, triggering a page fault."
+:::{iframe} https://docs.google.com/presentation/d/e/2PACX-1vTbLQECEMErmE2XPTIZjqwzMUdTYvmZWxYvMa1yvFqvBQ7ZG645I9nZdE2N8S8LLmkNUP16f2174XRQ/pubembed?start=false&loop=false
+:width: 100%
+:enumerated: false
+:title: "Animation that steps through the enumerated text in this section about address translation. Access [original Google Slides](https://docs.google.com/presentation/d/1F5Y4renut4fcXZh05XArHGSJY4t_0QqvAhba5kAW8No/edit?usp=sharing)"
 :::
+Address Translation, Case II: The target page is not in memory, triggering a page fault. With demand paging, a page fault means the page is fetched from disk.
+::::
+
+:::{note} Explanation for @fig-address-translation-ii
+:class: dropdown
+
+1. **Program requests a memory access at a virtual address (VA).** Here, load byte @ address `0x6000 0030` to register `t0`. The value `0x6000 0030` is a virtual address (VA).
+2. **Translate the virtual address to physical address** (i.e., location in memory).
+    * Extract the virtual page number (VPN) from the VA. The lower 12 bits of each address are reserved for the page offset (4 KiB pages = $2^{12}$ B pages), so the VPN is the upper 20 bits of VA, or `0x60000`.
+3. **Construct the physical address (PA).**
+    * The entry associated with VPN `0x60000` does _not_ have a valid page table entry. An _invalid_ page table entry means that the physical page is not in memory.
+    * Ask the OS to perform an interrupt to request the page from disk (see details in [this section](#sec-memory-manager)).
+    * Once the page is loaded from disk into memory (about a million cycles later[^jim-gray]), resume the address translation.
+    * The entry associated with VPN `0x60000` (now) has a valid page table entry. Access the entry for the physical page number (PPN, `0x2`) and concanate it with offset `0x030` to construct physical address `0x2030`.
+4. **Access memory at the physical address in memory and return to the process.** Here, the byte @ address `0x2030` is read and returned to the  process.
+
+[^jim-gray]: Jim Gray's [analogy figure](#fig-3-locality) for your reference.
 
-:::{figure} images/address-translation-4.png
-:label: fig-address-translation-4
-:width: 70%
-Example of page table walk: look up page.
 :::
 
-:::{figure} images/address-translation-5.png
-:label: fig-address-translation-5
-:width: 70%
-Example of page table walk: read data from page.
+### Revisiting the Library Analogy
+
+Let's understand virtual memory using our [library analogy](#sec-library) of the memory hierarchy.
+
+* The book title is like a virtual address, and the [Library of Congress call number](https://ask.loc.gov/faq/396298) is like a physical address. We usually remember a book by its title (VA), and not its call number (PA).
+* The card catalog is like a page table, which maps from book title to call number. If we went straight to the bookshelves to find a book number _without_ the call number, we likely wouldn't find the book. So the card catalog (page table) is important.
+* The corresponding card entry in the catalog has useful information:
+  * Valid bit: Does the book exist in this library? (Is the page in memory?) Or do you need to request a hold and be notified when the book is available in the library? (Trigger a page fault and notify when page is loaded from disk into memory?)
+  * Access bit: Can you check out this book, or is it reference-only? (We discuss memory page access rights more in [this section](#sec-page-table).)
+
+This analogy breaks down slightly because the page table is a **page number** lookup, not an address lookup. But we hope the weak analogy helps.
+
+:::{tip} Quick Check
+
+See [Spring 2025 Lecture 34 Slide 30](https://docs.google.com/presentation/d/1HXo7Adnk8eJZ53UVngsSEhPoneA-H02Qfpn8BjaAs1I/edit?slide=id.g34f3c4927f7_0_15#slide=id.g34f3c4927f7_0_15) for a practice exercise.
+
 :::
 
 (sec-memory-manager)=
-## The OS: Virtual Memory
-
-asdf
+## The "Memory Manager"
 
 :::{hint} About the Operating System
 :label: sec-os-overview
@@ -88,6 +144,7 @@ The **operating system (OS)** is likely the single largest piece of software on
 
 Most of the details of the operating system (OS) are out of scope for this course. Here are the sections that describe the key OS functions you should know:
 
+* [Loader](#sec-loader)
 * [Heap Memory Management](#sec-heap-allocator)
 * [Context Switches](#sec-context-switch)
 * [Virtual Memory Management](#sec-memory-manager)
@@ -96,15 +153,46 @@ We hope a future version of these course notes will discuss the operating system
 
 :::
 
+:::{note} Text from an [earlier section](#sec-memory-hierarchy)
+```{embed} #block-hierarchy-management
+```
 
-:::{warning} What manages the memory hierarchy?
+:::
 
-The below text is from an [earlier section](#sec-memory-hierarchy). The "later section" mentioned is this one. :-)
+Virtual memory manages the two levels of the memory hierarchy represented by main memory and disk. The "memory manager" performs translation and data mangement and is a combination of hardware (in the CPU) and software (the OS).
 
-```{embed} #block-hierarchy-management
-```
+There is address translation hardware in the CPU; it is called a [memory management unit](https://en.wikipedia.org/wiki/Memory_management_unit). This hardware unit splits the virtual address into the virtual page number and offset within the page and accesses the page table. If the page is not currently in memory, the hardware raises a **page fault exception**.
+
+Upon this page fault exception, transfer control the **page fault exception handler**—a supervisor-level OS procedure that performs the following:
+
+* Initiates transfer between memory and disk.
+  * If out of memory, first select a page to replace in memory.
+  * If needed, write the outgoing page to disk.
+  * Load the requested page from disk into memory.
+* Perform a **context switch** so that another user process can use the CPU while the disk transfer happens.
+* Following the page fault, re-execute the instruction.
+
+:::{warning} Page faults are extremely expensive!
+
+On a page fault, the process cannot continue until the memory access finishes. If the physical page is not in memory, the page must be first fetched from disk and loaded into memory (and the page table must be updated), and _finally_ the instruction can be re-executed to successfully completes the memory access. The (time) cost of disk access [^jim-gray] means that page faults are extremely expensive—on the order of a million cycles.
+
+**Context switches** amortize the cost of page faults across all processes. To keep the CPU busy, the OS performs a context switch and runs another process—while the original process that triggered a page fault "waits." Then, when the page in question is finally loaded into memory, the OS performs another context switch back to the original process.
+:::
+
+## Demand Paging
+
+As mentioned in an [earlier section](#sec-loader), the OS also performs the **load** part of [CALL](#sec-call)—meaning, the OS loads a program into a new virtual address space and runs it. Upon starting this new process, what is its memory footprint? No matter what, the OS must allocate enough space in memory for a new page table for this process. But what about memory pages corresponding to data and instructions?
+
+Preloading in numerous pages for every new process is wasteful. For example, with tiny programs like "Hello World", most pages are never used, so allocating the full virtual address space to memory at startup (i.e., assign every virtual page to a physical page in memory) seems nonsensical.
+
+In a system that uses **demand paging**,[^demand-paging] a process begins execution with none of its pages in physical memory. In other words, all of its page table entries are invalid. Then, when a page is actually requested, load the page from disk into memory.
+
+:::{figure} images/demand-paging.png
+:label: fig-demand-paging
+:width: 60%
+Our VM abstraction allows a program to use the full virtual address space, but some programs use only a tiny amount of memory. **Demand paging** means that new processes have page tables that start with entries that are all invalid.
 :::
 
+Demand paging prevents over-allocating memory to a process (and thereby supports running many processes on a limited amount of memory), but the startup cost is high for new processes.
 
-Virtual memory manages the two levels of the memory hierarchy represented by main memory and disk.
- -->
+[^demand-paging]: Read more on Wikipedia about [demand paging](https://en.wikipedia.org/wiki/Demand_paging) and its counterpart, [anticipatory paging](https://en.wikipedia.org/wiki/Memory_paging#Anticipatory_paging).
diff --git a/content/vm/images/demand-paging.png b/content/vm/images/demand-paging.png
new file mode 100644
index 0000000..aeeb461
Binary files /dev/null and b/content/vm/images/demand-paging.png differ
diff --git a/content/vm/index.md b/content/vm/index.md
index e93ce0a..65d3445 100644
--- a/content/vm/index.md
+++ b/content/vm/index.md
@@ -176,17 +176,51 @@ Each VPN maps to a PPN. Virtual pages and physical pages are the same size, so t
 * A physical address is decomposed into a **physical page number (PPN)** and a **page offset**. For a 48-bit physical address with 4 KiB pages, the PPN is the upper 28 bits and the page offset is the lower 12 bits.
 * As shown in @fig-vpn-to-ppn, the address translation mechanism of virtual memory works regardless of whether physical memory is smaller _or_ larger than the virtual address space capacity.
 
-To translate a virtual address to a physical address:
+:::{hint} Quick Check
 
-1. First decompose the virtual address into VPN and page offset.
-1. Then, lookup the PPN corresponding to this VPN.
-1. Finally, construct the physical address by concatenating the PPN with the page offset.
-  a virtual page number to a physical page number. Keep the page offset the same.
+Assume a 32-bit machine with 8GiB of RAM and 16KiB pages.
+How many bits would there be for each of the following?
 
-A **page table** keeps track of the VPN-to-PPN mappings for a given process (for Step 2 above). There is one page table per process.
+1. Page offset
+1. Virtual page number (VPN)
+1. Physical page number (PPN)
 
-:::{note} Pages are the memory unit of virtual memory
+:::
+
+:::{note} Show Answer
+:class: dropdown
+
+1. Page offset: = $\log_2$(16 KiB) = $\log_2(2^4 \times 2^{10})$ = 14 bits
+
+1. VPN = 32 - 14 = 18 bits
+
+1. PPN = $\log_2$(8 GiB) - 14 = $\log_2(2^3 \times 2^{30}) - 14$ = 33 - 14 = 19 bits
+
+:::
+
+:::{hint} Quick Check
+
+Suppose we have a 32-bit virtual address space with 16 GiB DRAM and 4 KiB pages. True or False?
+
+1. There are $2^{32}$ / $2^{12}$ = $2^{20}$ Virtual Page Numbers.
+2. There are $2^{4} \times 2^{30} / 2^{12} = 2^{22}$ Physical Page Numbers.
+3. Virtual addresses are 32-bits, where the bottom 12 bits are used to reference page offset.
+4. Both the virtual page size and the physical page size are 4 KiB.
+:::
+
+:::{note} Show Answers
+:class: dropdown
+
+1. True
+1. True
+1. True
+1. True
+:::
+
+:::{warning} Pages are the memory unit of virtual memory
 
 On a given machine, virtual pages and physical pages are the **same size**. For a given virtual-physical address mapping, the virtual page number and physical page numbers may be different, but the virtual page offset and physical page offset are **identical**.
 
 :::
+
+We discuss this virtual-to-physical address translation in the [next section](#sec-vm-address-translation).
diff --git a/content/vm/page-table.md b/content/vm/page-table.md
new file mode 100644
index 0000000..291a87b
--- /dev/null
+++ b/content/vm/page-table.md
@@ -0,0 +1,37 @@
+---
+title: "Page Tables"
+subtitle: Coming soon. Thanks for your patience!
+---
+
+(sec-page-table)=
+## Learning Outcomes
+
+* TODO
+* TODO
+
+::::{note} 🎥 Lecture Video
+:class: dropdown
+
+:::{iframe} https://www.youtube.com/embed/Rc73MpGzZuM
+:width: 100%
+:title: "[CS61C FA20] Lecture 29.5 - Virtual Memory I: Page Faults"
+:::
+
+::::
+<!-- :::{figure} images/paged-memory-1.png
+:label: fig-paged-memory
+:width: 50%
+Physical memory broken into pages.
+:::  -->
+
+<!-- :::{figure} images/page-table.png
+:label: fig-page-table
+:width: 50%
+Each process has a page table.
+:::
+
+:::{figure} images/page-table.png
+:label: fig-page-table-1
+:width: 50%
+Each process has a page table.
+::: -->
diff --git a/content/vm/page-tables-hierarchical.md b/content/vm/page-tables-hierarchical.md
index 42a25b6..46f57fa 100644
--- a/content/vm/page-tables-hierarchical.md
+++ b/content/vm/page-tables-hierarchical.md
@@ -8,6 +8,7 @@ subtitle: This content is not tested
 * TODO
 * TODO -->
 
+(sec-hierarchical-page-table)=
 ::::{note} 🎥 Lecture Video
 :class: dropdown
 
@@ -16,4 +17,4 @@ subtitle: This content is not tested
 :title: "[CS61C FA20] Lecture 30.1 - Virtual Memory II: Hierarchical Page Tables"
 :::
 
-::::
\ No newline at end of file
+::::
diff --git a/myst.yml b/myst.yml
index 4c336e0..9df7d84 100644
--- a/myst.yml
+++ b/myst.yml
@@ -253,7 +253,7 @@ project:
           children:
           - file: content/vm/index.md
           - file: content/vm/address-translation.md
-          - file: content/vm/page-faults.md
+          - file: content/vm/page-table.md
         - title: "L36: The TLB, Page Table Walks"
           children:
           - file: content/vm/tlb.md