Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!usc!bufo.usc.edu!vorbrueg
From: vorbrueg@bufo.usc.edu (Jan Vorbrueggen)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <20260@usc.edu>
Date: 2 Oct 89 22:47:34 GMT
Reply-To: vorbrueg@bufo.usc.edu (Jan Vorbrueggen)
Organization: University of Southern California, Los Angeles, CA
Lines: 46

In article <477@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
>
>As an alternative, do the following:
>    MOV       addr1,R1      (ie Move data found at addr1 into register R1)
>    STO       R1,addr2      (store register contents in addr2)
>Even if the fault occurs during the read of addr1 (a bit odd since
>peripheral memory locations are usually non-pageable) then the access will
>still only occur once.  If the page fault occurs during the store then
>we similarly don't care since addr2 will also only be accessed once (in my
>example its just memory but could conceivably be another peripheral).

But what if the pagetables mapping addr1 or addr2 are pageable?
This is the case on VAXen, where a process' pagetables (for its
private virtual address space called P0 or P1) reside in the
virtual address space shared by all processes (called S0). The
pagetables for S0, of course, are stored in contiguous physical
memory, at a physical address recorded in a processor register.

So, a pagefault can occur for two reasons: the page referenced is
invalid (not in the working set), or the pagetable page is invalid.
Naturally, the pagetable page for a valid (in-working set) page
has to be valid. 

However, VMS since (at least) V2.3 and probably until today has a bug where
pages mapped to physical memory (e.g., I/O registers), though by
definition always valid, don't increment the reference count of
the pagetable page. In a memory-tight situation (in this case, the
process was only allowed 100 pages in its working set), VMS will
kindly recuperate unused memory by performing a so-called dead 
pagetable scan. It proceeds to remove the pagetable mapping the device,
and next time the process references it, bang: down goes the system!
(Pagefaults are not allowed in certain situations.)

Another nice situation happens when you debug an application using
a memory-mapped device. Say your application sadly has a bug and accesses
an address where there is no device. It will get an access violation
fault. So you fire up the debugger and single-step through it.
This is implemented by using special trace bits which will return
control to the debugger after every instruction. The program
writes to that non-existant location and gets its trace-pending
trap, calling a priviledged-mode routine to handle the trap. Some
instructions (or 10 microseconds) later, the bus tells the cpu that
it couldn't perform the write. Now the access violation seems to have
occured in the priviledged mode - and a crash occurs...

Jan Vorbrueggen