Caches are architecturally invisible — until a DMA engine that isn’t coherent with them needs the truth. The CMO extensions give software the bridge: cache-block operations cbo Cache-Block Operation: the CMO subset acting on single cache blocks. Zicbom = CBO.INVAL/CLEAN/FLUSH (communicate with non-coherent agents), Zicboz = CBO.ZERO (store zeros to a whole block), Zicbop = PREFETCH.R/W/I hints. Gated per privilege mode by the xenvcfg CBIE/CBCFE/CBZE fields. defined in ch. I·20 — open in glossary on NAPOT blocks cache block The NAPOT-aligned unit CBO instructions operate on — uniform size across the system in CMO v1, discoverable by software (zero-block size may differ from management-block size). Identified by any physical address within it. defined in ch. I·20 — open in glossary of uniform, discoverable size. Zicbom manages copies (INVAL/CLEAN/FLUSH), Zicboz zeros a block, Zicbop prefetches.
Coherent agents and what CBOs really do
A set of coherent agents is defined by three properties: their stores serialize, their stores eventually reach every member, and loads return members’ stores. Hardware keeps copies consistent within the set; CBOs exist for the agents outside it:
- invalidate — deallocate all coherent copies, so a non-coherent agent’s writes to memory become visible inward;
- clean — write modified data out to a point the non-coherent agent can see, making coherent stores visible outward;
- flush — both, atomically.
A CBO applies to every copy in the coherent caches — including coherent instruction caches. Four bookkeeping rules govern coherent caches (may allocate/deallocate freely; may write back only if modified since the last inval/clean/flush; exactly one cache is responsible for an unwritten modification; must write back when a clean/flush demands it) — together they guarantee a clean copy can never overwrite memory that a non-coherent agent updated.
Ordering and load values
| Ordering behavior | |
|---|---|
| Invalidate / clean / flush | Behave as STORES in the PPO rules, plus one extra rule: they stay ordered before any program-order-later LOAD to an overlapping address. W or O in FENCE predecessor/successor sets. |
| CBO.ZERO stores | Ordinary stores in every respect, ordered by everything that orders stores. |
| PREFETCH.R/W/I | Ordered by NOTHING — no PPO rule, no fence. Pure hints. |
Invalidation also extends the Load Value Axiom: a load after an invalidate (with no intervening store) may see the block’s older history — bounded below by the latest clean/flush-written value — or any value a non-coherent agent stored, at any time. That formalizes “after CBO.INVAL, memory speaks and the cache forgets.”
Trap behavior
| Permitted when | Faults & A/D | |
|---|---|---|
| Management (Zicbom) | A load OR store may access the addresses (fetch-only pages: UNSPECIFIED). | STORE page-/guest-page-/access-fault; checks/sets A, ignores D. |
| Zero (Zicboz) | A store may access AND the Zicboz PMA supports it (mandatory for main memory, optional for I/O). | Store-typed faults; checks/sets A and D. |
| Prefetch (Zicbop) | Load, store, or fetch permission suffices. | NEVER faults — denied access means silently no operation. No A/D activity. |
| Block-wide constraints | PMP and PMA must be uniform across the whole block, with write⇒read. | Otherwise CBO behavior is UNSPECIFIED. PMP applies per constituent memory operation if decomposed. |
Illegal- vs virtual-instruction gating by the xenvcfg cascade is the next page’s subject. Under H, trapped CBOs get a standard mtinst/htinst transform (the instruction’s upper 12 bits with rs1/rd zeroed). And one deliberate concession: another hart’s management/zero CBO hitting your reservation set counts as a legitimate constrained-LR/SC loop-terminating event — coherence protocols can’t tell a CBO invalidation from a store’s.
Hardware Designer Notes
For a Linux-bootable SoC with any non-coherent master (display, DMA, crypto engine), Zicbom is effectively required plumbing — Linux’s arch_sync_dma_for_device() maps straight onto clean/inval/flush. If everything on your bus is coherent, the whole chapter can wait.
Minimal Linux-boot hart MUST
- Apply CBOs to every coherent copy — including coherent I-caches — via your protocol’s clean/invalidate verbs (ACE/CHI CleanShared, CleanInvalid, MakeInvalid map directly)
- Type management CBOs as stores in the LSU ordering queues and implement the CBO-before-overlapping-load rule
- Report store-typed faults with rs1 in xtval, and enforce the A-not-D rule for management ops
MAY simplify / trap-and-emulate
- Implement clean and inval both as flush — architecturally indistinguishable, stated twice in the spec
- Decompose a block CBO into multiple memory operations (each PMP-checked independently)
Check yourself — CMO concepts & ordering
1.What problem do the Zicbom management operations exist to solve?
2.How do CBO management operations slot into RVWMO?
3.Which permission does CBO.INVAL's fault reporting use, and which A/D bits does a management CBO touch?
4.Why does another hart's CBO to your LR reservation set count toward the constrained-LR/SC eventuality guarantee?