Notes on the Privileged Architecture for the RISC-V

My notes on The RISC-V Instruction Set Manual: Volume II: Privileged Architecture

I am suspicious of ‘Hardware Abstraction Layers’. My experience with them as I ported Keykos was that they hid features that ended up making the higher level code either less efficient or more complicated. In my experience “simpler” always dominates “uniform”.

1.4 Debug Mode

The 370 had several convenient hardware debug features designed for debugging application code. Of IBM’s OSes, only VM/370 supported them. Keykos did too. It is convenient if they are uniform across a family.

2.2 CSR Listing

I think that (even) read access by user code to a timer should be illegal as selected by privileged code. Among other things read access may provide convert channels.

The uscratch register is useful only if it is faster than going to memory. The 88K had four such and we used two to advantage. I presume that you can read and write it and there are no hardware ramifications. One use was to save the first register upon an interrupt. Another use was to locate the save area. An exchange instruction would reduce our requirement to one register. “uscratch” should be defined somewhere in the document. I guess it comes under αscratch for α∈{u, s, m}.

This section is hard to read without knowing the shape of the instruction used by a program to read or write the CSRs. For instance I need to know if there is an instruction to move between a general register and a CSR with no other side effects. A short search of the manual does not reveal any such instructions.
Page 22 of volume I has a satisfactory description of satisfactory instructions.
Now I see reference to “CSR instruction” which are defined in Vol I.

I choke up when I deduce that the register is readable and writeable in user code.


I presume the same goes mutatis mutandis for utval. That ruins a feature that IBM found quite valuable in VM/370. When an architectural improvement was considered, or committed to they could modify the VM/370 control program to emulate the new instruction.
There is a worse problem, I think; The kernel cannot deliver virtual memory if the user is able to sense page faults. Nor can a virtual machine control program provide the illusion that pages are there, when at the next level they are not.
Far from having learned the entire privileged architecture I have retained my prejudice that a simple two(!!) level privilege mode already solves all the problems. I iterate for the nth time that the simple 370 was virtualizable without any features added to support that. No RPQs were required to run VM/370. When architects add features to “improve virtualization” they generally make it worse, except that some simple architectures (386) were unvirtualizable. I think my bias would be less if the people who built the code that runs “below the kernel” were as accurate and expressive at documenting the abstraction that they intend to provide, as the hamachine architects often are.

I wonder about architects who worry about adding features to make their architecture virtualizable. Seldom addressed is the question as to whether the virtual machines are also to have the feature. What advantages do they aspire to beyond the 360 model 67, or later 370’s? It is noteworthy that CP/67 hardware was designed and produced by people who had not heard of virtualization! IBM added features to improve performance for VM/370 and early light hacks to achieve that seemed to be a good idea. Their later “Start Interpretive Execution” (SIE) was not a notable success as far as I know. It was, in effect, an attempt to move most of the control program into proprietary microcode. As architects improve the machine for virtualizability they usually make the control program more complex and bug prone. This may be a good tradeoff when real improved performance results. My experience with several architectures is that a modest privileged mode virtualize best.