KEMBAR78
Answers Lab2 | PDF | Kernel (Operating System) | Pointer (Computer Programming)
Scribd
Upload
697 views2 pages

Answers Lab2

This document contains the answers to Lab 2 questions for the 6.828 Operating Systems course at MIT. It discusses: 1) The appropriate type for a variable used to dereference a pointer returned from a function is uintptr_t, not physaddr_t. 2) The page directory has been filled with mappings for the top 4MB of physical memory, the kernel space section, and kernel stacks. 3) The CPL bits and permission bits in the CS register protect the kernel's memory from user programs. 4) The maximum physical memory supported is 256MB due to the kernel virtual address space layout. 5) Managing 256MB of physical memory would require 3MB of overhead for the PageInfo

Uploaded by

Long Nguyen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
697 views2 pages

Answers Lab2

This document contains the answers to Lab 2 questions for the 6.828 Operating Systems course at MIT. It discusses: 1) The appropriate type for a variable used to dereference a pointer returned from a function is uintptr_t, not physaddr_t. 2) The page directory has been filled with mappings for the top 4MB of physical memory, the kernel space section, and kernel stacks. 3) The CPL bits and permission bits in the CS register protect the kernel's memory from user programs. 4) The maximum physical memory supported is 256MB due to the kernel virtual address space layout. 5) Managing 256MB of physical memory would require 3MB of overhead for the PageInfo

Uploaded by

Long Nguyen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

LONG NGUYEN

6.828 - OPERATING SYSTEMS


FALL 2018

LAB 2 ANSWERS

1) Assuming that the following JOS kernel code is correct, what type should
variable x have, uintptr_t or physaddr_t?

It's clear that x should be uintptr_t, since value, the pointer returned
by return_a_pointer(), was dereferenced in the third line and set to 10.
We know that we can't "sensibly dereference a physical address".

2) What has been filled in the page directory?

1023: 0xFFC00000; page table for top 4MB of physical memory.


960: 0xF0000000; KERNBASE, beginning of kernel space section.
959: 0xEFC00000; kernel stack.
958: 0xEF800000; kernel stack.
957: 0xEF400000; kernel pgdir.
...
0: 0x00000000.

3) Why will user programs not be able to read or write the kernel's memory?
What specific mechanisms protect the kernel memory?

We have the CPL bits in the CS register that designate whether we're in
user or kernel mode, and this protects the kernel space from the user
program. They must have the appropriate permission bits if they want
to read and write the kernel's memory. Furthermore, permissions are
granted depending on the half of the address space that we're working in.
This is specific to the kernel or the user program.

4) What is the maximum amount of physical memory that this operating system
can support? Why?

256 megabytes. Note that the kernel virtual addresses begin at KERN-
BASE (0xF0000000) and end at 0xFFFFFFFF. The difference between the two
is 268435455 bytes, or 268 megabytes. This was already mentioned in
pmap.h.

5) How much space overhead is there for managing memory, if we actually


had the maximum amount of physical memory? How is this overhead broken down?

For managing memory, we use PageInfo structs. Each of these structs has a
32-bit pointer to the next page on the free list and a 16-bit integer
for the pp_ref. Thus, there are 48 bits per PageInfo struct. Given that we
have 256MB of physical memory, we have 62500 pages. 62500 * (32 + 16) =
3 megabytes exactly. Not too bad for mapping memory at all.

6) What makes it possible for us to continue executing at a low EIP between


when we enable paging and when we begin running at an EIP above KERNBASE?
Why is this transition necessary?

jmp *%eax allows us to go from a low EIP to a high EIP above KERNBASE. This
transition is necessary because our kernel will need to be at high
virtual addresses for actual execution. Also, this is possible because
we mapped VAs [0, 4MB) to the exact same PAs as well for bootstrapping.
Thus, it still works.
CHALLENGE PROBLEM DISCUSSION

For my challenge problem, I decided to extend the JOS kernel monitor with the
ability to display the physical page mappings (or lack thereof) for a
given range of virtual/linear addresses in the current address space.
You can run this extension through a 'showmappings x y', ex.
'showmappings 0x3000 0x5000'. The code can be found in monitor.c, with
the same structure in implementation as mon_backtrace was done for Lab 1.

My extension gives the following output for easy displaying of mappings.

Virtual address f5f55000 maps to the page at physical address 5f55000.


Virtual address f5f56000 maps to the page at physical address 5f56000.
Virtual address f5f57000 maps to the page at physical address 5f57000.
Virtual address f5f58000 maps to the page at physical address 5f58000.
Virtual address f5f59000 maps to the page at physical address 5f59000.

So on and so forth.

You might also like