Re: Privilege Levels Below User

MitchAlsup1 wrote:

John Savard wrote:
 

On Tue, 11 Jun 2024 00:27:02 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

 

ALL I have DONE is to not have the MB write into the cache until the
causing instruction retires !!

 

I suppose that depends on how you define "write".

 I mean the memory cell does not get modified.
 

If by "write" you mean store data in the cache, for eventual writing
out into RAM, well, since RAM doesn't contain "rename locations" to
play with, it seems to me that any CPU designer had better do that.

 The cache itself is not modified until the memory reference retires.
But there is a buffer holding the data which can be accessed as if
it were an L0 cache until the data migrates to the real cache at retirement.
 

At least, I'm not imaginative enough to think of doing it any other
way.

 

However, if by "write" you mean to change the state of the cache in
any way, such as by reading data from memory... now, _then_ you would
indeed have done what is necessary to combat Spectre.

 The cache is not modified, the data is available through another means.
a means that can be backed up like a mispredicted branch. The buffer
I am talking about is temporally organized not spatially organized.
 

Obviously, though, a "load" instruction will _never_ retire unless it
can read the data from memory it is trying to put in a register.

 The LD instruction can obtain data from either the buffer or from
the data cache itself. The buffer covers the execution window,
allowing the LD to retire (assuming every older instruction also
retires).
 

So apparently WHAT you have REALLY DONE is to modify how memory reads
work...

 I pipelined them through a temporally organized memory execution
window. This also provides for allowing the memory system to run
OoO wrt program order, and detect actual ordering violations, and
rerun the memory references in a proper memory order by rerunning
the references in order.
 You get relaxed memory order performance and precise memory order
simultaneously.
 

if the data a load instruction requires is not already in the cache,
then a direct read from memory

 The request is forwards towards memory through the cache hierarchy
and data arrives back at requestor (sooner or later).
 

                               is performed which *completely
bypasses* the cache;

 Yes, critical word first.
 

                     this data (and its associated address) are
retained by the CPU to be placed in the cache _if_ the instruction is
actually executed and when it retires.

 Yes !! While the data resides in the buffer, the whole line can be accessed by a number of memory reference instructions.
 

And, in fact, the various cache levels have to work this way too. You
have an L1 cache miss, but an L2 cache hit? Fine, you take your data
directly from L2, and don't promote the data into L2 until instruction
retirement.

 I use an exclusive cache organization. so data arriving at the CPU
goes into buffer, which upon retirement goes into L1, which has the
potential to push a L1->L2 line, and so forth.
 

So now the process of fetching data from memory is _not_ done by
fetching always from L1 and going _throughl_ L1 to access L2, and
going _through_ L2 to access RAM, which seems to be the usual way
these days.

 Its back to the Athlon/Operon organizations.
 

That certainly can be done. But it isn't quite as simple and obvious
as you seem to claim.

 If you had worked on them you can recognize the advantages and dis-
advantages.
 

My 66000 is also insensitive to RowHammer and derivatives.....

 

When I first read that sentence, I was completely incredulous. DRAM is
sensitive to RowHammer because it's gone to feature sizes which are
beyond the state-of-the-art to do properly... so corners have been
cut.

 

How a CPU can be "insensitive" to it was mysterious.

 

After all, RowHammer is caused by multiple rapid-fire accesses to the
same address, or to related addresses, in memory.

 Yes, the write buffer in my DRAM controller is the L3 cache. Modified
data in the L3 migrates towards DRAM as DRAM cycles permit, but there
is no way to cause a line to be continuously be written into DRAM.
If a modified line has migrated to DRAM, and it gets modified again
in the L3, that 2nd write will not be performed until a refresh cycle
on that DRAM is performed.
 Thus if one tries to RowHammer My 66000 DRAM, DRAM gets refresh cycle
between each write.

Rowhammer can modify nearby lines, not just the ones that are being hammered, right? How do you guarantee that all neighbors will also be refreshed?
Similarly, if the accesses are LOCK XADD operations, and you have multiple CPUs (or cores not sharing a common last level cache, then I don't see any way to avoid those accesses from making it all the way to the RAM chips?
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"