Date   

Re: Disabling and re-enabling extensions

Greg Favor
 

A potential second general requirement for all Priv extensions:

- The hart reset state must be fully specified and should generally be UNSPECIFIED except for any key control/status bits that need to be in a specific state.  (This minimizes hardware cost and leaves probably the large majority of state to be initialized by software.)

- The reset state should also specify one of:
    a) The extension is "disabled" (and most, if not all, other extension state is don't care).

    b) The extension is "enabled" and any key control/status bits are initialized to specific values as necessary (with all the rest UNSPECIFIED and left to be initialized by software).

Greg


Re: Disabling and re-enabling extensions

Greg Favor
 

On Thu, Sep 10, 2020 at 6:47 AM mark <markhimelstein@...> wrote:
Is there a checklist of requirements for priv specifications?
if not should there be?

I'm not sure, off-hand, if there is a many item list to be created or not.  (Andrew probably has better thoughts on this.)  But on the particular topic of this email thread, my leaning would be to say (to all extension TG's) the following:

- An extension spec must be "complete", i.e. it fully specifies all behaviors, including for all corner cases.

- It is alright for some behaviors to be specified as UNSPECIFIED, but it is preferable for specific behavior(s) to be specified - unless this would be burdensome on a worthwhile subset of reasonable implementations.  Further, in the latter case, specifying a bounded set of two allowed behaviors is acceptable if that would be of value to software (or compliance testing or SAIL modeling) instead of just specifying UNSPECIFIED.
 

Regarding the specific question of the H-specific state when disabling then re-enabling the H-extension (or more generally disabling then re-enabling any Priv extension), I suspect the following would be a reasonable specific behavior to specify (in the spirit of the preceding general philosophy):

When misa.H is cleared, the values of all state that become either inaccessible or masked (e.g. treated as _effectively_ a fixed value) are preserved such that these values become visible again when misa.H is set and this state becomes accessible and unmasked.

In other words, flop state is left untouched and any values that must now _appear_ as a fixed value are implemented via physical masking of the flop value (instead of changing the flop state).

Although I would try and argue - for the H-extension - that this provides no value to software (in the seemingly rare cases of this scenario happening).  In which case specifying UNSPECIFIED would seem suitable for the sake of avoiding unnecessary over-specification of behavior.

Lastly, it would seem desirable that all Priv extensions should, by default, have the same specification for what happens when the extension is disabled and then re-enabled.  In which case my own leaning would be towards the "UNSPECIFIED" option as the general default across all priv arch extensions.  Or otherwise towards the "preserve underlying state" option if Andrew or others felt this as being more appropriate.  (Or is there a better default option?)

Greg


Re: Disabling and re-enabling extensions

mark
 

Is there a checklist of requirements for priv specifications?

if not should there be?

If there is, would this be a requirement in that list to specify to some level of clarity (maybe indicating what is allowed to be left unspecified or not for example) what happens when the extension is turned off and on. and maybe provide overall guidance for future extensions.  I suggest it might be best not to just leave this up to reviews to catch these in an ad hoc manner.

Paul brought a broader set of items to light which makes me want to ask that once we answer paul and john's questions are there any others lurking out there from the past or in flight? Do we need to do a little audit?

am I misunderstanding something?

mark


On Wed, Sep 9, 2020 at 12:14 PM Paul Donahue <pdonahue@...> wrote:

In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser.  One thing that has changed is that now the architecture has an explicit goal of either describing behavior or using the term UNSPECIFIED.


To restate the question: Various extensions that add architectural state can be enabled/disabled via misa.  What happens to that architectural state if the extension is disabled and later re-enabled?


In particular, what happens to the following state if the associated misa bit is cleared and then set:

  • misa.F: FP registers and fcsr

  • misa.D: upper part of FP registers (when misa.D=0 and misa.F=1)

  • misa.Q: upper part of FP registers (when misa.Q=0 and misa.F=1)

  • misa.S: supervisor CSR state

  • misa.H: hypervisor CSR state

  • misa.V: vector state


The spec is clear about the treatment of mepc[1] and sepc[1] when misa.C is disabled and subsequently re-enabled.  That bit will contain the last written value even if the write comes while C is disabled.


In a different approach, the spec is also clear that if mstatus.FS is set to Off that the FP state is preserved.  However, this S-mode operation is different from the M-mode misa.F control.  And the question remains about disabling portions of the FP registers where implementations may continue to do single-precision operations that write (at least) the lower part of the register.


Implementations that support H are encouraged to make misa.H writable.  While support for disabling D without disabling F is potentially academic, most implementations are expected to allow software to disable and re-enable H.


I propose that there should be a sentence in the misa description that says that, unless otherwise specified, when software enables an extension that was previously disabled then all state uniquely associated with that extension is UNSPECIFIED.



Thanks,


-Paul



Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Siqi Zhao
 

Hi Greg,

Thanks for the comments.

It seems the proposal is not explicit enough about the type of interrupt. So to answer your question, with vstimecmp, there is in fact a new type of interrupt types. The new type is triggered by vstimecmp but received when the hart is at V==0, might be called SGTI (Supervisor Guest Timer Interrupt, in the same spirit as SGEI). The proposal didn't really distinguish this interrupt with VSTI. With this new interrupt type, this is how things conceptually work: the HS-mode code first receives a SGTI triggered by vstimecmp, consequently, a VSTI is generated by the HS-mode code for VS-mode to handle.

With the current specs, hip.VSTIP is used to represent pending state for both VSTI and SGTI, which can be made to work as shown in the document. Since once SGTI is pending, then the next step is naturally to make a pending VSTI for the guest. What causes the issue is that the enable bits are also shared in existing specs. I believe your comments was caused by another shared aspect which is the delegation bits. The current specs only provide bit 2 in hideleg, which can't be used to control delegation for two types of interrupt.

A better solution might be to introduce a new interrupt type called SGTI and the corresponding pending bits and delegation bits. M-mode delegate SGTI to HS-mode. HS-mode still delegates VSTI to VS-mode. When an interrupt is triggered by vstimecmp, the hart sets SGTI to be pending and generates a trap. The hypervisor then sets VSTI to be pending, and executes the vCPU.

Hope this explains.

Regards,
Siqi


Re: Disabling and re-enabling extensions

Andrew Waterman
 



On Wed, Sep 9, 2020 at 12:14 PM Paul Donahue <pdonahue@...> wrote:

In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser.  One thing that has changed is that now the architecture has an explicit goal of either describing behavior or using the term UNSPECIFIED.


To restate the question: Various extensions that add architectural state can be enabled/disabled via misa.  What happens to that architectural state if the extension is disabled and later re-enabled?


In particular, what happens to the following state if the associated misa bit is cleared and then set:

  • misa.F: FP registers and fcsr

  • misa.D: upper part of FP registers (when misa.D=0 and misa.F=1)

  • misa.Q: upper part of FP registers (when misa.Q=0 and misa.F=1)

  • misa.S: supervisor CSR state

  • misa.H: hypervisor CSR state

  • misa.V: vector state


The spec is clear about the treatment of mepc[1] and sepc[1] when misa.C is disabled and subsequently re-enabled.  That bit will contain the last written value even if the write comes while C is disabled.


In a different approach, the spec is also clear that if mstatus.FS is set to Off that the FP state is preserved.  However, this S-mode operation is different from the M-mode misa.F control.  And the question remains about disabling portions of the FP registers where implementations may continue to do single-precision operations that write (at least) the lower part of the register.


Implementations that support H are encouraged to make misa.H writable.  While support for disabling D without disabling F is potentially academic, most implementations are expected to allow software to disable and re-enable H.


I propose that there should be a sentence in the misa description that says that, unless otherwise specified, when software enables an extension that was previously disabled then all state uniquely associated with that extension is UNSPECIFIED.


I don’t object, but I’m wondering: would different implementations actually be motivated to have different behavior w.r.t. hypervisor state when H is disabled then re-enabled? Put another way, do we have any reason to believe that making the behavior fully specified would unduly burden certain styles of implementation?



Thanks,


-Paul











Re: Disabling and re-enabling extensions

Allen Baum
 

(Compliance hat on):
  I'd like to dig into that a bit further. This has come up in the context of WARL registers, where changing the value of some CSR field1 causes some other CSR field2 value to become illegal, and therefore reading/applying that CSR field2 will then reflect a different, now legal value. 
The question becomes: if CSR field1 is restored to its previous value (or some other value where the original CSR field2 was legal): does CSR field2 revert to that original value, or does it keep the newer (presumably legal) value?

Another way to look at this is: is it required that the illegal->legal mapping occur only when reading/using the CSR (by HW or SW), or that the result of an mapping force the field to be written (either explicitly on a write, or when changed while writing some other field)?

(Compliance hat going back into its closet)

On Wed, Sep 9, 2020 at 12:14 PM Paul Donahue <pdonahue@...> wrote:

In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser.  One thing that has changed is that now the architecture has an explicit goal of either describing behavior or using the term UNSPECIFIED.


To restate the question: Various extensions that add architectural state can be enabled/disabled via misa.  What happens to that architectural state if the extension is disabled and later re-enabled?


In particular, what happens to the following state if the associated misa bit is cleared and then set:

  • misa.F: FP registers and fcsr

  • misa.D: upper part of FP registers (when misa.D=0 and misa.F=1)

  • misa.Q: upper part of FP registers (when misa.Q=0 and misa.F=1)

  • misa.S: supervisor CSR state

  • misa.H: hypervisor CSR state

  • misa.V: vector state


The spec is clear about the treatment of mepc[1] and sepc[1] when misa.C is disabled and subsequently re-enabled.  That bit will contain the last written value even if the write comes while C is disabled.


In a different approach, the spec is also clear that if mstatus.FS is set to Off that the FP state is preserved.  However, this S-mode operation is different from the M-mode misa.F control.  And the question remains about disabling portions of the FP registers where implementations may continue to do single-precision operations that write (at least) the lower part of the register.


Implementations that support H are encouraged to make misa.H writable.  While support for disabling D without disabling F is potentially academic, most implementations are expected to allow software to disable and re-enable H.


I propose that there should be a sentence in the misa description that says that, unless otherwise specified, when software enables an extension that was previously disabled then all state uniquely associated with that extension is UNSPECIFIED.



Thanks,


-Paul



Disabling and re-enabling extensions

Paul Donahue
 

In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser.  One thing that has changed is that now the architecture has an explicit goal of either describing behavior or using the term UNSPECIFIED.


To restate the question: Various extensions that add architectural state can be enabled/disabled via misa.  What happens to that architectural state if the extension is disabled and later re-enabled?


In particular, what happens to the following state if the associated misa bit is cleared and then set:

  • misa.F: FP registers and fcsr

  • misa.D: upper part of FP registers (when misa.D=0 and misa.F=1)

  • misa.Q: upper part of FP registers (when misa.Q=0 and misa.F=1)

  • misa.S: supervisor CSR state

  • misa.H: hypervisor CSR state

  • misa.V: vector state


The spec is clear about the treatment of mepc[1] and sepc[1] when misa.C is disabled and subsequently re-enabled.  That bit will contain the last written value even if the write comes while C is disabled.


In a different approach, the spec is also clear that if mstatus.FS is set to Off that the FP state is preserved.  However, this S-mode operation is different from the M-mode misa.F control.  And the question remains about disabling portions of the FP registers where implementations may continue to do single-precision operations that write (at least) the lower part of the register.


Implementations that support H are encouraged to make misa.H writable.  While support for disabling D without disabling F is potentially academic, most implementations are expected to allow software to disable and re-enable H.


I propose that there should be a sentence in the misa description that says that, unless otherwise specified, when software enables an extension that was previously disabled then all state uniquely associated with that extension is UNSPECIFIED.



Thanks,


-Paul



Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Phil McCoy
 

Fair enough.  I was thinking of a system where the DVFS would be under the control of M-mode software, but in some chips it could be done by a more autonomous DVFS controller of some sort.

Sounds like memory-mapped stimecmp/vstimecmp registers might be the best solution.  I don't think anything in the existing spec would prevent this, but it would be nice to have it standardized (at least to the extent that mtime/mtimecmp are standardized...)

Cheers,
Phil


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Allen Baum
 

Scale factors don't work if the clock is constantly changing e.g. DVFS

On Wed, Sep 9, 2020 at 10:36 AM <pnm@...> wrote:
Another option is to create memory-mapped registers for stimecmp/vstimecmp at addresses that are accessible to S-mode/VS-mode software.


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Phil McCoy
 

Another option is to create memory-mapped registers for stimecmp/vstimecmp at addresses that are accessible to S-mode/VS-mode software.


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Phil McCoy
 

One of the main reasons for making mtime/mtimecmp memory-mapped rather than CSRs is to support systems where the CPU(s) do not run at a constant clock frequency.  In such systems, the mtime counter must reside in a different clock domain (and often voltage domain) from the CPU.  If the *timecmp registers are implemented as CSRs, the 64-bit compare value must be passed from the CPU clock domain to the mtime clock domain, which is a costly overhead for the CPU design.  (The alternative of passing the mtime value into the CPU clock domain is much worse for power, since it changes much more frequently than the compare value.)

Another alternative is for the CPU to translate the CSR write instruction into a memory write.  This is impractical for a CPU IP, because the CPU designers do not know the SoC memory map (which might vary between implementations/customers, or even be programmable at runtime).  There is also the overhead of handling interactions with PMP/PMA, etc.

How feasible is it to generate timer-interrupts for VS-mode software from a counter in the CPU clock domain?  The hypervisor could apply an appropriate scaling factor to align with wall-clock time, perhaps using an htimescale register somewhat analogous to htimedelta.


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

John Hauser
 

zhaosiqi (Siqi) wrote:
BTW, we have learned recently that there is an on-going work on an
improved version of the PLIC which is virtualization-aware, is there
any documents available?
There is an informal group that is working on a proposal for a RISC-V
"Advanced Interrupt Architecture", which includes replacements for
the current PLIC. No document is available yet because the group's
proposal isn't complete yet; the document is still being written. As
soon as the authors are satisfied with it, the proposal will be shared
with everyone so it can begin receiving wider evaluation and feedback.
I expect that will happen around the end of 2020 or early in 2021.

(Yes, I know, everybody wants it to be sooner. It's already being done
as fast as time allows.)

Regards,

- John Hauser


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Greg Favor
 

A few other small nits:

- Besides by S-mode and M-mode, the stimecmp CSR is accessible by HS-mode; and is accessible by VS-mode as well (during which the vstimecmp CSR contents substitute for stimecmp contents).

- The vstimecmp CSR is indirectly read/write accessible during VS-mode (as well as directly during M-mode and HS-mode).

- The *stimecmp CSR's are shown as having bits [11:0] and they are shown as TBD.  They instead should have the same format as mtimecmp, i.e. a full 64-bit unsigned value.

- Section 2.2 mistakenly says that "instructions that access stimecmp when V==0 access vstimecmp instead".  That should be for when V==1.

- From M/S/HS/VS modes, access to stimecmp does not trap.  But it does trap from U/VU modes.

- From M/S/HS modes, access to vstimecmp does not trap.  But it does trap from VS/U/VU modes.

- Lastly, what section 4 asks for, I believe is already provided via hideleg bit 6.

Greg




On Wed, Sep 2, 2020 at 8:24 PM zhaosiqi (A) via lists.riscv.org <zhaosiqi3=huawei.com@...> wrote:

Hi Everyone,

 

This is an updated version of our previous proposal on the clock source and clock event source. We have aligned our ideas with the latest hypervisor extension specs, removed the redundant parts, and uncovered some issues if we are going to implement this proposal with the current design. We give an analysis together with the proposed new CSRs in the attached document.

 

BTW, we have learned recently that there is an on-going work on an improved version of the PLIC which is virtualization-aware, is there any documents available?

 

Regards,

Siqi


Re: Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Greg Favor
 

I haven't gone through all of sections 3.1 and 3.2 yet, but it seems like 3.1 starts off on the wrong foot.  It states that "the current RISC-V spec states that vsie.STIE is an alias of hie.VSTIE".  I believe this (and the subsequent observations) are flawed for a combination of reasons.

First, the Priv spec says "When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE."   Not quite the same as vsie.STIE and hie.VSTIE always being aliases of each other.  This will matter down below.

Second, note that the Priv spec says, regarding vsie.STIE, that:
"The vsip and vsie registers are VSXLEN-bit read/write registers that are VS-mode’s versions of supervisor CSRs sip and sie, formatted as shown in Figures 5.22 and 5.23 respectively. When V=1, vsip and vsie substitute for the usual sip and sie, so instructions that normally read or modify sip/sie actually access vsip/vsie instead."
In other words, vsie.STIE substitutes for sie.STIE when (and only when) V=1.
And sie.STIE is not an alias or anything else of hie.VSTIE.  The spec says that "the nonzero bits in sie and hie are always mutually exclusive".

Thirdly, note that hie.VSTIE is the enable for hip.VSTIP and hip.VSTIP "is the logical-OR of hvip.VSTIP and any other platform-specific timer interrupt signal directed to VS-level".  A vstimecmp interrupt would fall in that latter category.

Fourthly, when hideleg bit 6 is zero, then hip.VSTIP=1 is directed to be serviced by HS-mode.  But when hideleg bit 6 is one, then hip.VSTIP=1 is directed to be serviced by VS-mode - and then (and only then) is vsip.STIP an alias of hip.VSTIP (and vsie.STIE an alias of hie.VSTIE).

So, in this latter case, since a vstimecmp interrupt factors into hip.VSTIP, it then also factors into vsip.STIP.  And when the vstimecmp interrupt is recognized, it is taken in VS-mode and not in HS-mode (i.e. not into the hypervisor) due to hideleg.

Conversely, if hideleg directs the interrupt to the hypervisor, then vsie/vsip.STIP are not aliases of hie/hip.VSTIP.  And hence clearing of hie.VSTIE does not not affect vsie.STIE (vsie.STIE, in fact, is read-only zeros).

So it seems like the stated problem case in section 3.1 cannot arise.

Greg


On Wed, Sep 2, 2020 at 8:24 PM zhaosiqi (A) via lists.riscv.org <zhaosiqi3=huawei.com@...> wrote:

Hi Everyone,

 

This is an updated version of our previous proposal on the clock source and clock event source. We have aligned our ideas with the latest hypervisor extension specs, removed the redundant parts, and uncovered some issues if we are going to implement this proposal with the current design. We give an analysis together with the proposed new CSRs in the attached document.

 

BTW, we have learned recently that there is an on-going work on an improved version of the PLIC which is virtualization-aware, is there any documents available?

 

Regards,

Siqi


Proposal: Supervisor Timer CSR and Virtual Supervisor Timer CSR

Siqi Zhao
 

Hi Everyone,

 

This is an updated version of our previous proposal on the clock source and clock event source. We have aligned our ideas with the latest hypervisor extension specs, removed the redundant parts, and uncovered some issues if we are going to implement this proposal with the current design. We give an analysis together with the proposed new CSRs in the attached document.

 

BTW, we have learned recently that there is an on-going work on an improved version of the PLIC which is virtualization-aware, is there any documents available?

 

Regards,

Siqi


Re: CSR address for debug scontext and hcontext

Allen Baum
 

Works for me

On Tue, Aug 25, 2020 at 12:52 PM Andrew Waterman <andrew@...> wrote:
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. 

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




Re: CSR address for debug scontext and hcontext

Greg Favor
 

No objections from me.

Greg


On Tue, Aug 25, 2020 at 12:52 PM Andrew Waterman <andrew@...> wrote:
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. 

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




Re: CSR address for debug scontext and hcontext

Andrew Waterman
 

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. 

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




Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

Allen Baum
 

To be fair, I said the same thing a month or so ago and had the same thing pointed out to me!

-Allen

On Aug 21, 2020, at 10:25 AM, Bill Huffman <huffman@...> wrote:

You're right, Allen.  I didn't think that one was true.  Delegation bits are presumably part of the core dispatch area and not kept somewhere else.  It would be different to have exceptions depend on operational performance counter registers, though.

      Bill

On 8/20/20 9:26 PM, Allen Baum wrote:
EXTERNAL MAIL

Prvi spec v1.12  sec 3.1.12:

When the CY, TM, IR, or HPMn bit in the mcounteren register is clear, attempts to read the cycle, time, instret, or hpmcountern register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode). 


On Thu, Aug 20, 2020 at 3:29 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
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


Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

Bill Huffman
 

You're right, Allen.  I didn't think that one was true.  Delegation bits are presumably part of the core dispatch area and not kept somewhere else.  It would be different to have exceptions depend on operational performance counter registers, though.

      Bill

On 8/20/20 9:26 PM, Allen Baum wrote:
EXTERNAL MAIL

Prvi spec v1.12  sec 3.1.12:

When the CY, TM, IR, or HPMn bit in the mcounteren register is clear, attempts to read the cycle, time, instret, or hpmcountern register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode). 


On Thu, Aug 20, 2020 at 3:29 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
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

801 - 820 of 1130