riscv-non-isa / riscv-sbi-doc

Documentation for the RISC-V Supervisor Binary Interface

RISC-V SBI specification

SBI (Supervisor Binary Interface) is an interface between the Supervisor Execution Environment (SEE) and the supervisor. It allows the supervisor to execute some privileged operations by using the ecall instruction. Examples of SEE and supervisor are: M-Mode and S-Mode on Unix-class platforms, where SBI is the only interface between them, as well as the Hypervisor extended-Supervisor (HS) and Virtualized Supervisor (VS).

Discussion of SBI occurs on the RISC-V Platform Runtime Services list. It is publicly readable but posting requires being a member of the RISC-V Foundation. Any new SBI extension needs to be discussed and approved there before being merged.

A list of implementations introduces SBI to M-Mode and HS-Mode software. See section "SBI Implementation IDs"

Licensing

The files in this repository are licensed under the Creative Commons Attribution 4.0 International License (CC-BY 4.0). The full license text is available at https://creativecommons.org/licenses/by/4.0/.

Dependencies

The PDF built in this project uses AsciiDoctor (Ruby). For more information on AsciiDoctor, specification guidelines, or building locally, see the RISC-V Documentation Developer Guide.

Cloning the Project

This project uses GitHub Submodules to include the RISC-V docs-resources project to achieve a common look and feel.

When cloning this repository for the first time, you must either use git clone --recurse-submodules or execute git submodule init and git submodule update after the clone to populate the docs-resources directory. Failure to clone the submodule, will result in the PDF build fail with an error message like the following:

$ make
asciidoctor-pdf \
-a toc \
-a compress \
-a pdf-style=docs-resources/themes/riscv-pdf.yml \
-a pdf-fontsdir=docs-resources/fonts \
--failure-level=ERROR \
-o profiles.pdf profiles.adoc
asciidoctor: ERROR: could not locate or load the built-in pdf theme `docs-resources/themes/riscv-pdf.yml'; reverting to default theme
No such file or directory - notoserif-regular-subset.ttf not found in docs-resources/fonts
  Use --trace for backtrace
make: *** [Makefile:7: profiles.pdf] Error 1

Building Documents

The final specification in form of PDF and HTML can be generated using make command. The makefile internally uses asciidoctor so the packages required by the makefile need to be installed on the build system using make install-debs or make install-rpms.

riscv-sbi-doc's Issues

`sbi_remote_sfence_vma` and co.: what does it mean for `start_address` or `size` to be invalid?

Currently, the documentation around the various rfence functions states that they're able to return SBI_ERR_INVALID_ADDRESS whenever start_address or size is "invalid", however its not clear how those values would be considered invalid. OpenSBI doesn't seem to check for any kind of invalid values:
https://github.com/riscv-software-src/opensbi/blob/013ba4ef3d94de67d040376535131012134ed54f/lib/sbi/sbi_tlb.c#L79-L98

void sbi_tlb_local_sfence_vma(struct sbi_tlb_info *tinfo)
{
	unsigned long start = tinfo->start;
	unsigned long size  = tinfo->size;
	unsigned long i;

	sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SFENCE_VMA_RCVD);

	if ((start == 0 && size == 0) || (size == SBI_TLB_FLUSH_ALL)) {
		tlb_flush_all();
		return;
	}

	for (i = 0; i < size; i += PAGE_SIZE) {
		__asm__ __volatile__("sfence.vma %0"
				     :
				     : "r"(start + i)
				     : "memory");
	}
}

size seems to be the size of the region in bytes to SFENCE.VMA (which I think could be made more clear as well, as in my opinion its easy to confuse size to mean either a byte size or a page count, even though the latter doesn't make sense) and OpenSBI does nothing except check for some sentinel values for some specific behaviors. Meanwhile, SFENCE.VMA can't trigger an exception as per the spec:

If the value held in rs1 is not a valid virtual address, then the SFENCE.VMA instruction has no effect. No exception is raised in this case.

And I doubt that any implementation is going to attempt to walk page tables to determine if the address is valid w.r.t virtual memory mappings.

The only error case I can think of is passing a size that's not a multiple of 4 KiB, but I'm not sure if there's sufficient reason to actually do so other than being somewhat paranoid about parameter correctness.

Type ambiguities/incosistencies

The current SBI specification assumes familiarity with C/C++ type widths, which I would argue is inappropriate for this level of documentation. I would like to see the type widths in use formally specified, ie:

int : 16 bits
long: 32 bits
long long: 64 bits

In particular, int as used in the legacy console functions could be almost anything. There are also a number of functions where the explicitly-sized types are used as well as the implicity-sized ones:

For uint64_t:

• both instances of sbi_set_timer,
• sbi_pmu_counter_config_matching,
• sbi_pmu_counter_start

For uint32_t:

• sbi_hart_suspend
• sbi_system_reset

The uint32_t are particularly confusing, as otherwise the document implies pretty strongly that long is 32 bits wide, and the examples above use both long and uint32_t. If there's some rationale for the use of both types, I didn't see it in the spec.

I believe the appropriate thing to do is:

• use the explicitly-sized types everwhere (ie, uint64_t etc), and
• define, at the beginning of the specification, what size those types are, or at least provide a reference to their definition elsewhere.

Update to RISC-V Template

Need to update the same look and feel as the other RISC-V document. This is accomplished by the following steps:

1. Utilize GitHub submodules to include a docs-resources project.
2. Updates to the README document to explain how to clone with submodules
3. Creation of an image/ directory with a riscv-images symlink into the docs-resources
4. Updates to the Makefile to use the RISC-V fonts and themes when building
5. Removal of the old theme file (riscv-sbi-theme.yaml).
6. Addition of necessary Asciidoctor variables to the main adoc file (riscv-sbi.adoc).
7. Updating the document level to 1.0-rc2 and adding change log entry (riscv-sbi.adoc)

Return values

Hi, currently one SBI call (sbi_console_getchar) returns a value, but the document doesn't explicitly specify how the value is returned (through register a0).

I am specifically interested in a corner case: If an SBI call is specified with the void return type, Is an SBI implementation allowed to set a0 to a dummy value, such as 0?

Is `sbi_cppc_read_hi` allowed to ignore reserved/unimplemented register IDs?

The documentation for sbi_cppc_read_hi currently reads:

This function always returns zero in sbiret.value when supervisor mode XLEN is 64 or higher.

Does this imply no validity checking is done when called with XLEN >= 64, or should implementations still return an error on a reserved or unimplemented register ID?

Unspecified interactions between HSM and other extensions

The SBI spec should clarify how stopping/suspending one or all harts is allowed to affect the behavior of other extensions, as well as other architectural state.

For example, the timer extension:

• Is a timer event required to fire while all harts are suspended?
• Is a future timer event required to remain armed across hart suspend?

Some further discussion (correct me if I'm wrong): https://lore.kernel.org/linux-riscv/[email protected]/T/

What about the PMU extension? Is hart suspend allowed to reset the PMU state?

SBI 3.0 work?

As part of following up on riscv-non-isa/riscv-server-platform#4, it's occurred to me I've no idea where the current SBI 3.0 draft is. Could someone point me in the right direction? I looked in the obvious places (searching for 'ras' under main branch, looking for a 3.0 draft branch etc)

v0.2: Timer and IPI extensions are missing "Function Listing" tables

The Timer and IPI extensions are missing the "Function Listing" tables present in the other extensions.

Although the Timer and IPI extensions have only a single function each, it would be
forward-thinking to define the appropriate function IDs to enable extension in the future.

Also, without function IDs, the switch from the v0.1 legacy encoding to the standard encoding provides no benefit.

Entry state unspecified

I'd expect this specification to describe the initial state of the system. That is, when whatever is supposed to use the SBI starts executing the first time. It should specify the current privilege level (supervisor mode?), the register state (opensbi and bbl pass important parameters like hart ID and FDT address in registers), and the state of other harts (opensbi and bbl start all harts that jump to the payload at the same time, which I find... surprising).

Maybe this is intentional and this is supposed to be the concern of boot loader implementations. Even then, it might be a good idea to define basic defaults.

Is shared memoy exclusive for the setting hart?

The doc defines shared memory between SBI and S-mode software at here. It says that SBI implementation needs to check S-mode software access type. I wonder whether SBI implementation needs to check the access type for all harts? or only the setting hart?

And one step further, can SBI implementation assume the share memory is exclusively owned by the setting hart and other harts have no access to it before stopping sharing?

Add SBI call to disable SBI

At the recent OSFC, the idea was raised that we'd like to have an SBI call to turn off SBI, for working with new implementations that can work without SBI being there.

We would like to add a call that permanently disables SBI. This should be pretty simple.

Clarification on `SBI_SUCCESS` return value from the `sbi_system_suspend` function

Page 48 of the v2.0-rc5 document states that sbi_system_suspend can return SBI_SUCCESS, indicating that "System has suspended and resumed successfully", except that this contradicts the earlier description

To resume, the hart will jump to supervisor-mode, at the address specified by resume_addr, with the specific register values described in Table 52.

which implies that if the function call succeeds, there is no transfer back to the state that the caller was in, instead execution is irreversibly transferred to the address set by resume_addr with both of the possible return value registers set to the hart ID and opaque value, thus SBI_SUCCESS is never observable. Is my interpretation correct here?

Clarification needed for sbi_pmu_counter_start

The current spec says:
When SBI_PMU_START_SET_INIT_VALUE is not set in start_flags, the counter value will not be modified and event counting will start from current counter value.

It should be
When SBI_PMU_START_SET_INIT_VALUE or SBI_PMU_START_FLAG_INIT_SNAPSHOT is not set in start_flags, the counter value will not be modified and event counting will start from current counter value.

Make latest release available at RISC-V Website as PDF

The RISC-V website's spec section at https://riscv.org/technical/specifications does not say anything about the SBI at the moment. The latest release should be made available there as PDF document together with a link to this repo and the latest master draft https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc. OpenSBI as reference implementation should also be linked there.

Inaccuracies of legacy SBI specification

BBL is the canonical implementation of the legacy spec, since the spec is meant to be a formalisation of BBL's behaviour; OpenSBI somewhat agrees with it, but not entirely, and the spec disagrees with both even in places where the two implementations agree.

Extension: Set Timer (EID #0x00)

This returns a long of value 0 in both BBL and OpenSBI.

Extension: Console Putchar (EID #0x01)

This returns a long of value 0 in both BBL and OpenSBI.

Extension: Console Getchar (EID #0x02)

This returns 0 in BBL when no supported UART is detected, whereas for OpenSBI it returns -1, just like if the UART's receive buffer is empty. OpenSBI's behaviour makes more sense, but is technically wrong as BBL is canonical. Both also return a long, not an int.

Extension: Clear IPI (EID #0x03)

This returns old_mip & MIP_MSIP in BBL, and 0 in OpenSBI.

Extension: Send IPI (EID #0x04)

This returns a long of value 0 in BBL, but can return errors in OpenSBI.

Extension: Remote FENCE.I (EID #0x05)

This returns a long of value 0 in BBL, but can return errors in OpenSBI.

Extension: Remote SFENCE.VMA (EID #0x06)

This returns a long of value 0 in BBL, but can return errors in OpenSBI.

Extension: Remote SFENCE.VMA with ASID (EID #0x07)

This returns a long of value 0 in BBL, but can return errors in OpenSBI.

Extension: System Shutdown (EID #0x08)

Both agree this never returns, but were it to it would return 0 in OpenSBI (BBL is unspecified, there is no return statement for mcall_shutdown).

---

When it comes to SBI calls that access memory on behalf of the supervisor, it's also totally undocumented that both will redirect page and access faults to the supervisor so it looks like the ecall faulted.

The important point though is that every single one of these returns a long (in OpenSBI it's an int that gets promoted to a long), and thus the "This is the only SBI call in the legacy extension that has a non-void return type." note for getchar is completely false. Any unknown call is handled by BBL as returning -ENOSYS, which is nonsense due to being an OS-specific errno that is wrong to use in firmware and should have been an SBI constant, but does "work" in the sense that it's a negative value and thus an error. This also means "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." does not hold for BBL.

how are arguments of sbi function passed to SEE?

Sorry, maybe I missed something, but how do the sbi functions pass their parameters to SEE.

the a7 is used to pass EID
a6 is used to pass FID,

what register is used to pass stime_value in sbi_set_timer function, for ex?
Are these a0,a1 ... as ABI mandate?

`sbi_hart_start` doesn't return `SBI_ERR_ALREADY_STARTED` when a hart is already started

When a given hart is already started and sbi_hart_start is called on it again, the spec says that it'll return SBI_ERR_ALREADY_AVAILABLE, but since the addition of the PMU extension, there's a SBI_ERR_ALREADY_STARTED error that exactly conveys the meaning of the error and would be more suitable, in my opinion.

Extension identifier 0x735049 is "sPI", not "IPI"

The head of the IPI Extension section says

IPI Extension, Extension ID: 0x735049 (IPI)

But bytes 0x73, 0x50, 0x49 are characters "sPI", not "IPI", so either the identifier number or the text equivalent is wrong in the document.

SBI Watchdog extension?

I asked in riscv-non-isa/server-soc#47 about a hardware watchdog, as feature parity-wise this is a gap, when compared to AArch64 servers. Ved pointed me at the SBI TG. Has any work started on a watchdog extension?

Advice to SBI

The sbi should provide a mechanism for the presence of detection functions. This facilitates error detection with the S-mode program and the expansion of the SBI function.

I recommend adding the following two interfaces.

/*
 * function : int sbi_has_feature(uintptr_t fid);
 * description : this is used to detect whether sbi has a certain function.
 * parameter fid : id of the function to be detected
 * return :
 *		0  - sbi provides this feature
 *		-1 - sbi does not provide this feature
 */
int sbi_has_feature(uintptr_t fid);

/*
 * function : int sbi_errno(void);
 * description : This is used to detect whether sbi has a certain function.
 * return : wrong number(the error number needs to be defined in advance 
 *          and consistently backward compatible),0 - no error.
 */
int sbi_errno(void);

`sbi_pmu_*` functions take the `counter_mask` arguments in opposite order compared to functions that use `hart_mask`

The sbi_pmu functions take the counter_mask and counter_base parameters in the opposite order than the other functions in the spec that operate on hart ID masks, which take hart_mask first and then the hart_mask_base after:

struct sbiret sbi_send_ipi(unsigned long hart_mask,
                           unsigned long hart_mask_base)

struct sbiret sbi_pmu_counter_config_matching(unsigned long counter_idx_base,
					      unsigned long counter_idx_mask,
					      unsigned long config_flags,
					      unsigned long event_idx,
					      uint64_t event_data)

This is a really unfortunate inconsistency and something that's probably quite easy to accidentally get wrong if you're familiar with the ordering from the other functions.

sbi_clear_ipi() no longer available in SBI v0.2

I noticed that sbi_clear_ipi() is no longer available in SBI v0.2 spec.
I guess the reason why it was removed is because S-mode software could do such directly from S-mode without the SBI call.

I also see these RFENCE Extension functions in the v0.2 spec. But the jobs done by these RFENCE Extension functions could also be done by calling sbi_send_ipi() plus some additional work from S-mode software.

Could someone clarify this why we only removed sbi_clear_ipi() but still keep these RFENCE Extension functions?

Does sbi_send_ipi really take a physical address?

The current document says that the argument to sbi_send_ipi should be a physical address. However, all existing implementations I could find actually expect virtual rather than physical addresses:

• BBL's send_ipi_many / load_##type uses the MPRV mechanism to load a supervisor virtual address (and I can confirm from testing that it page faults if the argument is only valid as a physical address).
• OpenSBI's code is almost exactly the same: sbi_ipi_send_many / load##type
• Linux also passes a virtual address to sbi_send_ipi.

No SBI way for supervisor to change SXLEN

It appears that the SBI specification doesn't currently support changing SXLEN. Of course, not all cores can do this, but I think it would potentially be valuable on cores that can.

I think we could add an SBI call of some kind to ask for this type of switch in either direction (32 to 64 or 64 to 32). It would allow 32-bit operating systems to try to still load, even if the SBI initially started them as 64-bit.

Now I acknowledge that while I'm currently making RISC-V CPUs, I'm not as good at this stuff yet as some others may be. Maybe it's impractical to add this, in which case I'm interested to know why.

Extension for controlling performance counters

The privileged ISR document says "The implementation should provide a mechanism to modify the counter values." (from supervisor mode). Would it make sense to add a standard SBI extension for setting counter values and their configuration registers?

Console legacy functions have not been migrated to standard extension format

What is the future library direction for the SBI console functions (getchar/putchar)? Will they remain as legacy functions? Will a new extension be created for them? Will they be deprecated?

Revert Inadvertent Commits

Looks like I inadvertently merged the wrong. Please revert these commits:

• 52d3eb3
• c80dbc0

Again, my apologies!
-Jeff

[RFC] SBI Implementation IDs experimental space

Hello,
while writing a test for KVM unit tests, to test sbi_get_impl_id() function, I realized there is no way to check if the returned value is within an acceptable range.
Discussing it with @jones-drew, he suggested to split the space in the listed implementation IDs and experimental IDs, analogous to Experimental SBI Extension IDs.
Does anybody has any objection on updating the specification to split implementation IDs to include an experimental space? If no, I'd suggest reserving the upper 8 bits for experimental ids, but I'm new to riscv so I'm not sure if this is reasonable.

Timer Extension Clarification

Is the SBI timer hart-local or system-wide? The spec is unclear on this, it seems to imply that each hart can set an independent timer, but is this actually the case?

Change branch from "master" to "main"

As a gentle reminder, the "Friendly Terminology" policy link which uses the "Inclusive Naming" community link includes the word "master" as a Tier 1: Replace Immediately word.

You can follow these steps to rename your branch: https://gist.github.com/danieldogeanu/739f88ea5312aaa23180e162e3ae89ab

Add reset function

The SBI specification provides a shutdown function, but no reset function. Reset support has been added recently to the QEMU "RISC-V VirtIO Board" machine. Would it be possible to add such a function to the SBI specifications? It's not clear to me what process has to be followed to update the specifications.

How should I get my SBI implementation ID?

I implemented my own SBI implementation for my team's project, and wonder how I can get my SBI implementation ID. Is there a test, registry or something else that I should complete first before I can get my own specific ID for my SBI?
Here is my SBI implementation, written in Rust. It implements Base, Time, sIP extensions, and a subset of Legacy ones. I'm now using it on my team's project to replace the old version of RustSBI that's now in use. The PsicaSBI can now run on k210 platform and QEMU.

Remote sfence vvma -- missing VMID argument

Section 5.3.2 of the Privileged Specification (Version 1.12) notes that the HFENCE.VVMA instruction is only operates on the guest identified by hgatp.VMID. (See also 5.5.3: "the effective ASID can be considered to be the combination of this VMID with the VS-level ASID.").

This is fairly obvious: a TLB holding guest translations needs to match against both the ASID, which is defined by the guest, and the VMID, which is defined by the hypervisor.

Hence, hagtp.VMID is an implicit operand to the HFENCE.VVMA instruction.

However, the sbi_remote_hfence_vvma_asid and sbi_remote_hfence_vvma functions do not have an argument for the VMID.

I suggest adding the VMID as an additional argument to both functions, in the fifth respectively fourth position Although this breaks the convention that semantically identical arguments are passed in identical registers, it makes the passthrough from a guest sbi_remote_fence_vma_asid and sbi_remote_fence simpler. (Or you could add a dummy argument to sbi_remote_hfence_vvma function, which would allow you to keep the VMID argument in the fifth position in both functions.)

LICENSE file needs full CC-BY-4.0 license text

Good community practice includes the full license text in the file instead of linking to it.

Unless someone has an objection, I'll update the file with the text in the next couple days. Please let me know if you have any concerns.

Why does SBI have no way to get a hart id?

There is no way to get a hart id (csr mhartid) via SBI. Is there another way or any reason?
Looks like the current RISC-V Linux implementation refers to device tree.
https://github.com/torvalds/linux/blob/master/arch/riscv/kernel/cpu.c#L25

Behavior on unknown or unimplemented SBI calls

How should an SBI implementation signal that it doesn't know the SBI call specified in a7?

[RFC] Syscall to obtain the misa?

As the MISA register is unavailable outside of machine mode, should SBI offer a syscall to obtain the supported extensions of the processor?

I'm really not seeing a method to obtain this at face value.

Regarding Unofficial hartid Transmission from Machine Mode

Hi,

I am involved in the development of an operating system that operates in Supervisor Mode. As you may be aware, it is not possible to directly retrieve hartid in Supervisor Mode. To obtain hartid, one must access the mhartid CSR, and thus, hartid can only be acquired in Machine Mode.

Upon reviewing the Linux kernel and OpenSBI, it is apparent that hartid is typically set in the a0 register, becoming an argument received by the booted entity during startup.

However, this is not a defined "specification." Depending on the implementation, it is possible that hartid may not be passed as a startup argument. Nevertheless, many implementations would likely fail to function properly without passing hartid as a startup argument. In essence, this becomes a "de facto specification." Why is it not officially specified that hartid must be passed during transitions between these different modes? I consider this to be a highly precarious situation.

If this is the wrong forum to raise this issue, I am sorry, but please let me know where to raise it.

SBI Remote Fence API: why doesn't this require the page table?

The remote fence API allows freeing of memory ranges, possibly belonging to a given ASID or VMID.

The privileged architecture specification makes it clear that a Xfence.Yvma instruction needs to be issued per page table entry that is to be invalidated; so one invalidation instruction per 4KB page in the memory range. However, with superpages, this would be reduced by a factor of 2^10 for 32-bit paging systems and a factor of 2^9 for 64 page systems per level of paging that is removed.

For an arbitrary (process) address space, there is no way for the (machine-level) SBI to discover the corresponding page table (so as to map the address range to the page table entry structure); it seems the only viable strategy for SBI is to assume that no superpages were used and to march through the memory range with a 4 KB stride.

Could you please comment if this is true? If so, I'd have to say that this part of the specification is not well thought out: convenience functions that makes things dramatically worse in certain cases. I'd much prefer the SBI to limit itself to essential functionality.

getchar/putchar interface

I notice that these functions take or result in an int. Are these interfaces intended to take only 7-bit ASCII, or should they be Unicode codepoints?

The reason I'm asking is because of getchar's use of -1 to indicate failure to retrieve a character. With a wrapper around getchar, you can use this to implement a function can_getchar, which returns true if and only if there's a character waiting, but which does not pop the character input queue. However, doing so involves locally caching the retrieved character, which seems like it should be the job of whatever is implementing the SBI.

Maybe three functions are to be preferred?

• int getchar() -- retrieves the next console character. Never blocks; -1 if not possible to grab character.
• int can_getchar() -- true if and only if getchar() will yield valid data.
• putchar(int) -- sends a character out to the console.

Just an idea.

Function to retrieve the Machine ISA CSR ``misa'' missing

I would expect a function struct sbiret sbi_get_misa (void); to be provided.

The Privileged Architecture Spec makes a clear case for this:

We require that lower privilege levels execute environment calls
instead of reading CPU registers to determine features available
at each privilege level. This enables virtualization layers
to alter the ISA observed at any level, and supports a much richer
command interface without burdening hardware designs.

How to decide Extension ID? For example: Timer Extension ID & IPI Extension ID

I was using git blame to search for "riscv-sbi.adoc" history message, and I find @atishp04 's commit(v0.1 SBI replacement extensions) which added the Timer Extension ID and IPI Extension ID.

I also searched in Mailing List discussion, but I can't find any Timer Extension ID and IPI Extension ID discussion, only system reboot extension discussion.

I want to know more about Extension ID's naming rules, and I was wondering if anyone can tell me where I can find more relevant information?

Progress of RISC-V SBI calling convention maps to the ARM PSCI calling convention

I found the following slides shows the compaison between SBI and ARM PSCI:
https://lists.riscv.org/g/tech-unixplatformspec/topic/risc_v_sbi_vs_arm_psci/77906648

And there is a topic:

How the RISC-V SBI calling convention maps to the ARM PSCI calling convention (and vice-versa)

Further more, ARM SMCCC has four registers W0 ~ W3 used to be return values, althought SBI only has a0 and a1.

Is there any progress or materials to standarize this topic?

How to add a new SBI call?

Hello all:

I implement some SBI call (non-platform-specific).

Both the Github issue & Patch talk about how to add SBI call too. (riscv-software-src/opensbi#146)
[PATCH] lib: Dynamic registration of SBI extensions http://lists.infradead.org/pipermail/opensbi/2020-January/000966.html

But the above discussions didn't touch on the standard process.

So I don't know how to define my SBI call's Extension ID. Or can I ignore it and define it myself?

Function numbers are not specified

The numbers to put in a7 are not specified.

Is there any spec to support Sdtrig extension?

Since debug triggers defined in the Sdtrig extension can only be accessed by Debug Mode and M-mode, I think an SBI extension is needed to support debug control from S-Mode software.

Status of register x1 (ra) in SBI ABI calling convention

Is x1 -- the standard return address register -- callee or caller saved in the SBI ABI? ECALL obviously does not require it, storing the return address in the epc CSR.

From a technical standpoint, I guess it would make slightly more sense to make it callee saved, as SBI calls that do not require ra, because they don't make further subroutine calls or only call "milli-code" routines using the alternative t0 register, would run slightly faster.

Send IPI: how to define the value of hart_mask and hart_mask_base

Hello folks,
I am enabling 2 harts on risc-v qemu and tries to send interrupt from hart 0 to hart 1. After reading documents, sending sbi_send_ipi is the right to do so, but how to assign hart_mask and hart_mask_base? I tried use bit filed to hart_mask, such 0b00000010 to say sending an interrupt to hart 1, but I did not receive any interrupt on hart 1.

Thanks in advance

sbi_clear_ipi deprecated?

The legacy extension sbi_clear_ipi has no equivalent in the revamped interface. Has it been deprecated?

The architecture specification makes it clear that sip.SSIP is software writeable, hence no SBI function is needed:

If implemented, SSIP is writable in sip. A supervisor-level software interrupt
is triggered on the current hart by writing 1 to SSIP, while a pending supervisor-level software
interrupt can be cleared by writing 0 to SSIP.

So sbi_clear_ipi should be deprecated (and the specification should make this explicit).

Improve error handling in sbi pmu

1. Add the following error for sbi_pmu_snapshot_set_shmem
   SBI_ERR_FAILED - The request failed for unspecified or unknown other reasons

2. SBI_ERR_INVALID_PARAM if given flag is within the reserved region.