Any objections with merging Ernie’s PR that allocates addresses for the *context CSRs? Note, it has been pared back from the original request and is only allocating one CSR per privilege mode, rather than a large block. 

https://github.com/riscv/riscv-isa-manual/pull/559/

On Fri, Jul 31, 2020 at 9:24 AM Ernie Edgar <ernie.edgar@...> wrote:

Hello,

Background:

You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or thread.  A modified S-mode OS kernel writes the process ID to scontext when switching processes.  Breakpoint hardware can be set to trigger only when the process ID in scontext matches the desired process.

Using ASID instead of scontext to qualify breakpoints has been suggested. However, many systems do not implement ASID or only implement a narrow field, forcing the OS to recycle ASID values.  This makes ASID useless for breakpoint qualification.

For those familiar with ARM, the equivalent registers in that architecture are CONTEXTIDR_EL1 and CONTEXTIDR_EL2.

Problem:

Scontext is defined in the ratified Debug Spec at CSR 0x7aa which is in the "Machine Standard read/write debug CSR" region and so is, by convention, inaccessible from S-mode.

The Debug Spec was ratified before work on the hypervisor had gotten very far, so Debug Spec 0.13 does not provide full support for hypervisor-based systems.  Among the missing items is a definition for an "hcontext" register to qualify breakpoints in a particular virtual machine.  An argument could be made to use VMID for this, but the discussion above about ASID qualification would also apply to VMID.

Proposed Solution:

The Debug Task Group would like to suggest allocating a range of CSR addresses in one of the Supervisor Standard read/write regions and in one of the Hypervisor Standard read/write regions to use for debug registers.  Our suggestion is 0x5A0-0x5AF for S-mode and 0x6A0-0x6AF for HS-mode, complementing the 0x7A0-0x7AF already defined for M-mode debug registers.  Allocating more than just one address gives the Debug TG flexibility for the future.

Thanks,

Ernie Edgar

RISC-V Debug Task Group

Any objections with merging Ernie’s PR that allocates addresses for the *context CSRs? Note, it has been pared back from the original request and is only allocating one CSR per privilege mode, rather than a large block. 

https://github.com/riscv/riscv-isa-manual/pull/559/

On Fri, Jul 31, 2020 at 9:24 AM Ernie Edgar <ernie.edgar@...> wrote:

Hello,

Background:

You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or thread.  A modified S-mode OS kernel writes the process ID to scontext when switching processes.  Breakpoint hardware can be set to trigger only when the process ID in scontext matches the desired process.

Using ASID instead of scontext to qualify breakpoints has been suggested. However, many systems do not implement ASID or only implement a narrow field, forcing the OS to recycle ASID values.  This makes ASID useless for breakpoint qualification.

For those familiar with ARM, the equivalent registers in that architecture are CONTEXTIDR_EL1 and CONTEXTIDR_EL2.

Problem:

Scontext is defined in the ratified Debug Spec at CSR 0x7aa which is in the "Machine Standard read/write debug CSR" region and so is, by convention, inaccessible from S-mode.

The Debug Spec was ratified before work on the hypervisor had gotten very far, so Debug Spec 0.13 does not provide full support for hypervisor-based systems.  Among the missing items is a definition for an "hcontext" register to qualify breakpoints in a particular virtual machine.  An argument could be made to use VMID for this, but the discussion above about ASID qualification would also apply to VMID.

Proposed Solution:

The Debug Task Group would like to suggest allocating a range of CSR addresses in one of the Supervisor Standard read/write regions and in one of the Hypervisor Standard read/write regions to use for debug registers.  Our suggestion is 0x5A0-0x5AF for S-mode and 0x6A0-0x6AF for HS-mode, complementing the 0x7A0-0x7AF already defined for M-mode debug registers.  Allocating more than just one address gives the Debug TG flexibility for the future.

Thanks,

Ernie Edgar

RISC-V Debug Task Group

Hello,

Background:

You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or thread.  A modified S-mode OS kernel writes the process ID to scontext when switching processes.  Breakpoint hardware can be set to trigger only when the process ID in scontext matches the desired process.

Using ASID instead of scontext to qualify breakpoints has been suggested. However, many systems do not implement ASID or only implement a narrow field, forcing the OS to recycle ASID values.  This makes ASID useless for breakpoint qualification.

For those familiar with ARM, the equivalent registers in that architecture are CONTEXTIDR_EL1 and CONTEXTIDR_EL2.

Problem:

Scontext is defined in the ratified Debug Spec at CSR 0x7aa which is in the "Machine Standard read/write debug CSR" region and so is, by convention, inaccessible from S-mode.

The Debug Spec was ratified before work on the hypervisor had gotten very far, so Debug Spec 0.13 does not provide full support for hypervisor-based systems.  Among the missing items is a definition for an "hcontext" register to qualify breakpoints in a particular virtual machine.  An argument could be made to use VMID for this, but the discussion above about ASID qualification would also apply to VMID.

Proposed Solution:

The Debug Task Group would like to suggest allocating a range of CSR addresses in one of the Supervisor Standard read/write regions and in one of the Hypervisor Standard read/write regions to use for debug registers.  Our suggestion is 0x5A0-0x5AF for S-mode and 0x6A0-0x6AF for HS-mode, complementing the 0x7A0-0x7AF already defined for M-mode debug registers.  Allocating more than just one address gives the Debug TG flexibility for the future.

Thanks,

Ernie Edgar

RISC-V Debug Task Group

Well, I'd be a little bit more specific: access can be conditioned on more than the CSR number, as the existence of Mcounteren CSR proves.

But, in that case, the register bit that controls access is static, held in a CSR, not dynamic and selected by the instruction, as a GPR value would do. 

On Thu, Aug 20, 2020 at 12:35 PM Bill Huffman <huffman@...> wrote:

Chuanhua,

The spec is set to determine writable (and required privilege) based entirely on CSR number.  Anything that determined exceptions based on data or the current value of the register has been very carefully avoided.  I expect that avoidance to continue.

I'm not knowledgeable on the proposal.   I'm just commenting on CSR instruction exceptions based on additional bits.

      Bill

On 8/19/20 9:16 PM, Chuanhua Chang wrote:

EXTERNAL MAIL

Hi, Bill,

I understand your timing concern for generating an exception based on data values. However, the concern is for data values directly read out from the general registers (GPR/FPR) by the instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

Chuanhua,

The spec is set to determine writable (and required privilege) based entirely on CSR number.  Anything that determined exceptions based on data or the current value of the register has been very carefully avoided.  I expect that avoidance to continue.

I'm not knowledgeable on the proposal.   I'm just commenting on CSR instruction exceptions based on additional bits.

      Bill

On 8/19/20 9:16 PM, Chuanhua Chang wrote:

EXTERNAL MAIL

Hi, Bill,

I understand your timing concern for generating an exception based on data values. However, the concern is for data values directly read out from the general registers (GPR/FPR) by the instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

In section 3.6.2 of the Privileged spec discussing changing PMP settings, it currently says:

"If page-based virtual memory is not implemented, or when it is disabled, memory accesses check the PMP settings synchronously, so no fence is needed."

I would like to suggest removing "or when it is disabled" and just say:

"If page-based virtual memory is not implemented, memory accesses check the PMP settings synchronously, so no fence is needed."

The motivation is that high-performance implementations that support page-based virtual memory have TLBs and want to use them to handle all fetch/load/store memory accesses as they go down load/store execution pipelines during all modes of execution - including while in M-mode.  In the case of M mode, they would effectively just be caching PMA/PMP permission/access control info (as well as identity address mappings).

For designs that implement page-based virtual memory and use their TLBs as described (which is generally true in high-performance designs), not requiring that M-mode software do an sfence.vma after a series of PMP CSR writes means that these CSR writes cannot simply be implemented as CSR writes, but instead each PMP CSR write needs to also perform a heavyweight sfence.vma operation.  This is both heavily redundant (across a series of PMP writes) and is unnatural for an aggressive o-o-o design RISC design in which an sfence.vma operation really is a very strong fencing operation as well as TLB invalidation operation.  (Put differently, a key point of RISC architecture is to simplify hardware in ways that software can easily and efficiently support.)

Given that M-mode software runs a lot of implementation-specific code (including code related with PMA and PMP management), this spec tweak allows for some implementations to simplify their hardware design and include an sfence.vma in their M-mode PMP CSR writing code (while other implementations can choose to not include an sfence.vma in their M-mode code).  But also note that all designs need to at least selectively do an sfence.vma (per section 3.6.2), so this essentially means that the M-mode code would simply always do an sfence.vma after a series of PMP writes.

Lastly note that this change is backward compatible in that software that does do an sfence.vma after PMP changes will run on "old" designs that support page-based virtual memory yet access PMA's and PMP's inline with load/store execution while in M-mode.

Any objections to this simple accomodation for high-performance CPU designs?

Greg