操作系统代写 CS 444 HW4: Experimenting with the x86 MMU

HW4: Experimenting with the x86 MMU

Assigned:  15 November 2017                                   Due: class time 29 November 2017

 

 

There is one page table (KPT0 for kernel PT#0) for this 4M system, itself mapped into the address space starting at 0x52000 (in the Tutor area.)

 

Make a script to show your work, as follows (you can edit out extraneous stuff after the fact if it gets too messy): List the script and mark it up with your analyses, or edit in comments if you prefer.

 

  1. With a fresh system (reboot to make sure), dump the first 4 PTEs and analyze them (status bits, what VA->PA translation they do).

 

  1. Find and dump the first 4 PTEs for the Tutor program and analyze them. The Tutor program starts at VA 50000. Find some PTEs for pages that have never been touched since system reset, above VA 50000, i.e. after Tutor.

 

We can play with pages 0-20 or so without much worry about necessitating a reset, because these are left over from being bootstrap scratch memory. All the sensitive data is above 0x50000, including the interrupt vector table.

 

  1. Set page 3 as valid but not yet referenced. Then do a read on it, check the PTE, then a write, check the PTE and interpret your findings.

 

  1. Now set page 3 as invalid (not present) and try reads and writes. You see that nothing special has happened. That’s because the PTE in the TLB is still showing the page as present, and the MMU checks the TLB before looking at memory PTs.

 

  1. Writing a value in the CR3 registers flushes the TLB, i.e., makes it drop all its cache entries. This can be done using the Tutor register-set command. Use the same old CR3 value, of course, or expect to reboot, for example: “Tutor> rs cr3 51000”. Do this and retry 4.  You should see a page fault, exception 14. Use “rd all” to see CR2, the “linear address”, which is the address that causes the page fault.

 

Note on linear addresses (LAs): We have avoided talking about x86 segmentation, and we don’t want to start now.  So just be aware that VA’s are actually mapped to LAs by segmentation, and LAs to PAs by paging.  Thus “the memory address” involved in a page fault is a LA.  On the SAPC, the rule is VA = LA – 0xc0000000 = PA for all addresses.  For example, VA 12345 is LA 0xc0001 2345 and PA 12345.  So if address 12345 causes a page fault, CR2 will contain 0xc001 2345.

 

  1. Write the appropriate PTEs to make both VA 3000 and VA 5000 refer to PA 5000. Show that it is working by writing once and reading twice. (After you modify the PTE, use the ms command to modify a location in PA 5000. Read the location in VA 3000 and VA 5000. They should yield the same value.)

 

  1. As a final suicidal action, wipe out the PDE (page directory entry) governing the PT we’re using. This PDE is accessible at VA 51c00. Is the PDE cached?

[VA 51c00–why this address? Note that the whole SAPC memory is located in 0xc000 0000-0xc03f ffff in linear address space, and 0xc000 0000 is 3/4 of the way through the 32-bit LA space.

The page directory starts at 51000, and each of its PDEs (1K in number) rules 4M of LA space.  The PDE for this region is 3/4 of the way down the PD, at 0x51000 + 3/4*4*1K = 0x51c00.]

 

Be nice and ~r at the end of your session!

USER  PROGRAM
TUTOR PROGRAM