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.