RISC-V inherited all the bad ideas of x86 by now. It has an SMM equivalent, a separate hypervisor mode (instead of full orthogonality which lets you get away without one), resident firmware code outside the OS' control, ...
RISC-V, without the hypervisor extension, meets the requirements for Popek-Goldberg virtualization, unlike x86. The problem is that classic virtualization requires shadow paging for memory virtualization, which can be slow. The hypervisor extension (not yet finalized) only adds two level nested paging, a few shadow CSRs, and IIRC a few more interrupt handling registers. The hypervisor extension itself is virtualizable (again, with shadow page tables).
Right, I forgot about RISC-V's MSR equivalent - with a worse assembler implementation (though that's simple to fix without touching the ISA) since the standard assembly expects them to be names, not numbers (that can be #defined away to names).
I had a (very emphatically not) fun time updating coreboot's toolchain and code base in lock step to ensure that risc-v code remained compilable when these changed.
Please don't spread misinformation. RISC-V has a well-thought out machine layer which is open source in all existing implementations[1]. You can easily modify the M layer if it's interfering with the performance or security of your OS.
The virtualization extension hasn't been finalized (but they are working with key KVM people), but it will perform a lot better than a theoretically pure self-virtualizable ISA.
"please don't spread misinformation" followed by confirming that all the mis-features I mentioned exist? (just that you disagree about them being mis-features)
How can I run Linux on RISC-V portably without having to implement the SBI?
It really doesn't. It has an open source layer under supervisor mode which works with the OS. This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user.
> a separate hypervisor mode (instead of full orthogonality which lets you get away without one),
As others pointed out also, this is plain wrong.
> resident firmware code outside the OS' control, ...
As explained, it has an open source machine mode, and we regularly modify both OS and machine mode to work together.
> How can I run Linux on RISC-V portably without having to implement the SBI?
Why would you want to? Porting Linux to M mode is going to be tricky because there's no paging, but other OSes could run there.
> This is very different from Intel SMM, a closed source blob that acts against the interests of the OS and the end user.
I'm not talking about implementations (there are open source SMM implementations that act against no-one's interest), but about the mechanism. The mere presence is enough that you'll see a closed source blob on RISC-V soon enough, and it won't be friendly.
The only way out is not to have that mechanism in the first place but by making it part of the architecture (instead of some vendor addition because they couldn't get the chip to work in any other way), it's guaranteed to stay.
> As others pointed out also, [getting away without hypervisor mode] is plain wrong.
Only if you want to deprive usermode from secondary page table capabilities. Instead of making it a separate mode, make it an optimized instruction and even "virtual hypervisor" would be relatively efficient (two invocations of that instruction, instead of one invocation plus a software implementation).
> As explained, it has an open source machine mode
And as explained, it doesn't matter that the early hackers have some open source code. If RISC-V ever takes off (and given how invested you seem to be in it, you probably want that?), it won't stay that way.
SiFive only had to give in this time because the market isn't mature yet. That will change.
>> without having to implement the SBI?
> Why would you want to?
Because I don't want anything to happen outside the OS' control.
Why can't M mode be left for dead on systems that mostly run in supervisor/user mode? Jump in supervisor, returning into M mode incurs a cold reset or trap (ie. Don't Do It). No SBI.
One of those decisions that will come to haunt RISC-V.
Companies using any ISA can add secret or closed extensions. That is simply outside the scope of an ISA specification.
If you want to ensure there is no secret stuff in your chip you'd better be prepared to create your own designs and manufacture them in your own foundry. RISC-V would still be an excellent starting point.
Extensions are fair game, of course. As is not buying chips with closed extensions.
But designing the hooks for anti-user binary blobs into the ISA just encourages misbehavior as soon as they can get away with it.
RISC-V code in privileged and protected pockets of the systems is so much easier to design, maintain and update than ISA extensions that I consider that the bigger problem due to its future ubiquity.
RISC-V, without the hypervisor extension, meets the requirements for Popek-Goldberg virtualization, unlike x86. The problem is that classic virtualization requires shadow paging for memory virtualization, which can be slow. The hypervisor extension (not yet finalized) only adds two level nested paging, a few shadow CSRs, and IIRC a few more interrupt handling registers. The hypervisor extension itself is virtualizable (again, with shadow page tables).