tech-unixplatformspec@lists.riscv.org | [PATCH 1/1] Use well defined type specifiers

Home Messages Hashtags Subgroups

Date Date 1 - 6 of 6

[PATCH 1/1] Use well defined type specifiers

Jonathan Behrens <behrensj@...> #597 On Sat, Mar 13, 2021 at 2:14 AM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> wrote: On 3/12/21 11:06 PM, Jonathan Behrens wrote: > The meaning of 'XLEN' and of 'unsigned int' are defined in the main It is nice that XLEN is defined elsewhere. But, please, do not expect the reader of the SBI specification to know where that definition is. Either we have to repeat the definition here or we have to reference the definition in that other document. As the definition is short I prefer copying it. I completely agree with you. > RISC-V spec and the relevant ABI documents > <https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md> > (someone should correct me if that link is the wrong one for the ABI > specification). The "RISC-V ELF psABI specification" is not referenced in the SBI spec. In the SBI standard we do not require the usage of any ABI defined in that standard. Wait, are we looking at the same document? The version I have says: "All SBI functions share a single binary encoding, which facilitates the mixing of SBI extensions. This binary encoding matches the RISC-V Linux syscall ABI, which itself is based on the calling convention defined in the RISC-V ELF psABI. In other words, SBI calls are exactly the same as standard RISC-V function calls except that: ..." The "RISC-V ELF psABI specification" does not define a calling convention for RV128. > > I do agree that this document could be clearer about how things are > defined, but I don't think we really need to create a new 'intn_t' type > when 'unsigned int' means the same thing for RISC-V. unsigned int is always 32 bit in the "RISC-V ELF psABI specification". My uintn_t is 32 bit on RV32, 64 bit on RV64, 128 bit on RV128. Sorry, I meant unsigned long, which is 32-bits on RV32, 64-bits on RV64, and will presumably be 128 bits on RV128 once it is defined. For a hart mask on RV128 it makes sense to use all available 128 bits. We could require the usage of the ILP32D and LP64D ABIs in the SBI spec instead of defining types intn_t and uintn_t. But that would leave the SBI interface undefined for RV128. We should reference the "RISC-V ELF psABI specification" as it defines the register synonyms a0-a7. Best regards Heinrich > > Jonathan > > On Fri, Mar 12, 2021 at 1:19 PM Heinrich Schuchardt via lists.riscv.org > <http://lists.riscv.org> <xypron.glpk=gmx.de@... > <mailto:gmx.de@...>> wrote: > > The length of int, long, unsigned long is compiler specific. We do > not want > to require the SBI and the operating system to use the same compiler. > Instead the SBI standard shall define a binary interface independent > of the > compiler used. > > * Define the constant XLEN in the text. > * Define types intn_t and uintn_t with width XLEN. > * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. > > 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on > RV32, > and 64 bit for long on RV64. Thus SBI implementations and consumers > using > these compilers will not have to be changed. > > Signed-off-by: Heinrich Schuchardt <xypron.glpk@... > <mailto:xypron.glpk@...>> > --- > riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- > 1 file changed, 68 insertions(+), 58 deletions(-) > > diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc > index 090f10a..ad6911f 100644 > --- a/riscv-sbi.adoc > +++ b/riscv-sbi.adoc > @@ -79,6 +79,17 @@ function calls except that: > * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension > ID (EID), > which matches how the system call ID is encoded in Linux system > call ABI. > > +Throughout the text the constant XLEN refers to the number of bits > in an integer > +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like > int and long > +are compiler specific we use the following types in our API > description: > + > +[cols="1,2", width=90%, align="center", options="header"] > +\|=== > +\| Type \| Definition > +\| intn_t \| signed integer type with XLEN bits > +\| uintn_t \| unsigned integer type with XLEN bits > +\|=== > + > Many SBI extensions also chose to encode an additional SBI > function ID (FID) > in `a6`, a scheme similar to the `ioctl()` system call on many > UNIX operating > systems. This allows SBI extensions to encode multiple functions > within the > @@ -94,8 +105,8 @@ returning an error code. This is analogous to > returning the C structure > [source, C] > ---- > struct sbiret { > - long error; > - long value; > + intn_t error; > + intn_t value; > }; > ---- > > @@ -116,7 +127,7 @@ Standard SBI error codes are listed below > An `ECALL` with an unsupported SBI extension ID (EID) or an > unsupported SBI > function ID (FID) must return the error code > `SBI_ERR_NOT_SUPPORTED`. > > -Every SBI function should prefer `unsigned long` as the data type. > It keeps > +Every SBI function should prefer `uintn_t` as the data type. It keeps > the specification simple and easily adaptable for all RISC-V ISA > types (i.e. > RV32, RV64 and RV128). In case the data is defined as 32bit wide, > higher > privilege software must ensure that it only uses 32 bit data only. > @@ -127,8 +138,8 @@ defined in or after v0.2. > > Any function, requiring a hart mask, need to pass following two > arguments. > > -* `unsigned long hart_mask` is a scalar bit-vector containing hartids > -* `unsigned long hart_mask_base` is the starting hartid from which > bit-vector > +* `uintn_t hart_mask` is a scalar bit-vector containing hartids > +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector > must be computed. > > In a single SBI function call, maximum number harts that can be set is > @@ -193,7 +204,7 @@ number is specific to the SBI implementation. > > [source, C] > ---- > -struct sbiret sbi_probe_extension(long extension_id); > +struct sbiret sbi_probe_extension(intn_t extension_id); > ---- > > Returns 0 if the given SBI extension ID (EID) is not available, > or an > @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. > > [source, C] > ---- > -void sbi_console_putchar(int ch) > +void sbi_console_putchar(int32_t ch) > ---- > > Write data present in ch to debug console. > @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. > > [source, C] > ---- > -void sbi_send_ipi(const unsigned long hart_mask) > +void sbi_send_ipi(const uintn_t hart_mask) > ---- > > Send an inter-processor interrupt to all the harts defined in > hart_mask. > @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the > receiving harts as Supervisor > Software Interrupts. > > hart_mask is a virtual address that points to a bit-vector of > harts. The > -bit vector is represented as a sequence of unsigned longs whose length > -equals the number of harts in the system divided by the number of bits > -in an unsigned long, rounded up to the next integer. > +bit vector is represented as a sequence of uintn_t whose length > equals the > +number of harts in the system divided by XLEN, rounded up to the > next integer. > > === Extension: Remote FENCE.I (EID #0x05) > > [source, C] > ---- > -void sbi_remote_fence_i(const unsigned long hart_mask) > +void sbi_remote_fence_i(const uintn_t hart_mask) > ---- > > Instructs remote harts to execute `FENCE.I` instruction. The > `hart_mask` > @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. > > [source, C] > ---- > -void sbi_remote_sfence_vma(const unsigned long hart_mask, > - unsigned long start, > - unsigned long size) > +void sbi_remote_sfence_vma(const uintn_t hart_mask, > + uintn_t start, > + uintn_t size) > ---- > > Instructs the remote harts to execute one or more `SFENCE.VMA` > instructions, > @@ -360,10 +370,10 @@ covering the range of virtual addresses > between start and size. > > [source, C] > ---- > -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, > - unsigned long start, > - unsigned long size, > - unsigned long asid) > +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, > + uintn_t start, > + uintn_t size, > + uintn_t asid) > ---- > > Instruct the remote harts to execute one or more `SFENCE.VMA` > instructions, > @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary > encoding section. > > [source, C] > ---- > -struct sbiret sbi_send_ipi(unsigned long hart_mask, > - unsigned long hart_mask_base) > +struct sbiret sbi_send_ipi(uintn_t hart_mask, > + uintn_t hart_mask_base) > ---- > > Send an inter-processor interrupt to all the harts defined in > hart_mask. > @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB > flush if > > [source, C] > ---- > -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, > - unsigned long hart_mask_base) > +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, > + uintn_t hart_mask_base) > ---- > Instructs remote harts to execute `FENCE.I` instruction. > > @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` > instruction. > > [source, C] > ---- > -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size) > +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size) > ---- > > Instructs the remote harts to execute one or more `SFENCE.VMA` > instructions, > @@ -517,11 +527,11 @@ covering the range of virtual addresses > between start and size. > > [source, C] > ---- > -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size, > - unsigned long asid) > +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size, > + uintn_t asid) > ---- > > Instruct the remote harts to execute one or more `SFENCE.VMA` > instructions, > @@ -542,11 +552,11 @@ only the given `ASID`. > > [source, C] > ---- > -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size, > - unsigned long vmid) > +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size, > + uintn_t vmid) > ---- > > Instruct the remote harts to execute one or more `HFENCE.GVMA` > instructions, > @@ -571,10 +581,10 @@ hypervisor extension. > > [source, C] > ---- > -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size) > +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size) > ---- > > Instruct the remote harts to execute one or more `HFENCE.GVMA` > instructions, > @@ -599,11 +609,11 @@ extension. > > [source, C] > ---- > -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size, > - unsigned long asid) > +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size, > + uintn_t asid) > ---- > > Instruct the remote harts to execute one or more `HFENCE.VVMA` > instructions, > @@ -628,10 +638,10 @@ call is only valid for harts implementing > hypervisor extension. > > [source, C] > ---- > -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, > - unsigned long hart_mask_base, > - unsigned long start_addr, > - unsigned long size) > +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, > + uintn_t hart_mask_base, > + uintn_t start_addr, > + uintn_t size) > ---- > > Instruct the remote harts to execute one or more `HFENCE.VVMA` > instructions, > @@ -748,9 +758,9 @@ following approaches: > > [source, C] > ---- > -struct sbiret sbi_hart_start(unsigned long hartid, > - unsigned long start_addr, > - unsigned long opaque) > +struct sbiret sbi_hart_start(uintn_t hartid, > + uintn_t start_addr, > + uintn_t opaque) > ---- > > Request the SBI implementation to start executing the target hart in > @@ -834,7 +844,7 @@ The possible error codes returned in > `sbiret.error` are shown in the > > [source, C] > ---- > -struct sbiret sbi_hart_get_status(unsigned long hartid) > +struct sbiret sbi_hart_get_status(uintn_t hartid) > ---- > > Get the current status (or HSM state id) of the given hart in > `sbiret.value`, > @@ -867,8 +877,8 @@ of the hart at the time of return value > verification. > [source, C] > ---- > struct sbiret sbi_hart_suspend(uint32_t suspend_type, > - unsigned long resume_addr, > - unsigned long opaque) > + uintn_t resume_addr, > + uintn_t opaque) > ---- > > Request the SBI implementation to put the calling hart in a > platform specfic > @@ -972,8 +982,8 @@ implementation could be machine mode firmware or > hypervisor. > > [source, C] > ---- > -struct sbiret sbi_system_reset(unsigned long reset_type, > - unsigned long reset_reason) > +struct sbiret sbi_system_reset(uintn_t reset_type, > + uintn_t reset_reason) > ---- > > Reset the system based on provided `reset_type` and > `reset_reason`. This is > -- > 2.30.1 > > > > ------------ > Links: You receive all messages sent to this group. > View/Reply Online (#592): > https://lists.riscv.org/g/tech-unixplatformspec/message/592 > <https://lists.riscv.org/g/tech-unixplatformspec/message/592> > Mute This Topic: https://lists.riscv.org/mt/81286360/1775851 > <https://lists.riscv.org/mt/81286360/1775851> > Group Owner: tech-unixplatformspec+owner@... > <mailto:tech-unixplatformspec%2Bowner@...> > Unsubscribe: https://lists.riscv.org/g/tech-unixplatformspec/unsub > <https://lists.riscv.org/g/tech-unixplatformspec/unsub> > [behrensj@... <mailto:behrensj@...>] > ------------ > >
More All Messages By This Member
Heinrich Schuchardt #596 On 3/12/21 11:06 PM, Jonathan Behrens wrote: The meaning of 'XLEN' and of 'unsigned int' are defined in the main It is nice that XLEN is defined elsewhere. But, please, do not expect the reader of the SBI specification to know where that definition is. Either we have to repeat the definition here or we have to reference the definition in that other document. As the definition is short I prefer copying it. RISC-V spec and the relevant ABI documents <https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md> (someone should correct me if that link is the wrong one for the ABI specification). The "RISC-V ELF psABI specification" is not referenced in the SBI spec. In the SBI standard we do not require the usage of any ABI defined in that standard. The "RISC-V ELF psABI specification" does not define a calling convention for RV128. I do agree that this document could be clearer about how things are defined, but I don't think we really need to create a new 'intn_t' type when 'unsigned int' means the same thing for RISC-V. unsigned int is always 32 bit in the "RISC-V ELF psABI specification". My uintn_t is 32 bit on RV32, 64 bit on RV64, 128 bit on RV128. For a hart mask on RV128 it makes sense to use all available 128 bits. We could require the usage of the ILP32D and LP64D ABIs in the SBI spec instead of defining types intn_t and uintn_t. But that would leave the SBI interface undefined for RV128. We should reference the "RISC-V ELF psABI specification" as it defines the register synonyms a0-a7. Best regards Heinrich Jonathan On Fri, Mar 12, 2021 at 1:19 PM Heinrich Schuchardt via lists.riscv.org <http://lists.riscv.org> <xypron.glpk=gmx.de@... <mailto:gmx.de@...>> wrote: The length of int, long, unsigned long is compiler specific. We do not want to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary interface independent of the compiler used. * Define the constant XLEN in the text. * Define types intn_t and uintn_t with width XLEN. * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on RV32, and 64 bit for long on RV64. Thus SBI implementations and consumers using these compilers will not have to be changed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> --- riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- 1 file changed, 68 insertions(+), 58 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 090f10a..ad6911f 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -79,6 +79,17 @@ function calls except that: * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (EID), which matches how the system call ID is encoded in Linux system call ABI. +Throughout the text the constant XLEN refers to the number of bits in an integer +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like int and long +are compiler specific we use the following types in our API description: + +[cols="1,2", width=90%, align="center", options="header"] +\|=== +\| Type \| Definition +\| intn_t \| signed integer type with XLEN bits +\| uintn_t \| unsigned integer type with XLEN bits +\|=== + Many SBI extensions also chose to encode an additional SBI function ID (FID) in `a6`, a scheme similar to the `ioctl()` system call on many UNIX operating systems. This allows SBI extensions to encode multiple functions within the @@ -94,8 +105,8 @@ returning an error code. This is analogous to returning the C structure [source, C] ---- struct sbiret { - long error; - long value; + intn_t error; + intn_t value; }; ---- @@ -116,7 +127,7 @@ Standard SBI error codes are listed below An `ECALL` with an unsupported SBI extension ID (EID) or an unsupported SBI function ID (FID) must return the error code `SBI_ERR_NOT_SUPPORTED`. -Every SBI function should prefer `unsigned long` as the data type. It keeps +Every SBI function should prefer `uintn_t` as the data type. It keeps the specification simple and easily adaptable for all RISC-V ISA types (i.e. RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher privilege software must ensure that it only uses 32 bit data only. @@ -127,8 +138,8 @@ defined in or after v0.2. Any function, requiring a hart mask, need to pass following two arguments. -* `unsigned long hart_mask` is a scalar bit-vector containing hartids -* `unsigned long hart_mask_base` is the starting hartid from which bit-vector +* `uintn_t hart_mask` is a scalar bit-vector containing hartids +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector must be computed. In a single SBI function call, maximum number harts that can be set is @@ -193,7 +204,7 @@ number is specific to the SBI implementation. [source, C] ---- -struct sbiret sbi_probe_extension(long extension_id); +struct sbiret sbi_probe_extension(intn_t extension_id); ---- Returns 0 if the given SBI extension ID (EID) is not available, or an @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. [source, C] ---- -void sbi_console_putchar(int ch) +void sbi_console_putchar(int32_t ch) ---- Write data present in ch to debug console. @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. [source, C] ---- -void sbi_send_ipi(const unsigned long hart_mask) +void sbi_send_ipi(const uintn_t hart_mask) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the receiving harts as Supervisor Software Interrupts. hart_mask is a virtual address that points to a bit-vector of harts. The -bit vector is represented as a sequence of unsigned longs whose length -equals the number of harts in the system divided by the number of bits -in an unsigned long, rounded up to the next integer. +bit vector is represented as a sequence of uintn_t whose length equals the +number of harts in the system divided by XLEN, rounded up to the next integer. === Extension: Remote FENCE.I (EID #0x05) [source, C] ---- -void sbi_remote_fence_i(const unsigned long hart_mask) +void sbi_remote_fence_i(const uintn_t hart_mask) ---- Instructs remote harts to execute `FENCE.I` instruction. The `hart_mask` @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. [source, C] ---- -void sbi_remote_sfence_vma(const unsigned long hart_mask, - unsigned long start, - unsigned long size) +void sbi_remote_sfence_vma(const uintn_t hart_mask, + uintn_t start, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -360,10 +370,10 @@ covering the range of virtual addresses between start and size. [source, C] ---- -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, - unsigned long start, - unsigned long size, - unsigned long asid) +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, + uintn_t start, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary encoding section. [source, C] ---- -struct sbiret sbi_send_ipi(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_send_ipi(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB flush if [source, C] ---- -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Instructs remote harts to execute `FENCE.I` instruction. @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` instruction. [source, C] ---- -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -517,11 +527,11 @@ covering the range of virtual addresses between start and size. [source, C] ---- -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -542,11 +552,11 @@ only the given `ASID`. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long vmid) +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t vmid) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -571,10 +581,10 @@ hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -599,11 +609,11 @@ extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -628,10 +638,10 @@ call is only valid for harts implementing hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -748,9 +758,9 @@ following approaches: [source, C] ---- -struct sbiret sbi_hart_start(unsigned long hartid, - unsigned long start_addr, - unsigned long opaque) +struct sbiret sbi_hart_start(uintn_t hartid, + uintn_t start_addr, + uintn_t opaque) ---- Request the SBI implementation to start executing the target hart in @@ -834,7 +844,7 @@ The possible error codes returned in `sbiret.error` are shown in the [source, C] ---- -struct sbiret sbi_hart_get_status(unsigned long hartid) +struct sbiret sbi_hart_get_status(uintn_t hartid) ---- Get the current status (or HSM state id) of the given hart in `sbiret.value`, @@ -867,8 +877,8 @@ of the hart at the time of return value verification. [source, C] ---- struct sbiret sbi_hart_suspend(uint32_t suspend_type, - unsigned long resume_addr, - unsigned long opaque) + uintn_t resume_addr, + uintn_t opaque) ---- Request the SBI implementation to put the calling hart in a platform specfic @@ -972,8 +982,8 @@ implementation could be machine mode firmware or hypervisor. [source, C] ---- -struct sbiret sbi_system_reset(unsigned long reset_type, - unsigned long reset_reason) +struct sbiret sbi_system_reset(uintn_t reset_type, + uintn_t reset_reason) ---- Reset the system based on provided `reset_type` and `reset_reason`. This is -- 2.30.1 ------------ Links: You receive all messages sent to this group. View/Reply Online (#592): https://lists.riscv.org/g/tech-unixplatformspec/message/592 <https://lists.riscv.org/g/tech-unixplatformspec/message/592> Mute This Topic: https://lists.riscv.org/mt/81286360/1775851 <https://lists.riscv.org/mt/81286360/1775851> Group Owner: tech-unixplatformspec+owner@... <mailto:tech-unixplatformspec%2Bowner@...> Unsubscribe: https://lists.riscv.org/g/tech-unixplatformspec/unsub <https://lists.riscv.org/g/tech-unixplatformspec/unsub> [behrensj@... <mailto:behrensj@...>] ------------
More All Messages By This Member
Jonathan Behrens <behrensj@...> #595 I think there's some confusion here. SBI is a binary interface, so the C functions are just shorthand for describing the input and output meanings of each register. The two sides of the interface defined in the document might be compiled with different compilers or even written in entirely different programming languages, and in practice will probably use inline assembly to get the register configuration correct. Chapter 2 of the SBI spec describes the binary interface so if something is unclear, that is probably the place that should be improved. Jonathan toggle quoted message Show quoted text On Fri, Mar 12, 2021 at 5:57 PM Nick Knight via lists.riscv.org <nick.knight=sifive.com@...> wrote: The width of int, long, etc., depend on the ABI. Perhaps we don't see issues right now when considering the "standard" ABIs currently defined in the psABI. However, new ABIs, like ilp32 for rv64, could break assumptions we're making. I think we should be explicit about the type-widths we assume. One approach is to explicitly couple ourselves to a particular ABI. Another approach is to decouple by using XLEN-width types. This debate has arisen independently in almost every task-group I follow. I'm optimistic my preferred solution, https://github.com/riscv/riscv-c-api-doc/pull/14 , will eventually gain acceptance. Best, Nick Knight On Fri, Mar 12, 2021 at 2:06 PM Jonathan Behrens <behrensj@...> wrote: The meaning of 'XLEN' and of 'unsigned int' are defined in the main RISC-V spec and the relevant ABI documents (someone should correct me if that link is the wrong one for the ABI specification). I do agree that this document could be clearer about how things are defined, but I don't think we really need to create a new 'intn_t' type when 'unsigned int' means the same thing for RISC-V. Jonathan On Fri, Mar 12, 2021 at 1:19 PM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> wrote: The length of int, long, unsigned long is compiler specific. We do not want to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary interface independent of the compiler used. * Define the constant XLEN in the text. * Define types intn_t and uintn_t with width XLEN. * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on RV32, and 64 bit for long on RV64. Thus SBI implementations and consumers using these compilers will not have to be changed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@...> --- riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- 1 file changed, 68 insertions(+), 58 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 090f10a..ad6911f 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -79,6 +79,17 @@ function calls except that: * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (EID), which matches how the system call ID is encoded in Linux system call ABI. +Throughout the text the constant XLEN refers to the number of bits in an integer +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like int and long +are compiler specific we use the following types in our API description: + +[cols="1,2", width=90%, align="center", options="header"] +\|=== +\| Type \| Definition +\| intn_t \| signed integer type with XLEN bits +\| uintn_t \| unsigned integer type with XLEN bits +\|=== + Many SBI extensions also chose to encode an additional SBI function ID (FID) in `a6`, a scheme similar to the `ioctl()` system call on many UNIX operating systems. This allows SBI extensions to encode multiple functions within the @@ -94,8 +105,8 @@ returning an error code. This is analogous to returning the C structure [source, C] ---- struct sbiret { - long error; - long value; + intn_t error; + intn_t value; }; ---- @@ -116,7 +127,7 @@ Standard SBI error codes are listed below An `ECALL` with an unsupported SBI extension ID (EID) or an unsupported SBI function ID (FID) must return the error code `SBI_ERR_NOT_SUPPORTED`. -Every SBI function should prefer `unsigned long` as the data type. It keeps +Every SBI function should prefer `uintn_t` as the data type. It keeps the specification simple and easily adaptable for all RISC-V ISA types (i.e. RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher privilege software must ensure that it only uses 32 bit data only. @@ -127,8 +138,8 @@ defined in or after v0.2. Any function, requiring a hart mask, need to pass following two arguments. -* `unsigned long hart_mask` is a scalar bit-vector containing hartids -* `unsigned long hart_mask_base` is the starting hartid from which bit-vector +* `uintn_t hart_mask` is a scalar bit-vector containing hartids +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector must be computed. In a single SBI function call, maximum number harts that can be set is @@ -193,7 +204,7 @@ number is specific to the SBI implementation. [source, C] ---- -struct sbiret sbi_probe_extension(long extension_id); +struct sbiret sbi_probe_extension(intn_t extension_id); ---- Returns 0 if the given SBI extension ID (EID) is not available, or an @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. [source, C] ---- -void sbi_console_putchar(int ch) +void sbi_console_putchar(int32_t ch) ---- Write data present in ch to debug console. @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. [source, C] ---- -void sbi_send_ipi(const unsigned long hart_mask) +void sbi_send_ipi(const uintn_t hart_mask) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the receiving harts as Supervisor Software Interrupts. hart_mask is a virtual address that points to a bit-vector of harts. The -bit vector is represented as a sequence of unsigned longs whose length -equals the number of harts in the system divided by the number of bits -in an unsigned long, rounded up to the next integer. +bit vector is represented as a sequence of uintn_t whose length equals the +number of harts in the system divided by XLEN, rounded up to the next integer. === Extension: Remote FENCE.I (EID #0x05) [source, C] ---- -void sbi_remote_fence_i(const unsigned long hart_mask) +void sbi_remote_fence_i(const uintn_t hart_mask) ---- Instructs remote harts to execute `FENCE.I` instruction. The `hart_mask` @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. [source, C] ---- -void sbi_remote_sfence_vma(const unsigned long hart_mask, - unsigned long start, - unsigned long size) +void sbi_remote_sfence_vma(const uintn_t hart_mask, + uintn_t start, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -360,10 +370,10 @@ covering the range of virtual addresses between start and size. [source, C] ---- -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, - unsigned long start, - unsigned long size, - unsigned long asid) +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, + uintn_t start, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary encoding section. [source, C] ---- -struct sbiret sbi_send_ipi(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_send_ipi(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB flush if [source, C] ---- -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Instructs remote harts to execute `FENCE.I` instruction. @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` instruction. [source, C] ---- -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -517,11 +527,11 @@ covering the range of virtual addresses between start and size. [source, C] ---- -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -542,11 +552,11 @@ only the given `ASID`. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long vmid) +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t vmid) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -571,10 +581,10 @@ hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -599,11 +609,11 @@ extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -628,10 +638,10 @@ call is only valid for harts implementing hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -748,9 +758,9 @@ following approaches: [source, C] ---- -struct sbiret sbi_hart_start(unsigned long hartid, - unsigned long start_addr, - unsigned long opaque) +struct sbiret sbi_hart_start(uintn_t hartid, + uintn_t start_addr, + uintn_t opaque) ---- Request the SBI implementation to start executing the target hart in @@ -834,7 +844,7 @@ The possible error codes returned in `sbiret.error` are shown in the [source, C] ---- -struct sbiret sbi_hart_get_status(unsigned long hartid) +struct sbiret sbi_hart_get_status(uintn_t hartid) ---- Get the current status (or HSM state id) of the given hart in `sbiret.value`, @@ -867,8 +877,8 @@ of the hart at the time of return value verification. [source, C] ---- struct sbiret sbi_hart_suspend(uint32_t suspend_type, - unsigned long resume_addr, - unsigned long opaque) + uintn_t resume_addr, + uintn_t opaque) ---- Request the SBI implementation to put the calling hart in a platform specfic @@ -972,8 +982,8 @@ implementation could be machine mode firmware or hypervisor. [source, C] ---- -struct sbiret sbi_system_reset(unsigned long reset_type, - unsigned long reset_reason) +struct sbiret sbi_system_reset(uintn_t reset_type, + uintn_t reset_reason) ---- Reset the system based on provided `reset_type` and `reset_reason`. This is -- 2.30.1 ------------ Links: You receive all messages sent to this group. View/Reply Online (#592): https://lists.riscv.org/g/tech-unixplatformspec/message/592 Mute This Topic: https://lists.riscv.org/mt/81286360/1775851 Group Owner: tech-unixplatformspec+owner@... Unsubscribe: https://lists.riscv.org/g/tech-unixplatformspec/unsub [behrensj@...] ------------
More All Messages By This Member
Nick Knight #594 The width of int, long, etc., depend on the ABI. Perhaps we don't see issues right now when considering the "standard" ABIs currently defined in the psABI. However, new ABIs, like ilp32 for rv64, could break assumptions we're making. I think we should be explicit about the type-widths we assume. One approach is to explicitly couple ourselves to a particular ABI. Another approach is to decouple by using XLEN-width types. This debate has arisen independently in almost every task-group I follow. I'm optimistic my preferred solution, https://github.com/riscv/riscv-c-api-doc/pull/14 , will eventually gain acceptance. Best, Nick Knight toggle quoted message Show quoted text On Fri, Mar 12, 2021 at 2:06 PM Jonathan Behrens <behrensj@...> wrote: The meaning of 'XLEN' and of 'unsigned int' are defined in the main RISC-V spec and the relevant ABI documents (someone should correct me if that link is the wrong one for the ABI specification). I do agree that this document could be clearer about how things are defined, but I don't think we really need to create a new 'intn_t' type when 'unsigned int' means the same thing for RISC-V. Jonathan On Fri, Mar 12, 2021 at 1:19 PM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> wrote: The length of int, long, unsigned long is compiler specific. We do not want to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary interface independent of the compiler used. * Define the constant XLEN in the text. * Define types intn_t and uintn_t with width XLEN. * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on RV32, and 64 bit for long on RV64. Thus SBI implementations and consumers using these compilers will not have to be changed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@...> --- riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- 1 file changed, 68 insertions(+), 58 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 090f10a..ad6911f 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -79,6 +79,17 @@ function calls except that: * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (EID), which matches how the system call ID is encoded in Linux system call ABI. +Throughout the text the constant XLEN refers to the number of bits in an integer +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like int and long +are compiler specific we use the following types in our API description: + +[cols="1,2", width=90%, align="center", options="header"] +\|=== +\| Type \| Definition +\| intn_t \| signed integer type with XLEN bits +\| uintn_t \| unsigned integer type with XLEN bits +\|=== + Many SBI extensions also chose to encode an additional SBI function ID (FID) in `a6`, a scheme similar to the `ioctl()` system call on many UNIX operating systems. This allows SBI extensions to encode multiple functions within the @@ -94,8 +105,8 @@ returning an error code. This is analogous to returning the C structure [source, C] ---- struct sbiret { - long error; - long value; + intn_t error; + intn_t value; }; ---- @@ -116,7 +127,7 @@ Standard SBI error codes are listed below An `ECALL` with an unsupported SBI extension ID (EID) or an unsupported SBI function ID (FID) must return the error code `SBI_ERR_NOT_SUPPORTED`. -Every SBI function should prefer `unsigned long` as the data type. It keeps +Every SBI function should prefer `uintn_t` as the data type. It keeps the specification simple and easily adaptable for all RISC-V ISA types (i.e. RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher privilege software must ensure that it only uses 32 bit data only. @@ -127,8 +138,8 @@ defined in or after v0.2. Any function, requiring a hart mask, need to pass following two arguments. -* `unsigned long hart_mask` is a scalar bit-vector containing hartids -* `unsigned long hart_mask_base` is the starting hartid from which bit-vector +* `uintn_t hart_mask` is a scalar bit-vector containing hartids +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector must be computed. In a single SBI function call, maximum number harts that can be set is @@ -193,7 +204,7 @@ number is specific to the SBI implementation. [source, C] ---- -struct sbiret sbi_probe_extension(long extension_id); +struct sbiret sbi_probe_extension(intn_t extension_id); ---- Returns 0 if the given SBI extension ID (EID) is not available, or an @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. [source, C] ---- -void sbi_console_putchar(int ch) +void sbi_console_putchar(int32_t ch) ---- Write data present in ch to debug console. @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. [source, C] ---- -void sbi_send_ipi(const unsigned long hart_mask) +void sbi_send_ipi(const uintn_t hart_mask) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the receiving harts as Supervisor Software Interrupts. hart_mask is a virtual address that points to a bit-vector of harts. The -bit vector is represented as a sequence of unsigned longs whose length -equals the number of harts in the system divided by the number of bits -in an unsigned long, rounded up to the next integer. +bit vector is represented as a sequence of uintn_t whose length equals the +number of harts in the system divided by XLEN, rounded up to the next integer. === Extension: Remote FENCE.I (EID #0x05) [source, C] ---- -void sbi_remote_fence_i(const unsigned long hart_mask) +void sbi_remote_fence_i(const uintn_t hart_mask) ---- Instructs remote harts to execute `FENCE.I` instruction. The `hart_mask` @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. [source, C] ---- -void sbi_remote_sfence_vma(const unsigned long hart_mask, - unsigned long start, - unsigned long size) +void sbi_remote_sfence_vma(const uintn_t hart_mask, + uintn_t start, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -360,10 +370,10 @@ covering the range of virtual addresses between start and size. [source, C] ---- -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, - unsigned long start, - unsigned long size, - unsigned long asid) +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, + uintn_t start, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary encoding section. [source, C] ---- -struct sbiret sbi_send_ipi(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_send_ipi(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB flush if [source, C] ---- -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Instructs remote harts to execute `FENCE.I` instruction. @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` instruction. [source, C] ---- -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -517,11 +527,11 @@ covering the range of virtual addresses between start and size. [source, C] ---- -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -542,11 +552,11 @@ only the given `ASID`. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long vmid) +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t vmid) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -571,10 +581,10 @@ hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -599,11 +609,11 @@ extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -628,10 +638,10 @@ call is only valid for harts implementing hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -748,9 +758,9 @@ following approaches: [source, C] ---- -struct sbiret sbi_hart_start(unsigned long hartid, - unsigned long start_addr, - unsigned long opaque) +struct sbiret sbi_hart_start(uintn_t hartid, + uintn_t start_addr, + uintn_t opaque) ---- Request the SBI implementation to start executing the target hart in @@ -834,7 +844,7 @@ The possible error codes returned in `sbiret.error` are shown in the [source, C] ---- -struct sbiret sbi_hart_get_status(unsigned long hartid) +struct sbiret sbi_hart_get_status(uintn_t hartid) ---- Get the current status (or HSM state id) of the given hart in `sbiret.value`, @@ -867,8 +877,8 @@ of the hart at the time of return value verification. [source, C] ---- struct sbiret sbi_hart_suspend(uint32_t suspend_type, - unsigned long resume_addr, - unsigned long opaque) + uintn_t resume_addr, + uintn_t opaque) ---- Request the SBI implementation to put the calling hart in a platform specfic @@ -972,8 +982,8 @@ implementation could be machine mode firmware or hypervisor. [source, C] ---- -struct sbiret sbi_system_reset(unsigned long reset_type, - unsigned long reset_reason) +struct sbiret sbi_system_reset(uintn_t reset_type, + uintn_t reset_reason) ---- Reset the system based on provided `reset_type` and `reset_reason`. This is -- 2.30.1 ------------ Links: You receive all messages sent to this group. View/Reply Online (#592): https://lists.riscv.org/g/tech-unixplatformspec/message/592 Mute This Topic: https://lists.riscv.org/mt/81286360/1775851 Group Owner: tech-unixplatformspec+owner@... Unsubscribe: https://lists.riscv.org/g/tech-unixplatformspec/unsub [behrensj@...] ------------
More All Messages By This Member
Jonathan Behrens <behrensj@...> #593 The meaning of 'XLEN' and of 'unsigned int' are defined in the main RISC-V spec and the relevant ABI documents (someone should correct me if that link is the wrong one for the ABI specification). I do agree that this document could be clearer about how things are defined, but I don't think we really need to create a new 'intn_t' type when 'unsigned int' means the same thing for RISC-V. Jonathan toggle quoted message Show quoted text On Fri, Mar 12, 2021 at 1:19 PM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> wrote: The length of int, long, unsigned long is compiler specific. We do not want to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary interface independent of the compiler used. * Define the constant XLEN in the text. * Define types intn_t and uintn_t with width XLEN. * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on RV32, and 64 bit for long on RV64. Thus SBI implementations and consumers using these compilers will not have to be changed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@...> --- riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- 1 file changed, 68 insertions(+), 58 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 090f10a..ad6911f 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -79,6 +79,17 @@ function calls except that: * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (EID), which matches how the system call ID is encoded in Linux system call ABI. +Throughout the text the constant XLEN refers to the number of bits in an integer +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like int and long +are compiler specific we use the following types in our API description: + +[cols="1,2", width=90%, align="center", options="header"] +\|=== +\| Type \| Definition +\| intn_t \| signed integer type with XLEN bits +\| uintn_t \| unsigned integer type with XLEN bits +\|=== + Many SBI extensions also chose to encode an additional SBI function ID (FID) in `a6`, a scheme similar to the `ioctl()` system call on many UNIX operating systems. This allows SBI extensions to encode multiple functions within the @@ -94,8 +105,8 @@ returning an error code. This is analogous to returning the C structure [source, C] ---- struct sbiret { - long error; - long value; + intn_t error; + intn_t value; }; ---- @@ -116,7 +127,7 @@ Standard SBI error codes are listed below An `ECALL` with an unsupported SBI extension ID (EID) or an unsupported SBI function ID (FID) must return the error code `SBI_ERR_NOT_SUPPORTED`. -Every SBI function should prefer `unsigned long` as the data type. It keeps +Every SBI function should prefer `uintn_t` as the data type. It keeps the specification simple and easily adaptable for all RISC-V ISA types (i.e. RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher privilege software must ensure that it only uses 32 bit data only. @@ -127,8 +138,8 @@ defined in or after v0.2. Any function, requiring a hart mask, need to pass following two arguments. -* `unsigned long hart_mask` is a scalar bit-vector containing hartids -* `unsigned long hart_mask_base` is the starting hartid from which bit-vector +* `uintn_t hart_mask` is a scalar bit-vector containing hartids +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector must be computed. In a single SBI function call, maximum number harts that can be set is @@ -193,7 +204,7 @@ number is specific to the SBI implementation. [source, C] ---- -struct sbiret sbi_probe_extension(long extension_id); +struct sbiret sbi_probe_extension(intn_t extension_id); ---- Returns 0 if the given SBI extension ID (EID) is not available, or an @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. [source, C] ---- -void sbi_console_putchar(int ch) +void sbi_console_putchar(int32_t ch) ---- Write data present in ch to debug console. @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. [source, C] ---- -void sbi_send_ipi(const unsigned long hart_mask) +void sbi_send_ipi(const uintn_t hart_mask) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the receiving harts as Supervisor Software Interrupts. hart_mask is a virtual address that points to a bit-vector of harts. The -bit vector is represented as a sequence of unsigned longs whose length -equals the number of harts in the system divided by the number of bits -in an unsigned long, rounded up to the next integer. +bit vector is represented as a sequence of uintn_t whose length equals the +number of harts in the system divided by XLEN, rounded up to the next integer. === Extension: Remote FENCE.I (EID #0x05) [source, C] ---- -void sbi_remote_fence_i(const unsigned long hart_mask) +void sbi_remote_fence_i(const uintn_t hart_mask) ---- Instructs remote harts to execute `FENCE.I` instruction. The `hart_mask` @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. [source, C] ---- -void sbi_remote_sfence_vma(const unsigned long hart_mask, - unsigned long start, - unsigned long size) +void sbi_remote_sfence_vma(const uintn_t hart_mask, + uintn_t start, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -360,10 +370,10 @@ covering the range of virtual addresses between start and size. [source, C] ---- -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, - unsigned long start, - unsigned long size, - unsigned long asid) +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, + uintn_t start, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary encoding section. [source, C] ---- -struct sbiret sbi_send_ipi(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_send_ipi(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB flush if [source, C] ---- -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Instructs remote harts to execute `FENCE.I` instruction. @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` instruction. [source, C] ---- -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -517,11 +527,11 @@ covering the range of virtual addresses between start and size. [source, C] ---- -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instructions, @@ -542,11 +552,11 @@ only the given `ASID`. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long vmid) +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t vmid) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -571,10 +581,10 @@ hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructions, @@ -599,11 +609,11 @@ extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -628,10 +638,10 @@ call is only valid for harts implementing hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructions, @@ -748,9 +758,9 @@ following approaches: [source, C] ---- -struct sbiret sbi_hart_start(unsigned long hartid, - unsigned long start_addr, - unsigned long opaque) +struct sbiret sbi_hart_start(uintn_t hartid, + uintn_t start_addr, + uintn_t opaque) ---- Request the SBI implementation to start executing the target hart in @@ -834,7 +844,7 @@ The possible error codes returned in `sbiret.error` are shown in the [source, C] ---- -struct sbiret sbi_hart_get_status(unsigned long hartid) +struct sbiret sbi_hart_get_status(uintn_t hartid) ---- Get the current status (or HSM state id) of the given hart in `sbiret.value`, @@ -867,8 +877,8 @@ of the hart at the time of return value verification. [source, C] ---- struct sbiret sbi_hart_suspend(uint32_t suspend_type, - unsigned long resume_addr, - unsigned long opaque) + uintn_t resume_addr, + uintn_t opaque) ---- Request the SBI implementation to put the calling hart in a platform specfic @@ -972,8 +982,8 @@ implementation could be machine mode firmware or hypervisor. [source, C] ---- -struct sbiret sbi_system_reset(unsigned long reset_type, - unsigned long reset_reason) +struct sbiret sbi_system_reset(uintn_t reset_type, + uintn_t reset_reason) ---- Reset the system based on provided `reset_type` and `reset_reason`. This is -- 2.30.1 ------------ Links: You receive all messages sent to this group. View/Reply Online (#592): https://lists.riscv.org/g/tech-unixplatformspec/message/592 Mute This Topic: https://lists.riscv.org/mt/81286360/1775851 Group Owner: tech-unixplatformspec+owner@... Unsubscribe: https://lists.riscv.org/g/tech-unixplatformspec/unsub [behrensj@...] ------------
More All Messages By This Member
Heinrich Schuchardt #592 The length of int, long, unsigned long is compiler specific. We do not wan= t to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary interface independent of th= e compiler used. * Define the constant XLEN in the text. * Define types intn_t and uintn_t with width XLEN. * Replace int, long, unsigned long by int32_t, intn_t, uintn_t. 32bit and 64bit GCC and Clang use 32 bit for int, 32 bit for long on RV32, and 64 bit for long on RV64. Thus SBI implementations and consumers using these compilers will not have to be changed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@...> =2D-- riscv-sbi.adoc \| 126 ++++++++++++++++++++++++++----------------------- 1 file changed, 68 insertions(+), 58 deletions(-) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 090f10a..ad6911f 100644 =2D-- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -79,6 +79,17 @@ function calls except that: * `a7` (or `t0` on RV32E-based systems) encodes the SBI extension ID (EI= D), which matches how the system call ID is encoded in Linux system call AB= I. +Throughout the text the constant XLEN refers to the number of bits in an = integer +register (32 for RV32, 64 for RV64, 128 for RV128). As C types like int a= nd long +are compiler specific we use the following types in our API description: + +[cols=3D"1,2", width=3D90%, align=3D"center", options=3D"header"] +\|=3D=3D=3D +\| Type \| Definition +\| intn_t \| signed integer type with XLEN bits +\| uintn_t \| unsigned integer type with XLEN bits +\|=3D=3D=3D + Many SBI extensions also chose to encode an additional SBI function ID (= FID) in `a6`, a scheme similar to the `ioctl()` system call on many UNIX opera= ting systems. This allows SBI extensions to encode multiple functions within t= he @@ -94,8 +105,8 @@ returning an error code. This is analogous to returning= the C structure [source, C] ---- struct sbiret { - long error; - long value; + intn_t error; + intn_t value; }; ---- @@ -116,7 +127,7 @@ Standard SBI error codes are listed below An `ECALL` with an unsupported SBI extension ID (EID) or an unsupported= SBI function ID (FID) must return the error code `SBI_ERR_NOT_SUPPORTED`. -Every SBI function should prefer `unsigned long` as the data type. It kee= ps +Every SBI function should prefer `uintn_t` as the data type. It keeps the specification simple and easily adaptable for all RISC-V ISA types (i= .e. RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher privilege software must ensure that it only uses 32 bit data only. @@ -127,8 +138,8 @@ defined in or after v0.2. Any function, requiring a hart mask, need to pass following two arguments= . -* `unsigned long hart_mask` is a scalar bit-vector containing hartids -* `unsigned long hart_mask_base` is the starting hartid from which bit-ve= ctor +* `uintn_t hart_mask` is a scalar bit-vector containing hartids +* `uintn_t hart_mask_base` is the starting hartid from which bit-vector must be computed. In a single SBI function call, maximum number harts that can be set is @@ -193,7 +204,7 @@ number is specific to the SBI implementation. [source, C] ---- -struct sbiret sbi_probe_extension(long extension_id); +struct sbiret sbi_probe_extension(intn_t extension_id); ---- Returns 0 if the given SBI extension ID (EID) is not available, or an @@ -286,7 +297,7 @@ interrupt by clearing `sie.STIE` CSR bit. [source, C] ---- -void sbi_console_putchar(int ch) +void sbi_console_putchar(int32_t ch) ---- Write data present in ch to debug console. @@ -322,7 +333,7 @@ S-mode code can clear `sip.SSIP` CSR bit directly. [source, C] ---- -void sbi_send_ipi(const unsigned long hart_mask) +void sbi_send_ipi(const uintn_t hart_mask) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -330,15 +341,14 @@ Interprocessor interrupts manifest at the receiving = harts as Supervisor Software Interrupts. hart_mask is a virtual address that points to a bit-vector of harts. The -bit vector is represented as a sequence of unsigned longs whose length -equals the number of harts in the system divided by the number of bits -in an unsigned long, rounded up to the next integer. +bit vector is represented as a sequence of uintn_t whose length equals th= e +number of harts in the system divided by XLEN, rounded up to the next int= eger. =3D=3D=3D Extension: Remote FENCE.I (EID #0x05) [source, C] ---- -void sbi_remote_fence_i(const unsigned long hart_mask) +void sbi_remote_fence_i(const uintn_t hart_mask) ---- Instructs remote harts to execute `FENCE.I` instruction. The `hart_mask` @@ -348,9 +358,9 @@ is same as described in `sbi_send_ipi()`. [source, C] ---- -void sbi_remote_sfence_vma(const unsigned long hart_mask, - unsigned long start, - unsigned long size) +void sbi_remote_sfence_vma(const uintn_t hart_mask, + uintn_t start, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructio= ns, @@ -360,10 +370,10 @@ covering the range of virtual addresses between star= t and size. [source, C] ---- -void sbi_remote_sfence_vma_asid(const unsigned long hart_mask, - unsigned long start, - unsigned long size, - unsigned long asid) +void sbi_remote_sfence_vma_asid(const uintn_t hart_mask, + uintn_t start, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instruction= s, @@ -436,8 +446,8 @@ follow the `hart_mask` as defined in the binary encodi= ng section. [source, C] ---- -struct sbiret sbi_send_ipi(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_send_ipi(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Send an inter-processor interrupt to all the harts defined in hart_mask. @@ -477,8 +487,8 @@ The remote fence function acts as a full TLB flush if [source, C] ---- -struct sbiret sbi_remote_fence_i(unsigned long hart_mask, - unsigned long hart_mask_base) +struct sbiret sbi_remote_fence_i(uintn_t hart_mask, + uintn_t hart_mask_base) ---- Instructs remote harts to execute `FENCE.I` instruction. @@ -494,10 +504,10 @@ Instructs remote harts to execute `FENCE.I` instruct= ion. [source, C] ---- -struct sbiret sbi_remote_sfence_vma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_sfence_vma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instructs the remote harts to execute one or more `SFENCE.VMA` instructio= ns, @@ -517,11 +527,11 @@ covering the range of virtual addresses between star= t and size. [source, C] ---- -struct sbiret sbi_remote_sfence_vma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_sfence_vma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `SFENCE.VMA` instruction= s, @@ -542,11 +552,11 @@ only the given `ASID`. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma_vmid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long vmid) +struct sbiret sbi_remote_hfence_gvma_vmid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t vmid) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructio= ns, @@ -571,10 +581,10 @@ hypervisor extension. [source, C] ---- -struct sbiret sbi_remote_hfence_gvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_gvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.GVMA` instructio= ns, @@ -599,11 +609,11 @@ extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size, - unsigned long asid) +struct sbiret sbi_remote_hfence_vvma_asid(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size, + uintn_t asid) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructio= ns, @@ -628,10 +638,10 @@ call is only valid for harts implementing hypervisor= extension. [source, C] ---- -struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask, - unsigned long hart_mask_base, - unsigned long start_addr, - unsigned long size) +struct sbiret sbi_remote_hfence_vvma(uintn_t hart_mask, + uintn_t hart_mask_base, + uintn_t start_addr, + uintn_t size) ---- Instruct the remote harts to execute one or more `HFENCE.VVMA` instructio= ns, @@ -748,9 +758,9 @@ following approaches: [source, C] ---- -struct sbiret sbi_hart_start(unsigned long hartid, - unsigned long start_addr, - unsigned long opaque) +struct sbiret sbi_hart_start(uintn_t hartid, + uintn_t start_addr, + uintn_t opaque) ---- Request the SBI implementation to start executing the target hart in @@ -834,7 +844,7 @@ The possible error codes returned in `sbiret.error` ar= e shown in the [source, C] ---- -struct sbiret sbi_hart_get_status(unsigned long hartid) +struct sbiret sbi_hart_get_status(uintn_t hartid) ---- Get the current status (or HSM state id) of the given hart in `sbiret.val= ue`, @@ -867,8 +877,8 @@ of the hart at the time of return value verification. [source, C] ---- struct sbiret sbi_hart_suspend(uint32_t suspend_type, - unsigned long resume_addr, - unsigned long opaque) + uintn_t resume_addr, + uintn_t opaque) ---- Request the SBI implementation to put the calling hart in a platform spec= fic @@ -972,8 +982,8 @@ implementation could be machine mode firmware or hyper= visor. [source, C] ---- -struct sbiret sbi_system_reset(unsigned long reset_type, - unsigned long reset_reason) +struct sbiret sbi_system_reset(uintn_t reset_type, + uintn_t reset_reason) ---- Reset the system based on provided `reset_type` and `reset_reason`. This = is =2D- 2.30.1
More All Messages By This Member

1 - 6 of 6

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms