We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RV arch extensions that have been submitted for official AR (or for prelim review). Here are this week's minutes.
Minutes from AR Committee meeting on 11/8/22
Discussed recent Zcmt software-related issues. Confirmed that Zcmt is incompatible with the RVA profile, since RVA mandates Zcd, which conflicts with Zcmt. Hence "missing" software support on application-class Linux systems is a moot issue. Similarly, AR is also not convinced as to the need for Zcmt to support position independent code. A much fuller response on the latter has been posted on tech-code-size to further the discussion.
Svadu regarding "cacheable main memory" requirement The current spec requires that page tables be in "cacheable main memory" - which is imprecise and not quite right as far as the required PMA attributes. The requirement has been clarified and resolved to be that page tables need to be in PMA regions that have the RsrvEventual attribute (so that hart software can also make compare-and-swap style atomic changes to PTEs using LR/SC concurrently with hardware doing atomic A&D updates).
Vector Crypto submitted for arch review (although the spec is not 100% finalized yet).
The proposal for "All Rounds" instructions should be pursued separately from the current proposed set of instructions (i.e. a separate ratification package) so as to not delay the current package of instructions from working their way down the path to ratification. In parallel, further review and vetting by the community can proceed around these proposed "All Round" instructions and their intended use to create DPA-resistant AES instructions, as well as doing some form of associated PoC.
Reviewed handling of "improper" vl values and agreed with the current spec's mandate of non-integral vl/EGS causing an illegal instruction exception.
Reviewed handling of VLEN<EGW in relatively "narrow" vector implementations and agreed with the use of LMUL=2 when needed (which still allows for 16 vector register groups).
The proposed resolution within the TG to this week's vector rotate immediate issue looks good.
AR, as prelim feedback, is happy with the general direction of the proposed spec including the proposed instruction semantics, the opcode assignments, and the use of the (new) general vector concept of element groups.
AR also approves of the reuse or overlay of some vector crypto opcodes with the 'P' (aka Packed-SIMD) opcode space. Since the P and V extensions have overlapping functionality, yet are largely suited to different application domains, they are considered mutually incompatible. This avails each extension of the other's major opcode without concern of collision.
The vector bitmanip extension looks fine. In the future these may become part of a broader vector bitmanip extension, but this is a good set for now for crypto purposes.
As the spec is not quite completely finalized yet, completion of AR awaits a final ready-to-freeze spec.
IOMMU and whether Svnapot support should be mandatory or optional. AR's view continues to be that the hardware cost of supporting NAPOT PTEs in at least the trivial form is tiny (~20 gates to decode NAPOT PTEs but otherwise treat them as normal 4K PTEs), whereas in general there is software cost (whether big or little) to supporting optionality (and little hassles like extension naming support for optional features). In short, RV arch specs should support optionality where there is value to providing implementation flexibility (and the software support cost is reasonable), and conversely supporting optionality for negligible benefit is generally discouraged. John will discuss further with Ved.
Review of latest Pointer Masking (Zjpm) spec
After a recent joint meeting with the J group chairs to review the latest pointer masking proposed spec and go over various questions and comments, an updated and improved spec will be created. Completion of AR awaits submission of this updated spec. CSR number assignments will be made based on the updated spec.
