Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Thu, 13 Jun 2024 00:34:34 +0000
Organization: Rocksolid Light
Message-ID: <c66d331b401f9363a1fab5c7e2ad350b@www.novabbs.org>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com> <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at> <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com> <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org> <k58h6jlvp9rl13br6v1t24t47t4t2brfiv@4ax.com> <5a27391589243e11b610b14c3015ec09@www.novabbs.org> <jqgaO.1934$WaKd.92@fx41.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="4016787"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$XnYie1N5Ek2WgRA3m1YYFee2NsJsGpQoifLJaO.CP2FBvFIMkMG.q
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3535
Lines: 51

EricP wrote:

> MitchAlsup1 wrote:
>> John Savard wrote:
>> 
>> 
>>> 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.

> What does it do if L3 receives more writes than it has ways in a row,
> does it stall evicts from L2?

There is a 128 line temporally organized buffer between L3 and DRAM.
So with your proposed 4-way L3, you have 130 accesses between banging
on
one particular line a second time. This buffer is also SNOOPed acting 
like a victim cache. And likewise a similar buffer on the read side,
acting like a prefetch buffer. There is a connection between the 
buffers so that when ECC error is corrected, the corrected data is 
migrated back into DRAM.

> Lets say L3 is 4 way assoc and all four in a L3 row been updated,
> then a 5th way in that same row is written from L2.

L3 dumps a selected line into the DRAM write staging buffer. This
staging buffer is controlled by high and low water marks, and 
operated to minimize DRAM->CHIP and CHIP->DRAM bus turn arounds.
You try to insert refresh cycles on the DRAM while its pins are
doing their electrical turn around thing.

> L3 has no place to hold that 5th way and it can't evict one
> of the other 4 ways because that could cause rowhammer.

You typical L3 has a lot more ways than you postulate.

> Seems to me that all it can do is stall the 5th write from L2 until
> DRAM refresh rolls around and re-enables one of the pending L3 writes,
> which would back up victim evicts from L2.
> Or maybe L3 has a small fully assoc emergency overflow buffer,
> but still that could fill up too.

Buffers my friend, buffers.