email@example.com Integration <tech-cmo@...>
Thanks for your feedback. I have some short responses and some longer responses, and unfortunately, at this time, I can only address the feedback that requires short responses. But I promise to get back to you on the rest in the future!
It depends. The specification requires that
The spec also has the following non-normative comment:
So, for example, if a load could be serviced from an instruction cache via coherence mechanisms or if a store could invalidate an instruction cache, because that cache was coherent with respect to those loads and stores, then a CBO must operate on that cache. The permissions for CBOs include instruction fetch for this reason, but the specification (and the architecture) does not distinguish types of caches.
Crucially, these CBOs are only intended to operate on copies that can be accessed by explicit memory accesses, and any synchronization between implicit instruction fetches and explicit loads and stores will be defined in a forthcoming I/D consistency extension. That extension will define more fine-grained operations to manage those types of memory accesses beyond FENCE.I.
This was a hotly debated topic within the TG as well as with the arch review committee. I plan to provide a long non-normative section in the specification to capture the salient points of the discussion and the resolution. My apologies that I cannot do justice to this topic right now.
Again, there was a lot of discussion around this one, and it probably deserves non-normative commentary for posterity as well. At this point, I will say that there's a distinction between what permissions are required for each operation based on intended use-cases and what exceptions are reported based expected implementations. I promise I will circle back with more information.
Thanks again for your feedback!