Hi Andrew,

On Wed, Jan 19, 2022 at 11:38 AM Andrew Waterman <andrew@...> wrote:
>
>
>
> On Tue, Jan 18, 2022 at 7:48 PM Anup Patel <apatel@...> wrote:
>>
>> HI Andrew,
>>
>> On Wed, Jan 19, 2022 at 6:31 AM Andrew Waterman <andrew@...> wrote:
>> >
>> > 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 (e.g., passing a physical address as an unsigned long precludes use of the full 34-bit physical-address space), and the RV32 variants aren't currently in high demand, anyway.
>>
>> 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 4GB.
>>
>> I suggest we document this RV32 limitation in SBI RFENCE and SBI HSM
>> chapters for SBI v1.0 and plan to address this in SBI v2.0.
>
>
> 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 calls into question why we are rushing to ratify them.  So, I'll re-emphasize our suggestion that we only ratify the RV64 versions.

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 RV32
limitation. The RV32 limitation only affects SBI HSM and does not
affect any other SBI extension (including SBI RFENCE) because SBI
RFENCE calls take virtual address as "unsigned long" parameter. In
other words, on a RV32 system the SBI HSM start and suspend calls will
need a physical address within the 4GB address range.

Regards,
Anup

>
>>
>> >
>> > It would be helpful to add some non-normative text about what the SBI assumes about discovery.  For example, there's no SBI call to retrieve the value of the misa CSR--which is reasonable because the OS is presumably expected to retrieve this information from the DeviceTree--but readers who don't know that might find this surprising.
>>
>> I agree with this suggestion. We got this question multiple times in
>> the past as well.
>
>
> Cool, thanks!
>
>>
>>
>> Regards,
>> Anup
>>
>> >
>> > Thanks,
>> > Andrew
>> >
>> > On Wed, Jan 12, 2022 at 10:43 AM <atishp@...> wrote:
>> >>
>> >> I just realized that the below email was not delivered to unix
>> >> platform mailing list and
>> >> linux-riscv mailing list because of the attachment. Reseeding it again
>> >> without the
>> >> attachment. Apologies for the noise.
>> >>
>> >> -----------------------------------------------------------------------------------------------
>> >> We are delighted to announce the start of the public review period for
>> >> the Non-ISA Supervisor Binary Interface (SBI) specification. The
>> >> SBI specification is considered as frozen now as per the RISC-V International
>> >> policies.
>> >>
>> >> The review period begins today, Monday Jan 10, and ends on Monday
>> >> Jan 24 (inclusive).
>> >>
>> >> The specification can be found here
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v1.0-rc1/riscv-sbi.pdf
>> >>
>> >> which was generated from the source available in the following GitHub
>> >> repository:
>> >> https://github.com/riscv-non-isa/riscv-sbi-doc
>> >>
>> >> To respond to the public review, please either reply to this email or
>> >> send comments to the platform mailing list[1] or add issues to the
>> >> SBI GitHub repo[2]. We welcome all input and appreciate your time and
>> >> effort in helping us by reviewing the specification.
>> >>
>> >> During the public review period, corrections, comments, and
>> >> suggestions, will be gathered for review by the Platform HSC members. Any
>> >> minor corrections and/or uncontroversial changes will be incorporated
>> >> into the specification. Any remaining issues or proposed changes will
>> >> be addressed in the public review summary report. If there are no
>> >> issues that require incompatible changes to the public review
>> >> specification, the platform HSC will recommend the updated
>> >> specifications be approved and ratified by the RISC-V Technical
>> >> Steering Committee and the RISC-V Board of Directors.
>> >>
>> >> SBI specification is non-ISA specifications and will evolve over time
>> >> with new extensions as long as they are backward compatible. Any such
>> >> proposals for new extensions can be included in the future releases
>> >> after proper discussions in the platform working group meetings.
>> >>
>> >> Thanks to all the contributors for all their hard work.
>> >>
>> >> [1] tech-unixplatformspec@...
>> >> [2] https://github.com/riscv-non-isa/riscv-sbi-doc/issues
>> >>
>> >> Regards,
>> >> Atish Patra
>> >>
>> >>
>> >>
>> >>
>> >>