From the time I started working on the Kestrel-3 development tools and emulator, I used the currently documented Draft Privileged ISA Specification V1.7 as my guide for supporting interrupts, managing the mtohost and mfromhost CSRs (which I used to talk with the emulator directly), and other supervisory aspects of the machine.

One e-mail I got back from the HW-DEV group brought to my attention differences between the Spike ISA simulator and the V1.7 privileged ISA specs. While some changes were to be expected, I did not expect the changes to be so radically different as to basically require a complete redesign of the privileged mode all-together.

Some changes that I'm personally aware of, along with some inspired speculations:

• No more mtime and mtimecmp registers; responsibility for real-time keeping is off-loaded to a peripheral. I have mixed feelings over this removal, but I think it's a good move in the long term. It certainly greatly simplifies real-time-keeping in a multi-hart configuration.
• The mstatus register is completely different in layout. The privilege stack that was previously maintained in mstatus is gone. Unfortunately, I'm not sure how it works right now. While interrupt enables exist for user, supervisor, hypervisor, and machine modes, the removal of ERET suggests to me that a stack is no longer implemented. (Note that EBREAK and ECALL are still supported.) There are also MPP, HPP, SPP, and UPP fields, whose semantics are completely opaque to me at the moment. Also, it's not clear how to tell which operating mode the CPU is currently in. With discussions of a new "debug mode," it's entirely possible that mstatus is no longer the source of truth for determining current operating mode.
• Speaking of which, the ERET instruction is no longer supported. Instead, there are URET, SRET, HRET, and MRET instructions. Whether these instructions "return to" their eponymous mode of operation or if these instructions can only be *used* in their eponymous mode is unknown to me. The Git diffs I've seen do not make the semantics clear. This change was apparently needed to work around a virtualization escape exploit.
• Polaris is configured to boot in high memory, specifically at address $FFFFFFFFFFFFFF00. This differs markedly from where Spike assumes a processor will boot from. However, this keeps changing throughout the project's history. I remember when $2000 was the official bootstrap point. Then it became $200. Then in the V1.7 privileged specs, it was configurable based on the default MTVEC register (which is what Polaris does). Then it became address zero (like Intel 8080). Now that people are talking about a debug mode of operation, it's currently at $1000. Where will it be tomorrow? Nobody knows. But, one thing is for sure: it's prudent to treat the RISC-V architecture just like the Motorola 68K series of CPUs, which had a rock-solid user-mode environment, but in any other privilege mode, anything goes.
• The nature of mtvec has changed. In V1.7, mtvec pointed to a set of five trap handlers. These handlers were intended to handle traps generated in user, supervisor, hypervisor, and machine modes of operation, in that order. There was an additional non-maskable interrupt entry point as well. Note that htvec and stvec (for hypervisor and supervisor trap handlers) pointed right at their respective handlers. This elevated machine-mode software above other modes in a way which violated Popek and Goldberg virtualization requirements. Going forward, it seems that mtvec, htvec, stvec, and a newly introduced utvec register all point directly at their handlers equally, enabling code that once sat at machine-mode to be seamlessly run at lower privilege levels. This is a change I actually agree with, although I will miss the convenience of having separate handlers for different privilege modes.

I'm positive there are others; these are just the changes I've been able to glean from reading the git commit history.

While I look forward to seeing a finished privileged ISA specification, I also do not want to wait forever to get the Kestrel-3 working in a real FPGA. I'm going to stick with the ISA specifications as they're currently defined. This means that the Kestrel-3 will be officially incompatible with any future RISC-V Privileged ISA specifications.

I think to bring the Kestrel Project back into RISC-V compliance, I will need to release a Kestrel-4 (one which is not my April Fool's joke), which is a Kestrel-3 in every way, but with a properly compliant CPU at its core.