search

riscv / riscv-CMOs

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
78 stars 12 forks source link

THIRD QUESTION: what CMO types should actually be supported? #11

Closed AndyGlew closed 2 years ago

AndyGlew commented 3 years ago

Once wer have decided what the basic register dataflow shape of the CMO instructions look like (per-cache-line vs range CMO.AR + CMO.UR) there is the question of what cache operations should be supported.

This issue is just a collection point. There will be sub-issues dedicated to different tyopes of CMO operations.

This issue will be closed when we thing we have the full set, and reopened if new CMO types are added

This issue also just starts the discussion:

The basic CMOs are

Writeback dirty data, and leave behind invalid lines (whether originally clean or dirty). (In another issue John Hauser has proposed tocall this EVICT for RISC-V; other instruction sets call it WBINVD (writeback invalidate) or FLUSH (POWER DCBF, Intel x86 CLFLUSH)

Writeback dirty data, and leave behind clean lines (whether originally dirty or clean). We propose to call this CLEAN for RISC-V. Other ISAs call it writeback-no-evict, or FLUSH.

Change lines to invalid without writing back dirty data. We propose to call this DISCARD for RISC-V, following IBM POWE; other ISAs call it "forget" or "invalidate" (e.g, x86 INVD). This operation is insecure and cannot be allowed to all user code on systemns than have different privilege domaions sharing the same cache; but it is nevertheless frequent, often important for performance, and arguably should be part of any RISC-C CMO spec. (The arguments should be in separate issues.)

There are many more CMOs.

E.g. ZALLOC or DCBZ - allocate a cache l;ine without an RFO, saving bus traffic, zero filling it (fior security)

E.g. DCBA - allocate a cache line, possibly inheriting garbage data. A security hole, we can argue abourt including it...

E.g. cache line prefetches - PREFETCH-TO-READ, PREFETCH-TO-WRITE, PREFETCH-CODE ... again, argue elsewhere

Move data into other processor caches, etc.

dkruckemyer-ventana commented 3 years ago

At a minimum, EVICT and CLEAN should be defined. I'm less inclined to support DISCARD, since we need to define virtualization behavior (e.g. imagine a guest OS that operates using DISCARD). In at least one other architecture, DISCARD becomes EVICT in a virtualized environment when the guest performs the op.

But let's define the primary use-cases we want to address first. That should hopefully triage the ops.

dkruckemyer-ventana commented 2 years ago

Closing since defined in v1.0 spec.