Make clear that the draft chapters won't change ratified parts

[cmuellner]

There were concerns that the draft chapters of this specification might have an impact on the ratified parts once they advance. Let's make it clear that this is not the case.

[jhauser-us]

There were concerns that the draft chapters of this specification might have an impact on the ratified parts once they advance. Let's make it clear that this is not the case.

As far as RISC-V ISA components such as CSRs are concerned, the proposed new text is redundant with the existing rules of the RISC-V International Association. Once an ISA extension is ratified, RVIA says it cannot later be modified in any substantive way (excluding presentation style, comments, and clarifications of the original intent in cases where the official text may have conflicting interpretations, which is always a risk). Substantive ISA modifications like additional CSRs must be new extensions, layered on top of the base ISA and earlier extensions.

I prefer to rely on the general RVIA rule that's supposed to be true of all ISA extensions. If people are not already aware of this general rule, it's better to inform them of it than to have a specific instance in the AIA document for the AIA alone.

[cmuellner]

Thanks for the response!

I assume you refer to the Ratification Policy, which states in version 1.3:

No substantive changes (i.e., new instructions or state) may be made to a ratified specifications; these can only take the form of a new extension in a new specification. HCs may approve any non-substantive changes (editing, formatting, clarifications, etc.) at any time in a ratified specification.

As far as I can see, the Duo-PLIC section would introduce changes to the domaincfg register's behavior (e.g. introduction of the CM bit instead of a reserved bit) if no changes are made to the chapter. As the domaincfg register is not a CSR, this change does not qualify as a state change. The IOMMU Support for MSIs to Virtual Machines chapter will become relevant once the IOMMU spec comes towards ratification (as written in the preface).

So here are possible paths for the draft chapters:

• They will not be driven any further
• They will become a ratified part of a new version of the AIA specification, in which case no new instructions/CSRs will be added
• They will be moved into a new extension specification

So my proposed text might lead to further issues, because it could be argued that the change of bit 6 in the domaincfg register from read-only 0 to CM (as currently written in the DuoPLIC section) is a change of an already ratified part of the AIA spec (which my proposed text ruled out). So I am not interested in getting this PR merged.

FWIW, there was also a short discussion about this in December 2022 on tech-aia: https://lists.riscv.org/g/tech-aia/message/335