If that is the intention, the text should be changed to "Returns 0 if the given SBI extension ID (EID) is not available, or an implementation defined non-zero value if it is available". Although, if t

If I understand correctly, per the description of `sbi_probe_extension`, each of the extensions are supposed to specify an "extension-specific non-zero value" to return if they are available. However,

It seems that this comes down entirely to semantics of what a "tick" means in this context. If 1 tick = 1 count = 10ns then it violates the spec, whereas if 1 tick = 10 count = 100ns then it complies.

The requirement seems to come from the Zicntr extension described in the base (unprivileged) spec. I'll let somebody else say whether incrementing mtime by +10 counts as 1 tick or 10 ticks.

I think the argument is that you technically violate the ISA spec if you have two cores and you increment mtime on the first core by +10 then a fraction of a nanosecond later update the second core's

Given that the device-tree mechanism is apparently already in place, it honestly probably wouldn't be a big deal to just formalize that and not require any particular mtime resolution. I still prefer

The draft says "Platform must support a default ACLINT MTIME counter resolution of 10ns" which I interpret to mean that 100,000 always corresponds to 1ms. The point of different frequencies just means

Adding more configuration options increases complexity. Under the current draft, if software wants an interrupt 1ms in the future it can set mtimecmp to the value of mtime plus 100,000. If we make the

Could you say a bit more about the OS aspect? Is the idea that an OS must be provided access to a UART, but has the option to ignore it in favor of other I/O methods? I don't think we should allow fir

100 MHz is way more than sufficient for carrying out a Spectre attack. Web browsers limit clock resolutions to 1 kHz or even 500 Hz to disrupt those sorts of attacks (and apply other mitigations as we

Even the first-stage timeout would probably be more useful to the OS if it was a "non-maskable interrupt" or otherwise able to arrive even with sstatus.SIE bit unset. If the system has locked up to th

I suspect that given the choice, many customers of server grade platforms would much prefer to control the M-mode software running on their systems themselves. Jonathan

It might be good to add a note or requirement to the platform spec saying that the PMP granularity can be 4KB/can be at most 4KB. Jonathan

I don't think there's broad agreement that PMP has significant limitations. Do you have pointers to any work showing that an alternative approach would be substantially cheaper? For instance, for the

I don't think doing trap-and-emulate to handle reads of the watchdog timer would be much of a problem for a hypervisor. That functionality would be needed for emulating almost any other common device.

The spec requires PMP so that standard M-mode software like OpenSBI can assume that PMP is implemented. If the requirement was "PMP or any other asset protection implementation" then OpenSBI would nee

Other people can probably jump in with the official charter, but I interpret the platform spec to be defining the interfaces between all M-mode and S-mode software, plus defining any hardware interfac

+** When an illegal instruction trap is taken into S-mode, exception-specific + non-zere value must be written to the `stval` CSR. nit: When the illegal instruction is c.unimp (encoded as 0x0000) then

If writing non-zero values to mtval and stval are going to be required by OS/A-base, then I think it should require non-zero values for mtinst and htinst. The transformed instruction encodings for mti

The H-extension adds a mtinst and htinst registers. If we're requiring non-zero values in mtval and stval, shouldn't those have similar requirements?