Here are the bits needed:
hardware 1 - valid
2 - not-read-only
software 3 - really-valid
4 - really-not-read-only
5 - referenced
6 - dirty
Given the page for which the fault occurred, and the
type of access attempted, the page table entries are updated
as follows, when a page fault occurs:
if the page is marked valid
if the page is marked not-read-only
-- this should never happen
else the page is not marked not-read-only
if the access was read
-- this should never happen
else the access was write
if the page was marked really-not-read-only
-- this is a soft page fault
mark the page not-read-only
mark the page dirty
else
-- this is a real protection violation
endif
endif
endif
else the page is marked invalid
if the page is marked really valid
-- this is a soft page fault
mark the page valid
mark the page referenced
else
-- this is a real page fault
-- after some page is replaced and the new
-- page is read in from disk
leave the page marked not valid
mark the page read-only
mark the page really-valid
mark the page not referenced
mark the page not dirty
endif
endif
The question: What are the significant differences between these alternatives? Would you expect performance differences? Would you expect implementation problems with one alternative that are solved by the other?
If segment faults are reported when a reference is made to a byte in a segment with an invalid descriptor, that assumes that the descriptor is already loaded in one of the four descriptor registers. Thus, it will not be immediately obvious what descriptor in the program base segment had been loaded in the descriptor register. This problem can be solved by having the segment fault handler do a linear search of the program's base segment to find and update the descriptor that had been loaded in the descriptor register.
If segment faults are reported when an attempt is made to load a segment descriptor from the base segment into one of the four descriptor registers, it is possible that faults may be reported prematurely and even unnecessarily (the latter is possible if a segment register is loaded with an invalid descriptor that is never used). On the other hand, this makes it easy to find the descriptor in the base segment that the fault handler must update.
You need to be able to mark a page as read-only, so that, when a process tries to write on a shared page, it can be copied. Presumably, the software can find some bit somewhere to mark the page as shared for the purpose of lazy copying.
b) Assuming that all reports from the memory management unit to the CPU are delivered to a single trap service routine, outline how this routine would distinguish between a conventional page-fault and a lazy-fork-fault (the latter requires that a page be duplicated).
If the page is marked read-only and the user tried to write it, and the software has a record that the page is shared for the purpose of lazy copying, then it is time to copy that page and update the page tables of the appropriate processes.
c) Outline the response of the trap service routine to a lazy-fork-fault.
First, get a page frame. Then make a copy of the page into that frame. Decrease the reference count for the shared page by one, and make the address map entry for the process that caused the lazy copy fault point to the new frame.