Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ogccse!blake!milton!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.COM (Terry Ingoldsby)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Summary: Depends on the OS??
Message-ID: <480@ctycal.UUCP>
Date: 1 Oct 89 22:59:57 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2255@munnari.oz.au>
Organization: The City of Calgary, Ab
Lines: 41

In article <2255@munnari.oz.au>, ok@cs.mu.oz.au (Richard O'Keefe) writes:
> 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
> 
> It doesn't sound all that unreasonable for a page fault to occur during
> a memory-mapped I/O operation.  Imagine a memory-mapped scheme where each
> device has all its registers in a different page of I/O space, and where
> the operating system is running a "virtual machine" scheme.  All I/O
> pages would initially be mapped out of a process's address space.  Touching
> an I/O page would cause a page fault, at which time the O/S would check
> whether the process had permission to access that device, and if so would
> map the page in.  If the O/S needed to seize control of the device back,
> it would map the page out again.
> 
Granted, it could happen under some conditions.  I was thinking more of
the case where the user doesn't actually do the memory access, but rather
makes a system call for the OS to do it.  Many OSes lock things like disk
device drivers, buffer space, tables, etc. into memory and I assumed that
many OSes would do the same with the memory locations corresponding to
devices.  This wouldn't be hard to do since a small region of memory could
be dedicated to this.  Whether this is done or not I have no idea (any
OS gurus out there know how it really is done?).  Nonetheless, it doesn't
make any difference since the instructions I suggested still work even if
the fault occurs.

The only thing that I can see happening if the page is not locked into
memory is if a swapper tries to write a region of memory out to disk.  That
could provoke some unusual behaviour of the peripherals!  A similar argument
would exist for swapping (or paging - if it is a hard page fault) the region
back into memory.  Soft page faults (ie. those where the page is in physical
memory, but not in a process's page table) just involve setting up some
pointers and don't actually affect (ie. read/write) the memory locations.
Is any of this making sense?
-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb