On Wed, Sep 28, 2022 at 10:59 PM merle w <merlew4n6@...> wrote:

Anup Patel <apatel@...> 于2022年7月14日周四 17:39写道：

Hi All,

To support native debugging in S-mode and VS-mode, we need
a SBI Debug Trigger extension which complements the Sdtrig
extension.

Below is the draft proposal of the SBI Debug Trigger Extension...

Many thanks to folks (CC'ed here) who provided early feedback
and helped improve this proposal.

The proposed SBI extension is highly inspired from Linux HW
breakpoint infrastructure which is built on top of the Linux
perf subsystem.

Please review and provide your feedback.

Regards,
Anup

SBI Debug Trigger Extension (EID #0x44425452 "DBTR")
====================================================

The RISC-V Sdtrig ISA extension allows machine-mode software to
directly configure debug triggers which in-turn allows native
(or hosted) debugging without any external debugger.

The SBI debug trigger extension defines a SBI based abstraction to
provide native debugging for supervisor-mode software such that it:
1) Suitable for the rich operating systems and hypervisors running
in supervisor-mode.
2) Allows Guest (VS-mode) and Hypervisor (HS-mode) to share debug
triggers on a HART.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The base address of the physical memory MUST be 16-byte aligned
so that it is machine word aligned for RV32, RV64 and RV128.
2) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
3) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

Each debug trigger is assigned a logical number called `trig_idx`
by the SBI implementation. If total number of debug triggers are
`N` then `0 <= trig_idx < N`.

If I understand correctly, the N here should refer to the logical
trigger, not the physical number. sbi needs to maintain these logic
data, and this is related to runtime, which is difficult for sbi to
implement (if many programs are debugged at the same time, it may
take up a lot of logic triggers). I think this logical data should
be handed over to low-privilege level maintenance.

The `trig_idx` is intentionally a logical index so that Hypervisors
can share the debug triggers between guest and host. As an
example, you can look at `counter_idx` defined by SBI PMU
extension which follows a similar rationale.

This does not put any burden on M-mode firmware because
M-mode firmware can always treat "logical index" equals
"physical index".

The configuration of each debug trigger is expressed by three
entities `trig_tdata1`, `trig_tdata2`, and `trig_tdata3` which
are same as the `tdata1`, `tdata2`, and `tdata3` CSRs defined by
the RISC-V Sdtrig specification but with the following additional
constraints:
1) The `trig_tdata1.dmode` bit should always be zero.
2) The `trig_tdata1.m` bit should always be zero.
3) The `trig_tdata1.action` bits should always be zero.

The SBI implementation must also maintain an additional software
state for each debug trigger called `trig_state` which is encoded
as follows:
reserved [XLEN-1:5] - Reserved for future use.
vs [4:4] - Saved copy of the `trig_tdata1.vs` bit.
vu [3:3] - Saved copy of the `trig_tdata1.vu` bit.
s [2:2] - Saved copy of the `trig_tdata1.s` bit.
u [1:1] - Saved copy of the `trig_tdata1.u` bit.
mapped [0:0] - When set, the trigger has been mapped to
some HW debug trigger.

Function: Get number of triggers (FID #0)
-----------------------------------------

struct sbiret sbi_debug_num_triggers(unsigned long trig_tdata1)

Get the number of per-HART debug triggers which can support the
trigger configuration specified by `trig_tdata1` parameter.

The SBI implementation must return the total number of per-HART
debug triggers when `trig_tdata1 == 0`.

Returns the number of per-HART debug triggers in `sbiret.value`
and always returns SBI_SUCCESS in `sbiret.error`.

Function: Read triggers (FID #1)
--------------------------------

struct sbiret sbi_debug_read_triggers(unsigned long trig_idx_base,
unsigned long trig_count,
unsigned long out_addr_div_by_16)

Read the trigger state and configuration for a range of debug triggers
specified by `trig_idx_base` and `trig_count` parameters on the calling
HART.

The state and configuration of triggers will be written to an output
memory of size `trig_count * 4 * (XLEN / 8)` bytes. The base physical
address of the output memory right shifted by 4 is specified by the
`out_addr_div_by_16` parameter.

For i'th debug trigger in the specified range, the trigger configuration
consists of four XLEN-bit words written in little-endian format at
`offset = i * 4 * (XLEN / 8)` of the output memory. The contents of
output trigger configuration words are as follows:
word[0] = trig_state
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Configuration read successfully.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`out_addr_div_by_16` parameter is not
accessible to supervisor-mode.
SBI_ERR_INVALID_PARAM - Either `trig_idx_base + trig_count` or
`trig_idx_base` is greater than the total
number of triggers.

Function: Install triggers (FID #2)
-----------------------------------

struct sbiret sbi_debug_install_triggers(unsigned long trig_count,
unsigned long in_addr_div_by_16,
unsigned long out_addr_div_by_16)

Install debug triggers based on an array of trigger configurations
specified through an input memory and return the `trig_idx` of each
installed debug trigger in an output memory.

The `trig_count` parameter represents the number of debug triggers
to be installed.

The base physical address of the input memory right shifted by 4
is specified by the `in_addr_div_by_16` parameter and the size of
input memory is `trig_count * 4 * (XLEN / 8)` bytes. The i'th input
trigger configuration is at `offset = i * 4 * (XLEN / 8)` of the
input memory consisting of four consecutive XLEN-bit words in
little-endian format. The contents of each trigger configuration
are follows:
word[0] = Reserved for future use and should be zero
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The current debug specification has many variants: type 1, type 2,
type 6. There may be more manufacturer-defined specifications. Instead
of passing register information directly, we should need more abstraction,
which also simplifies the design of low-privilege software

We had started off with a simple abstraction which only covered type2
and type6 but quite a few folks are interested in having SBI extension
future proof so that we don't have to keep improving for other debug
trigger types.

Due to the above, we have a very generic SBI debug trigger extension
and we have sbi_debug_num_triggers() which provides some level
of discovery to S-mode software. This means if a SBI implementation
(M-mode firmware or Hypervisor) wants to only support type2 or type6
triggers then sbi_debug_num_triggers() will return non-zero only for
those types of trigger.

The base physical address of the output memory right shifted by
4 is specified by the `out_addr_div_by_16` parameter and the size
of output memory is `trig_count * (XLEN / 8)` bytes. The `trig_idx`
assigned for the i'th input trigger configuration is written at
`offset = i * (XLEN / 8)` of the output memory in little-endian
format.

For each input trigger configuration in the input memory, the SBI
implementation should:
1) Map a free `trig_idx` with an unused HW debug trigger that
matches the trigger configuration.
2) Save a copy of the `trig_tdata1.vs`, `trig_tdata1.vu`,
`trig_tdata1.s`, and `trig_tdata.u` bits in `trig_state`.
3) Update the `tdata1`, `tdata2`, and `tdata3` CSRs of the
HW debug trigger.

Additionally for each input trigger configuration chain, the
SBI implementation MUST assign contiguous `trig_idx` values
and contiguous HW debug triggers when installing debug triggers.

The last trigger configuration in the input memory MUST not have
`trig_tdata1.chain == 1` for `trig_tdata1.type = 2 or 6` to prevent
incomplete trigger configuration chain in input memory.

This function succeeds and output memory is written with `trig_idx`
values only if the SBI implementation is able to install a debug
trigger for each input trigger configuration.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Triggers installed successfully. The
`sbiret.value` will be set to zero.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`in_addr_div_by_16` or `out_addr_div_by_16`
parameter is not accessible to supervisor-mode.
The `sbiret.value` will be set to zero.
SBI_ERR_INVALID_PARAM - One of the input trigger configuration has
an invalid value. The `sbiret.value` will
be set to the array index of failing input
trigger configuration.
SBI_ERR_NOT_SUPPORTED - One of the input trigger configuration can't
be programmed due to unimplemented optional
bits in `tdata1`, `tdata2`, or `tdata3` CSRs.
The `sbiret.value` will be set to the array
index of failing input trigger configuration.
SBI_ERR_FAILED - Failed to assign `trig_idx` or HW debug
trigger for one of the input trigger
configuration. The `sbiret.value` will be
set to the array index of failing input
trigger configuration.

Function: Uninstall a set of triggers (FID #3)
----------------------------------------------

struct sbiret sbi_debug_uninstall_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Uninstall a set of debug triggers specified by the `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

For each debug trigger in the specified set of debug triggers, the
SBI implementation should:
1) Clear the `tdata1`, `tdata2`, and `tdata3` CSRs of the mapped
HW debug trigger.
2) Clear the `trig_state` of the debug trigger.
3) Unmap the HW debug trigger from `trig_idx` and free both of
them for future trigger installations.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger uninstalled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Enable a set of triggers (FID #4)
-------------------------------------------

struct sbiret sbi_debug_enable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Enable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To enable a debug trigger, SBI implementation MUST restore the
`vs`, `vu`, `s`, and `u` bits of the mapped HW debug trigger
from their saved copy in `trig_state`.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger enabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Disable a set of triggers (FID #5)
--------------------------------------------

struct sbiret sbi_debug_disable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Disable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To disable a debug trigger, SBI implementation MUST clear the `vs`,
`vu`, `s`, and `u` bits of the mapped HW debug trigger.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger disabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

We need to abstract out the breakpoint information.
e.g

struct trigger {
unsigned long addr;
unsigned long length;
unsigned long rwx_mask; /*
bit 0 -> read;
bit 1 -> write;
bit 2 -> execute */
unsigned long priv_mask; /*
bit 0 -> u;
bit 1 -> s;
bit 2 -> vu;
bit 3 -> vs */

unsigned long resource_id;
/* This records which triggers are occupied,
which is needed to undo the trigger settings */
unsigned long result；
/* This variable will be set by sbi to identify
whether the setting is successful or not */

/* Other information that may be required */
};

Different triggers can perform specific settings instead of directly
passing tdata1~tdata3

We only need two interfaces, one for install and one for uninstall.

struct sbiret sbi_debug_install_triggers(
unsigned long trig_count,
unsigned long in_addr_div_by_16);

struct sbiret sbi_debug_uninstall_triggers(
unsigned long trig_count,
unsigned long in_addr_div_by_16);

in_addr_div_by_16 points to an array of struct triggers.

See above comment.

Regards,
Anup

Regards，
Xiang W

Anup Patel <apatel@...> 于2022年7月14日周四 17:39写道：

Hi All,

To support native debugging in S-mode and VS-mode, we need
a SBI Debug Trigger extension which complements the Sdtrig
extension.

Below is the draft proposal of the SBI Debug Trigger Extension...

Many thanks to folks (CC'ed here) who provided early feedback
and helped improve this proposal.

The proposed SBI extension is highly inspired from Linux HW
breakpoint infrastructure which is built on top of the Linux
perf subsystem.

Please review and provide your feedback.

Regards,
Anup

SBI Debug Trigger Extension (EID #0x44425452 "DBTR")
====================================================

The RISC-V Sdtrig ISA extension allows machine-mode software to
directly configure debug triggers which in-turn allows native
(or hosted) debugging without any external debugger.

The SBI debug trigger extension defines a SBI based abstraction to
provide native debugging for supervisor-mode software such that it:
1) Suitable for the rich operating systems and hypervisors running
in supervisor-mode.
2) Allows Guest (VS-mode) and Hypervisor (HS-mode) to share debug
triggers on a HART.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The base address of the physical memory MUST be 16-byte aligned
so that it is machine word aligned for RV32, RV64 and RV128.
2) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
3) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

Each debug trigger is assigned a logical number called `trig_idx`
by the SBI implementation. If total number of debug triggers are
`N` then `0 <= trig_idx < N`.

If I understand correctly, the N here should refer to the logical
trigger, not the physical number. sbi needs to maintain these logic
data, and this is related to runtime, which is difficult for sbi to
implement (if many programs are debugged at the same time, it may
take up a lot of logic triggers). I think this logical data should
be handed over to low-privilege level maintenance.

The configuration of each debug trigger is expressed by three
entities `trig_tdata1`, `trig_tdata2`, and `trig_tdata3` which
are same as the `tdata1`, `tdata2`, and `tdata3` CSRs defined by
the RISC-V Sdtrig specification but with the following additional
constraints:
1) The `trig_tdata1.dmode` bit should always be zero.
2) The `trig_tdata1.m` bit should always be zero.
3) The `trig_tdata1.action` bits should always be zero.

The SBI implementation must also maintain an additional software
state for each debug trigger called `trig_state` which is encoded
as follows:
reserved [XLEN-1:5] - Reserved for future use.
vs [4:4] - Saved copy of the `trig_tdata1.vs` bit.
vu [3:3] - Saved copy of the `trig_tdata1.vu` bit.
s [2:2] - Saved copy of the `trig_tdata1.s` bit.
u [1:1] - Saved copy of the `trig_tdata1.u` bit.
mapped [0:0] - When set, the trigger has been mapped to
some HW debug trigger.

Function: Get number of triggers (FID #0)
-----------------------------------------

struct sbiret sbi_debug_num_triggers(unsigned long trig_tdata1)

Get the number of per-HART debug triggers which can support the
trigger configuration specified by `trig_tdata1` parameter.

The SBI implementation must return the total number of per-HART
debug triggers when `trig_tdata1 == 0`.

Returns the number of per-HART debug triggers in `sbiret.value`
and always returns SBI_SUCCESS in `sbiret.error`.

Function: Read triggers (FID #1)
--------------------------------

struct sbiret sbi_debug_read_triggers(unsigned long trig_idx_base,
unsigned long trig_count,
unsigned long out_addr_div_by_16)

Read the trigger state and configuration for a range of debug triggers
specified by `trig_idx_base` and `trig_count` parameters on the calling
HART.

The state and configuration of triggers will be written to an output
memory of size `trig_count * 4 * (XLEN / 8)` bytes. The base physical
address of the output memory right shifted by 4 is specified by the
`out_addr_div_by_16` parameter.

For i'th debug trigger in the specified range, the trigger configuration
consists of four XLEN-bit words written in little-endian format at
`offset = i * 4 * (XLEN / 8)` of the output memory. The contents of
output trigger configuration words are as follows:
word[0] = trig_state
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Configuration read successfully.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`out_addr_div_by_16` parameter is not
accessible to supervisor-mode.
SBI_ERR_INVALID_PARAM - Either `trig_idx_base + trig_count` or
`trig_idx_base` is greater than the total
number of triggers.

Function: Install triggers (FID #2)
-----------------------------------

struct sbiret sbi_debug_install_triggers(unsigned long trig_count,
unsigned long in_addr_div_by_16,
unsigned long out_addr_div_by_16)

Install debug triggers based on an array of trigger configurations
specified through an input memory and return the `trig_idx` of each
installed debug trigger in an output memory.

The `trig_count` parameter represents the number of debug triggers
to be installed.

The base physical address of the input memory right shifted by 4
is specified by the `in_addr_div_by_16` parameter and the size of
input memory is `trig_count * 4 * (XLEN / 8)` bytes. The i'th input
trigger configuration is at `offset = i * 4 * (XLEN / 8)` of the
input memory consisting of four consecutive XLEN-bit words in
little-endian format. The contents of each trigger configuration
are follows:
word[0] = Reserved for future use and should be zero
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The current debug specification has many variants: type 1, type 2,
type 6. There may be more manufacturer-defined specifications. Instead
of passing register information directly, we should need more abstraction,
which also simplifies the design of low-privilege software

The base physical address of the output memory right shifted by
4 is specified by the `out_addr_div_by_16` parameter and the size
of output memory is `trig_count * (XLEN / 8)` bytes. The `trig_idx`
assigned for the i'th input trigger configuration is written at
`offset = i * (XLEN / 8)` of the output memory in little-endian
format.

For each input trigger configuration in the input memory, the SBI
implementation should:
1) Map a free `trig_idx` with an unused HW debug trigger that
matches the trigger configuration.
2) Save a copy of the `trig_tdata1.vs`, `trig_tdata1.vu`,
`trig_tdata1.s`, and `trig_tdata.u` bits in `trig_state`.
3) Update the `tdata1`, `tdata2`, and `tdata3` CSRs of the
HW debug trigger.

Additionally for each input trigger configuration chain, the
SBI implementation MUST assign contiguous `trig_idx` values
and contiguous HW debug triggers when installing debug triggers.

The last trigger configuration in the input memory MUST not have
`trig_tdata1.chain == 1` for `trig_tdata1.type = 2 or 6` to prevent
incomplete trigger configuration chain in input memory.

This function succeeds and output memory is written with `trig_idx`
values only if the SBI implementation is able to install a debug
trigger for each input trigger configuration.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Triggers installed successfully. The
`sbiret.value` will be set to zero.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`in_addr_div_by_16` or `out_addr_div_by_16`
parameter is not accessible to supervisor-mode.
The `sbiret.value` will be set to zero.
SBI_ERR_INVALID_PARAM - One of the input trigger configuration has
an invalid value. The `sbiret.value` will
be set to the array index of failing input
trigger configuration.
SBI_ERR_NOT_SUPPORTED - One of the input trigger configuration can't
be programmed due to unimplemented optional
bits in `tdata1`, `tdata2`, or `tdata3` CSRs.
The `sbiret.value` will be set to the array
index of failing input trigger configuration.
SBI_ERR_FAILED - Failed to assign `trig_idx` or HW debug
trigger for one of the input trigger
configuration. The `sbiret.value` will be
set to the array index of failing input
trigger configuration.

Function: Uninstall a set of triggers (FID #3)
----------------------------------------------

struct sbiret sbi_debug_uninstall_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Uninstall a set of debug triggers specified by the `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

For each debug trigger in the specified set of debug triggers, the
SBI implementation should:
1) Clear the `tdata1`, `tdata2`, and `tdata3` CSRs of the mapped
HW debug trigger.
2) Clear the `trig_state` of the debug trigger.
3) Unmap the HW debug trigger from `trig_idx` and free both of
them for future trigger installations.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger uninstalled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Enable a set of triggers (FID #4)
-------------------------------------------

struct sbiret sbi_debug_enable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Enable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To enable a debug trigger, SBI implementation MUST restore the
`vs`, `vu`, `s`, and `u` bits of the mapped HW debug trigger
from their saved copy in `trig_state`.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger enabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Disable a set of triggers (FID #5)
--------------------------------------------

struct sbiret sbi_debug_disable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Disable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To disable a debug trigger, SBI implementation MUST clear the `vs`,
`vu`, `s`, and `u` bits of the mapped HW debug trigger.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger disabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

We need to abstract out the breakpoint information.
e.g

struct trigger {
unsigned long addr;
unsigned long length;
unsigned long rwx_mask; /*
bit 0 -> read;
bit 1 -> write;
bit 2 -> execute */
unsigned long priv_mask; /*
bit 0 -> u;
bit 1 -> s;
bit 2 -> vu;
bit 3 -> vs */

unsigned long resource_id;
/* This records which triggers are occupied,
which is needed to undo the trigger settings */
unsigned long result；
/* This variable will be set by sbi to identify
whether the setting is successful or not */

/* Other information that may be required */
};

Different triggers can perform specific settings instead of directly
passing tdata1~tdata3

We only need two interfaces, one for install and one for uninstall.

struct sbiret sbi_debug_install_triggers(
unsigned long trig_count,
unsigned long in_addr_div_by_16);

struct sbiret sbi_debug_uninstall_triggers(
unsigned long trig_count,
unsigned long in_addr_div_by_16);

in_addr_div_by_16 points to an array of struct triggers.

Regards，
Xiang W

To implement hardware breakpoints and watchpoints on the riscv, the trigger in M
mode is required. We need an sbi extension for debugging to set the trigger.

Please give suggestions and feedback.

Regards,
Xiang W




Debug Extension (EID #0x44424755 "DBG")
=======================================

Function: Set Tiggers(FID #0)
-----------------------------

```c
struct trigger {
unsigned long address;
unsigned long length;
unsigned long rwx_mask;
unsigned long privilege_mask;
unsigned long resource_id;
};
```

rwx_mask:
bit 0: read
bit 1: write
bit 2: execute

privilege_mask：
bit 0: U-Mode
bit 1: S-Mode
bit 2: H-Mode
bit 3: M-Mode

resource_id: This is a resource identifier, non-0, 0 is used to indicate that
the resource is free. This flag is used to associate which trigger is used, and
is useful when clearing settings.


```c
struct sbiret sbi_debug_set_triggers(unsigned long addr_lo, unsigned long addr_hi, unsigned long num);
```

addr_lo and addr_hi are used to access address ranges whose physical address
width is greater than XLEN. The addr_lo and addr_hi point to the struct trigger
array.

num represents the number of elements in the array.

Trigger is a scarce resource and should be used as the context of the program,
set when resuming execution, and cleared when swapped out. In order to reduce
the number of sbi calls, the breakpoint information is passed through an array
here.


Function: Clear Tiggers(FID #1)
--------------------------------
```c
struct sbiret sbi_debug_clear_triggers(unsigned long addr_lo, unsigned long addr_hi, unsigned long num);
```

addr_lo and addr_hi are used to access address ranges whose physical address
width is greater than XLEN. The addr_lo and addr_hi point to the struct trigger
array.

num represents the number of elements in the array.

This call will undo all trigger settings.

On Wed, Sep 7, 2022 at 8:44 AM Tianyi Xia via lists.riscv.org
<tianshi.xty=alibaba-inc.com@...> wrote:

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

I think this description is better.



Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like this:

Cluster0

Core0: base0+0x0000_0000

Core1: base0+0x0000_0008

Cluster1

Core0: base1+0x0000_0000

Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1, depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.


The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.

This case is already handled by ACLINT device tree bindings. We
just need two separate MTIMER DT nodes where the mtimecmp
base address will be different in each DT node.

Please refer to the latest OpenSBI sources.

Regards,
Anup

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

I think this description is better.

 

Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like this:

Cluster0

    Core0: base0+0x0000_0000

    Core1: base0+0x0000_0008

Cluster1

    Core0: base1+0x0000_0000

    Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1,  depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.

The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.

 

 

In the SiFive Core-Local Interruptor (CLINT) device , a core can access the mtimcmp register of all cores in the platform.

In the ACLINT spec, If a platform implements multiple MTIMER devices, such as multiple clusters, each cluster implements one MTIMER device, then a core may not be able to access the MTIMER devices of other clusters.

As I understand, it is not necessary for a core to access the mtimecmp of other cores. Is it possible to add a recommended software usage method to the ACLINT spec, for example, it is recommended that the software only use a core to access its own mtimcmp register, but not access mtimcmp of other cores. This can avoid the problem that the software uses a core to access the MTIMER devices of other clusters, but the hardware cannot support it.