Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!news
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.arch
Subject: Re: cache pre-load/no-load instructions
Message-ID: <1991Mar27.110029.15418@cl.cam.ac.uk>
Date: 27 Mar 91 11:00:29 GMT
References: <1991Mar24.151523.21921@cl.cam.ac.uk> <12487@pt.cs.cmu.edu>
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 23

In article <12487@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>In article <1991Mar24.151523.21921@cl.cam.ac.uk>
>	cet1@cl.cam.ac.uk (C.E. Thompson) writes:
>:Even if DCLZ and CLI did check protection, you have to allow for scenarios
>:such as the following. User program touches a never-before-referenced page
>:in a work segment; kernel allocates a real page frame and zeros it with DCLZ
>:instructions (this must be the archetypal use of DCLZ in practice). Now the
>:user program must *not* be allowed to use CLI on this page, or it could read
>:the previous contents of the real page frame which the kernel was trying to
>:hide from it.
>
>I thought that read-uncached would check for valid cached data before
>going to memory?  

This sub-thread was about the cache manipulation instructions on the RS/6000.
It doesn't have a read-uncached mode (except at the hardware test level
of "do this memory cycle"). CLI invalidates the cache line, even if dirty,
without affecting main memory: it is privileged, and I was trying to explain
one reason why it needs to be.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk