Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.arch
Subject: Re: Phys vs Virtual Addr Caches
Message-ID: <2798@phri.UUCP>
Date: Thu, 16-Jul-87 20:22:22 EDT
Article-I.D.: phri.2798
Posted: Thu Jul 16 20:22:22 1987
Date-Received: Sat, 18-Jul-87 09:06:09 EDT
References: <3904@spool.WISC.EDU>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 27

In article <3904@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes:
> Why do people build their caches to respond to physical addresses instead
> of virtual addresses?

	The scheme Larry describes sure sounds like it would be a win but
for one problem.  How do you deal with invalidating cache lines when some
DMA I/O device writes into the corresponding main memory location?  The I/O
device is generating physical addresses but the cache is keying on virtual
addresses.  Now that I've posed the problem, I'll throw out some possible
answers.

	1) When you store to cache, install VA as the key and store the PA
along with the data.  CPU-generated addresses key on VA, I/O generated
addresses key on PA for purposes of invalidation.  Makes the cache wider
and adds more key-match logic.

	2) Do I/O with VA's instead of PA's and have DMA go through the VM
machinery.  Doesn't make the I/O device any more complicated to build (in
fact, doesn't change it one whit) but adds more complexity to the I/O
bus adaptor.

	Add to all this the fact that you can (and very well might want to)
have multiple VA's mapping to the same PA.  Nasty wrinkle all around.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016