[rwmj]

You said:

> It has an SMM equivalent,

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.

[pgeorgi]

> 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.

[rwmj]

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.

[pgeorgi]

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.

[rwmj]

The machine mode is there for a very good reasons of microarchitecture design scalability, allowing the same machine model to be presented to the operating system with everything from tiny designs to everything-in-hardware. In all existing designs it is open source. It's quite reasonable to have this explicit layer, since in many other cases it has been hidden away (think: Transmeta, or many x86 emulators).