Re: Another security vulnerability

Scott Lurndal wrote:

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 3/29/24 10:15 AM, Scott Lurndal wrote:

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 3/28/24 3:59 PM, MitchAlsup1 wrote:

[snip]

However, even for a "general purpose" processor, "word"-granular
atomic operations could justify not having all data transfers be
cache line size. (Such are rare compared with cache line loads
from memory or other caches, but a design might have narrower
connections for coherence, interrupts, etc. that could be used for
small data communication.)

 So long as the data transfer is cachable, the atomics can be handled
at the LLC, rather than the memory controller.

>
Yes, but if the width of the on-chip network — which is what Mitch
was referring to in transferring a cache line in one cycle — is
c.72 bytes (64 bytes for the data and 8 bytes for control
information) it seems that short messages would either have to be
grouped (increasing latency) or waste a significant fraction of
the potential bandwidth for that transfer. Compressed cache lines
would also not save bandwidth. These may not be significant
considerations, but this is an answer to "why define anything
smaller than a cache line?", i.e., seemingly reasonable
motivations may exist.
>

It's not uncommon for the bus/switch/mesh -structure- to be 512-bits wide,
which indeed will support a full cache line transfer in a single transaction;

It is not the transaction it is a single beat of the clock. One can have
narrower bus widths and simply divide the cache line size by the bus width
to get the number of required beats.

it also supports high-volume DMA operations (either memory to memory or
device to memory).

Most of the interconnect (bus, switched or point-to-point) implementations
have an

or more than one

        overlaying protocol (including the cache coherency
protocol) and are effectively message based, with agents posting requests
that don't need a reply and expecting a reply for the rest.

Many older busses read PTP and PTEs from memory sizeof( PTE ) at a time,
some of them requesting write permission so that used and modified bits
can be written back immediately.{{Which skirts the distinction between
cacheable and uncacheable in several ways.}}

That doesn't require that every transaction over that bus to
utilize the full width of the bus.

In my wide bus situation, the line width is used to gang up multiple
responses (from different end-points) into a single beat==message.
For example the chip-to-chip transport can carry multiple independent
SNOOP responses in a single beat (saving cycles and lowering latency).