Hi All, The next platform HSC meeting is scheduled on Mon Jan 24th 2022 at 8AM PST. Here are the details: Agenda and minutes kept on the github

Thank you for your reply

That won't be required as the specification clearly states that "SBI extensions as whole are optional but they shall not be partially implemented. If sbi_probe_extension() signals that an extension

3.4. Function: Probe SBI extension (FID #3) struct sbiret sbi_probe_extension(long extension_id); Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific

Hi Paul, Can you send a PR please? Regards Kumar

Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).

Hi Andrew, I mostly agree with your suggestion considering the fact that we have very few (or none) RV32 Linux (or RichOS) capable systems. I would also like to correct my previous comment about the

Sure. Here is the proposed diff that removed all the references to RV32 in the specification. Is it a common practice to explicitly specify in the specification that only the RV64 version is ratified

It's true that specific example is limited to those calls, but I'll re-emphase the "e.g." The RV32 variants have not gotten much road testing because there isn't much demand for them--which again

HI Andrew, The RV32 physical address space limitation only impacts SBI RFENCE calls and SBI HSM calls. A RV32 system can still use these calls as long as their physical address space is within

Hi Atish, I've got some minor feedback from the Architecture Review committee: We think that only the RV64 SBI should be ratified at this time. The RV32 variants are likely to need some reworking

I think allowing implementation-defined nonzero rather than requiring it be 1 is OK, but I agree with your proposed wording change.

Hi Abner, We need to add this requirement in the platform spec for sure. I will send the patch once this is frozen. But I think we also need to update the UEFI section 2.3.7.1 since it

Thanks. Updated as per your suggestion. https://github.com/riscv-non-isa/riscv-uefi/releases/download/0.3/EFI_RISCV_PROTOCOL-spec.pdf I will work with you, Heinrich and Abner to get an codefirst ECR

Sounds good. One minor comment: "While there can be a solution using /chosen node in DT based systems to pass this information, a simple and common interface across DT and ACPI platforms is desired

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

The description says "Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero value if it is available" The specification says it should be non-zero as the

I just sent a patch. (The main reason I didn't do that sooner was that I'm not patch-savvy. I'm more familiar with pull requests which are used by all the other RISC-V specs but which are admittedly

Signed-off-by: Paul Donahue <pdonahue@...> --- riscv-platform-spec.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index

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,