search

riscv / riscv-CMOs

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

CBO instruction behavior when cache is disabled or when memory attribute is uncacheable #41

Closed chuanhua closed 2 years ago

chuanhua commented 2 years ago

What is the behaviors of CBO instructions when

  1. the corresponding cache is disabled?
  2. When the memory attribute of the address is uncacheable or in I/O region?
dkruckemyer-ventana commented 2 years ago

What is the behaviors of CBO instructions when

  1. the corresponding cache is disabled?

The architecture does not describe a mechanism to disable a cache, so the extensions do not cover this case.

  1. When the memory attribute of the address is uncacheable or in I/O region?

Note that the definition of the PMAs does not require I/O regions to be uncacheable, so the behaviors are independent of whether a cache block is in a main memory region or I/O region. The CBO instructions do place certain constraints on the PMPs and PMAs, namely, the protection and attribute information must be the same for all bytes in a cache block. Otherwise, the behavior is UNSPECIFIED.

Regarding the uncacheable attribute, the behavior of management CBOs are defined with respect to the data values observable by agents inside and outside the set of coherent agents. There's no explicit behavior defined beyond satisfying those requirements (see additional comments below). Additionally, the behavior of zero CBOs is defined with respect to the set of bytes corresponding to a cache block to accommodate cacheable and uncacheable attributes. Finally, since uncacheable implies that a copy of a cache block may not be allocated, prefetches are effectively NOPs (but they are HINTs anyway so they have no architecturally visible effects other than those specified in the base spec).

Now, please keep in mind that the current extensions assume two requirements: (1) all agents in a coherent set access a cache block with the same attributes, and (2) those attributes are static. In a future version of the extensions, the TG will define the behaviors with respect to mismatched attributes (e.g. different PMAs on different harts or different PBMTs due to aliases) and with respect to changing attributes (e.g. changing PMAs or PBMTs from cacheable to uncacheable). These new behaviors may introduce additional requirements.

dkruckemyer-ventana commented 2 years ago

Closing since I believe the issue has been addressed. Please reopen if not.