From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-MAY-1989 13:58
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: Device driver initialization (memory mapping)

Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 25 MAY 89 08:38:23 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Thu, 25 May 89 08:35:51 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.36)
	id AA17133; Thu, 25 May 89 08:32:19 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 May 89 03:48:41 GMT
From: scubed!simpact!jeh@ames.arc.nasa.gov  (Jamie Hanrahan)
Organization: Simpact Associates, San Diego CA
Subject: Re: Device driver initialization (memory mapping)
Message-Id: <475@simpact.uucp>
References: <58*edgecombe@ccrs.cdn>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <58*edgecombe@ccrs.cdn>, edgecombe@ccrs.CDN (John Edgecombe) writes:
> We are trying to update a device driver from 4.7 to 5.1.
> This requires accessing UNIBUS memory for the device (during device
> initialization time, when the driver is loaded; and specifically at
> elevated interrupt level).
> We have attempted the minimal translation from 4.7 -- allocate some
> system page table entries, fill them to point to the UNIBUS memory 
> for the device, and work through them.
> This seems to work; however the system crashes at various times --

Just off the top of my head:

- Make sure you invalidate the translation buffer for the new virtual
addresses you're creating.  The t.b. is a cache of PTEs, and like any cache,
when you modify the thing being cached you have to make sure to either update
or invalidate the cache.  Specifically, any modifications to PTEs must
be done via the INVALIDATE_TB macro.  This was not a concern under V4 if
you alloc'd the SPTEs and filled them in once and only once, since the
system virtual addresses created thereby never existed before, and therefore
could not have been valid in the t.b.  Under V5 SPTEs can be deallocated,
so you might be using some SPTEs that were used before, so their old 
contents might still be present in the t.b.  

- Make sure that you permanently allocate, and mark as invalid (ie clear
the high-order bit), the Unibus map registers corresponding to the area of
Unibus memory you're using.  

- Make sure to never look at Unibus space (whether memory or "real" device
registers) with anything other than byte- or word-sized references.  MOVCx 
might work (it works to and from Qbus memory that's mapped this way), but then 
again it might not.  

I've written several drivers for devices that appear as a chunk of Qbus
memory and a single word CSR.  They do just what you're describing -- 
allocate a bunch of SPTEs and map the memory into system v.a.s., then
access the memory in response to $QIO requests.  No problems after 
several years of operation.  I'll talk to my boss about sending you
the code that does the mapping (can't send the whole thing, but I doubt
you'd want it all anyway).  

The swapper isn't an issue, since the pages in question aren't part of
anybody's working set, not even the system working set (yes, you can 
have valid pages that aren't part of a working set), and all functions
of the swapper are constrained to pages that are, or were, members of 
working sets.  (The "current process" at the time of a crash is often
unrelated to the crash, particularly if the crash occurred while the
system was running on the interrupt stack (indicated by stack addresses of
8xxxxxxx instead of 7xxxxxxx).)