Date   

Re: Resumable NMI proposal

Beeman Strong
 

Oops, I guess the web interface doesn't include the text from the message I was responding to.  Here it is, from Krste:


On Tue, 19 Jan 2021 10:04:28 -0800, Earl Killian <earl.killian@...> said:
| I would like a clarification on whether this replaces the existing NMI, or are you saying there are two different things, NMI and RNMI? I doubt it, but I wanted to check.

Enhances NMI by adding state to make resumable.

| I am concerned that the rnmie is hidden and only settable by MNRET. This means that to re-enable NMI for a portion of a NMI handler (e.g. after saving all the appropriate information to a NMI stack) one must write mnepc and then MNRET there, but there is no way to disable it for the real MNRET.

Should have been visible but only settable by M-mode software.

Krste


|| On Jan 18, 2021, at 18:39, Krste Asanovic <krste@...> wrote:
||
||
|| Current RISC-V specs only have a non-resumable NMI definition. The
|| following proposal would add resumable NMI support. This was one of
|| the features requested for priv 1.12 or RVA/RVM22.
||
|| This is up for discussion, but I think it is small enough to go
|| through fast track process.
||
|| Krste
||
|| :sectnums:
|| :toc: left
||
|| = Resumable NMI support in RISC-V
|| Version 0.2.1-Draft
||
|| == Background and Motivation
||
|| The RISC-V privileged architecture version 1.11 supports only
|| unresumable non-maskable interrupts (UNMIs), where the NMI jumps to a
|| handler in machine mode, overwriting the current `mepc` and `mcause`
|| register values. If the hart had been executing machine-mode code in
|| a trap handler, the previous values in `mepc` and `mcause` would not
|| be recoverable and so execution is not generally resumable.
||
|| This proposal adds support for resumable non-maskable interrupts
|| (RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`,
|| `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
|| and a new instruction to resume from the RNMI handler.
||
|| == RNMI Interrupt Signals
||
|| The `rnmi` interrupt signals are inputs to
|| the hart. These interrupts have higher priority than any other
|| interrupt or exception on the hart and cannot be disabled by software.
|| Specifically, they are not disabled by clearing the `mstatus.mie`
|| register.
||
|| == RNMI Handler Addresses
||
|| The RNMI interrupt trap handler address is implementation-defined.
||
|| RNMI also has an associated exception trap handler address, which is
|| implementation defined.
||
|| == New RNMI CSRs
||
|| This proposal adds additional M-mode CSRs to enable a resumable
|| non-maskable interrupt (RNMI).
||
|| .NMI additional CSRs
|| [cols="2,2,2,2"]
|| [%autowidth]
|| |===
|| | Number | Privilege | Name | Description
||
|| | 0x350 | MRW | `mnscratch` | Resumable Non-maskable scratch register
|| | 0x351 | MRW | `mnepc` | Resumable Non-maskable EPC value
|| | 0x352 | MRW | `mncause` | Resumable Non-maskable cause value
|| | 0x353 | MRW | `mnstatus` | Resumable Non-maskable status
|| |===
||
|| The `mnscratch` CSR holds an XLEN-bit read-write register which
|| enables the NMI trap handler to save and restore the context that was
|| interrupted.
||
|| The `mnepc` CSR is an XLEN-bit read-write register which on entry
|| to the NMI trap handler holds the PC of the instruction that took the
|| interrupt. The lowest bit of `mnepc` is hardwired to zero.
||
|| The `mncause` CSR holds the reason for the NMI, with bit XLEN-1 set to
|| 1, and the NMI cause encoded in the least-significant bits or zero if
|| NMI causes are not supported.
||
|| The `mnstatus` CSR holds a two-bit field which on entry to the trap
|| handler holds the privilege mode of the interrupted context encoded in
|| bits `mnstatus[12:11]` in the same manner as `mstatus.mpp`. The other
|| bits in `mnstatus` are _reserved_, but software should write zeros and
|| hardware implementations should return zeros.
||
|| == New MNRET instruction
||
|| This new M-mode only instruction uses the values in `mnepc` and
|| `mnstatus` to return to the program counter and privileged mode of the
|| interrupted context respectively. This instruction also sets the
|| `rnmie` state bit.
||
|| MNRET instruction encoding is same as MRET except with bit 30 set
|| (i.e.,`funct7`=`0111000`).
||
|| == RNMI Operation
||
|| When an RNMI interrupt is detected, the interrupted PC is written to
|| the `mnepc` CSR, the type of RNMI to the `mncause` CSR, and the
|| privilege mode of the interrupted context to the `mnstatus` CSR. An
|| internal microarchitectural state bit `rnmie` is cleared to indicate
|| that processor is in an RNMI handler and cannot take a new RNMI
|| interrupt. The internal `rnmie` bit when clear also disables all
|| other interrupts.
||
|| NOTE: These interrupts are called non-maskable because software cannot
|| mask the interrupts, but for correct operation other instances of the
|| same interrupt must be held off until the handler is completed, hence
|| the internal state bit.
||
|| The core then enters machine-mode and jumps to the RNMI trap handler
|| address.
||
|| The RNMI handler can resume original execution using the new MNRET
|| instruction, which restores the PC from `mnepc`, the privilege mode
|| from `mnstatus`, and also sets the internal `rnmie` state bit, which
|| reenables other interrupts.
||
|| If the hart encounters an exception while the `rnmie` bit is clear, the
|| exception state is written to `mepc` and `mcause`, `mstatus.mpp` is
|| set to M-mode, and the hart jumps to the RNMI exception handler
|| address.
||
|| NOTE: Traps in the RNMI handler can only be resumed if they occur while
|| the handler was servicing an interrupt that occured outside of
|| machine-mode.
||
|| == Interaction with debugger
||
|| The debugger can be configured such that an RNMI event drops the
|| system into the debugger.
||
||
||
||
||

On Wed, Jun 1, 2022 at 6:15 PM Beeman Strong via lists.riscv.org <beeman=rivosinc.com@...> wrote:
Reviving this old thread.  What is the status of this proposal?  I'd like to explore using RNMIs for performance counter overflow interrupts, in order to support profiling while interrupts are masked.


Re: Resumable NMI proposal

Beeman Strong
 

Reviving this old thread.  What is the status of this proposal?  I'd like to explore using RNMIs for performance counter overflow interrupts, in order to support profiling while interrupts are masked.


Re: Smstateen for Zcmt

Tariq Kurd
 

ok, thanks John, I've done the rewording.

Tariq

On Mon, 23 May 2022 at 02:46, John Hauser <jh.riscv@...> wrote:
Tariq Kurd wrote:
> Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.

> Can I allocate bit 2 as follows?

Yes, let's assume bit 2 is allocated for this purpose, in mstateen0,
hstateen0, and sstateen0.

> *Bit 2 applies only for the case that Zcmt is implemented, which includes
> the JVT CSR and the cm.jt, cm.jalt encodings.*
> *For convenience if bit 2 of a controlling stateen0 CSR is zero, then all
> cm.jt, cm.jalt instructions cause an illegal instruction trap *
> *(or virtual instruction trap, if relevant). *
>
> How does that sound?

We'll probably change the wording later, but for now, replace the
word _encodings_ by _instructions_, and drop "For convenience".
Instructions CM.JT and CM.JALT must trap because they implicitly depend
on the value of jvt.

> ..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.

Right.  The intention is that stateen bits should be for controlling
access to new state.  No state, no stateen bit.

    - John Hauser


--

Tariq Kurd | Chief CPU Architect | Codasip UK Design Centre | www.codasip.com


Re: Smstateen for Zcmt

John Hauser
 

Tariq Kurd wrote:
Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.
Can I allocate bit 2 as follows?
Yes, let's assume bit 2 is allocated for this purpose, in mstateen0,
hstateen0, and sstateen0.

*Bit 2 applies only for the case that Zcmt is implemented, which includes
the JVT CSR and the cm.jt, cm.jalt encodings.*
*For convenience if bit 2 of a controlling stateen0 CSR is zero, then all
cm.jt, cm.jalt instructions cause an illegal instruction trap *
*(or virtual instruction trap, if relevant). *

How does that sound?
We'll probably change the wording later, but for now, replace the
word _encodings_ by _instructions_, and drop "For convenience".
Instructions CM.JT and CM.JALT must trap because they implicitly depend
on the value of jvt.

..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.
Right. The intention is that stateen bits should be for controlling
access to new state. No state, no stateen bit.

- John Hauser


Re: Smstateen for Zcmt

John Hauser
 

Mark wrote:
Please explain to me why we would not want implementers to implement Zc*
and not C. I am not sure I understand the use cases and workloads well. Am
I misunderstanding?
We expect people to implement the new Zcm* extensions together with Zca
and Zcb. Zca is the subset of C that drops the compressed instructions
for double-precision floating-point loads and stores. The expectation
is that most embedded systems will find the new compressed instructions
more useful than the existing ones for double-precision floating-point,
especially as smaller embedded systems typically don't do double-
precision floating-point at all. But even for those that do, they can
still have the standard non-compressed D instructions together with Zca
+ Zcb + all of Zcm*.

I understand that implementers want to pick and choose in embedded
environments but I'd think we'd want the ability to have them all
available together.
The total number of 16-bit encodings is too small to contain everything
we might want to put in that space. Choices must be made.

- John Hauser


Re: Smstateen for Zcmt

mark
 

Please explain to me why we would not want implementers to implement Zc* and not C. I am not sure I understand the use cases and workloads well. Am I misunderstanding?

I understand that implementers want to pick and choose in embedded environments but I'd think we'd want the ability to have them all available together.

Mark

On Tue, May 17, 2022 at 12:42 AM Tariq Kurd <tariq.kurd@...> wrote:
OK, thanks everyone, interesting debate.
 BTW it's not only Zcmt which has conflicting opcodes with C (encoding C.FSD, C.FSDSP, C.FLD, C.FLDSP), it's also the case for all Zcm* (Zcmb Zcmp Zcmpe Zcmt).
So if we want to disable opcode conflicts, then we'll need to do so for all of those.
Note for Jeff: this is our method of dramatically improving the code-size - we need to reuse some of the 16-bit encoding space to be competitive with other embedded architectures.

Personally I agree with the concept of building a C compatible core or Zcm* compatible core as a design choice, and if someone _really_ wants a switch then they can implement a custom bit to control it, but this seems like an unlikely use case.

Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.

Referring to this existing text for Zfinx stateen:

>Bit 1 applies only for the case when floating-point instructions operate on x registers instead of f registers.
>Whenever misa.F = 1, bit 1 of mstateen0 is read-only zero (and hence read-only zero in hstateen0 and sstateen0
>too). For convenience, when the stateen CSRs are implemented and misa.F = 0, then if bit 1 of a controlling
>stateen0 CSR is zero, all floating-point instructions cause an illegal instruction trap (or virtual instruction trap, if
>relevant), as though they all access fcsr, regardless of whether they really do.

Can I allocate bit 2 as follows?

Bit 2 applies only for the case that Zcmt is implemented, which includes the JVT CSR and the cm.jt, cm.jalt encodings.
For convenience if bit 2 of a controlling stateen0 CSR is zero, then all cm.jt, cm.jalt instructions cause an illegal instruction trap 
(or virtual instruction trap, if relevant). 

How does that sound?

..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.

Tariq

On Tue, 17 May 2022 at 03:09, John Hauser <jh.riscv@...> wrote:
I wrote:
> Zca + Zcb is a subset of C.

Correction:  Zca is a subset of C; Zcb is not.

    - John Hauser


--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com


Re: Smstateen for Zcmt

Tariq Kurd
 

OK, thanks everyone, interesting debate.
 BTW it's not only Zcmt which has conflicting opcodes with C (encoding C.FSD, C.FSDSP, C.FLD, C.FLDSP), it's also the case for all Zcm* (Zcmb Zcmp Zcmpe Zcmt).
So if we want to disable opcode conflicts, then we'll need to do so for all of those.
Note for Jeff: this is our method of dramatically improving the code-size - we need to reuse some of the 16-bit encoding space to be competitive with other embedded architectures.

Personally I agree with the concept of building a C compatible core or Zcm* compatible core as a design choice, and if someone _really_ wants a switch then they can implement a custom bit to control it, but this seems like an unlikely use case.

Therefore, I'd like to allocate one Smstateen bit to JVT - the CSR only.

Referring to this existing text for Zfinx stateen:

>Bit 1 applies only for the case when floating-point instructions operate on x registers instead of f registers.
>Whenever misa.F = 1, bit 1 of mstateen0 is read-only zero (and hence read-only zero in hstateen0 and sstateen0
>too). For convenience, when the stateen CSRs are implemented and misa.F = 0, then if bit 1 of a controlling
>stateen0 CSR is zero, all floating-point instructions cause an illegal instruction trap (or virtual instruction trap, if
>relevant), as though they all access fcsr, regardless of whether they really do.

Can I allocate bit 2 as follows?

Bit 2 applies only for the case that Zcmt is implemented, which includes the JVT CSR and the cm.jt, cm.jalt encodings.
For convenience if bit 2 of a controlling stateen0 CSR is zero, then all cm.jt, cm.jalt instructions cause an illegal instruction trap 
(or virtual instruction trap, if relevant). 

How does that sound?

..and I'm not proposing a stateen for Zcmb, Zcmp, Zcmpe.

Tariq

On Tue, 17 May 2022 at 03:09, John Hauser <jh.riscv@...> wrote:
I wrote:
> Zca + Zcb is a subset of C.

Correction:  Zca is a subset of C; Zcb is not.

    - John Hauser


--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com


Re: Smstateen for Zcmt

John Hauser
 

I wrote:
Zca + Zcb is a subset of C.
Correction: Zca is a subset of C; Zcb is not.

- John Hauser


Re: Smstateen for Zcmt

John Hauser
 

Greg Favor wrote:
Off-hand (maybe naively) I would imagine that implementations will either
implement the D extension or the Zcmt extension - as a fixed choice.
RVA-compliant implementations must implement D, so this is a non-issue for
such designs. It is only non-RVA embedded designs that either care about
code size reduction enough to want Zcmt and don't care about having DP FP,
or vice-versa.
Actually, there's no conflict between Zcmt and the D extension.
The conflict is between Zcmt and the C extension, because it's the
C extension that defines the compressed instruction encodings reused by
Zcmt. To summarize:

Zcmt + D is possible
Zcmt + C isn't possible
Zcmt + Zca + Zcb + D is possible

Zca + Zcb is a subset of C.

We'd like to stamp out the notion that the Zcm* extensions are
incompatible with D.

However, because the RVA profiles also require C, most of what Greg
wrote still applies, if you just substitute "C" instead of "D".

Jeff Scott:
Why are Zcmt opcodes using FP opcodes?
The Zcm* extensions repurpose only the 16-bit (compressed) encodings
for D instructions, not the 32-bit encodings.

Is this a final decision by the committee?
It's not final, but a lot has already gone into choosing this tradeoff;
I doubt we can be persuaded to change it.

- John Hauser


Re: Smstateen for Zcmt

Allen Baum
 

OK, I interpret that as "define no spec before its time".  I suspect we can live with that.

On Mon, May 16, 2022 at 4:37 PM Greg Favor <gfavor@...> wrote:
On Mon, May 16, 2022 at 3:11 PM Allen Baum <allen.baum@...> wrote:
Then, why is a custom enable/disable required ?

Not required.  Just an option for the seemingly (?) rare design that implements both extensions and hence needs a bit to control which is enabled (and the other is disabled) - ASSUMING that there is not sufficient practical justification to provide a standard CSR bit for this purpose.
 
(and possibly a bit more complicated: if misa.D, Smstateen.Zcmt can't both be set, so setting one must clear the other)

Yep.
 
OR is that extra bit of functionality what makes it custom - though that would be the requirement of any extension that conflicts with other extension,
which should probably be made part of the spec so we don't go through this exercise every  time it happens.

I think I want to say yes?  But in any case the point is whether there is enough practical justification for having a standard bit that switches between these two extensions (which is not even a simple extension enable/disable bit, but an ISA switch bit).

To me it seems like the first question is whether introducing a standard ISA switch bit for Zcmt is addressing a real-world need versus just a theoretical need?  And if just the latter, then the rare exception of a design that implements both extensions can instead have a custom "ISA switch" bit.

Greg


Re: Smstateen for Zcmt

Greg Favor
 

On Mon, May 16, 2022 at 3:11 PM Allen Baum <allen.baum@...> wrote:
Then, why is a custom enable/disable required ?

Not required.  Just an option for the seemingly (?) rare design that implements both extensions and hence needs a bit to control which is enabled (and the other is disabled) - ASSUMING that there is not sufficient practical justification to provide a standard CSR bit for this purpose.
 
(and possibly a bit more complicated: if misa.D, Smstateen.Zcmt can't both be set, so setting one must clear the other)

Yep.
 
OR is that extra bit of functionality what makes it custom - though that would be the requirement of any extension that conflicts with other extension,
which should probably be made part of the spec so we don't go through this exercise every  time it happens.

I think I want to say yes?  But in any case the point is whether there is enough practical justification for having a standard bit that switches between these two extensions (which is not even a simple extension enable/disable bit, but an ISA switch bit).

To me it seems like the first question is whether introducing a standard ISA switch bit for Zcmt is addressing a real-world need versus just a theoretical need?  And if just the latter, then the rare exception of a design that implements both extensions can instead have a custom "ISA switch" bit.

Greg


Re: Smstateen for Zcmt

Allen Baum
 

 Greg, you said:
 "The intent is that if Smstateen is needed to provide a backward compatibility mechanism, 
   then the extension AS A WHOLE would be enabled or disabled.
  (This, as I noted earlier, should be a rare case.)"

The spec for Msstateen says:
In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA extensions that introduce the controlled state.

It sounds like this is that rare case: Smstateem enable bit is required because they are incompatible, 
So it must control both the access to the CSRs and all instructions defined by that extension  - even if some particular op doesn't change processor state (beyond Rd)
Then, why is a custom enable/disable required ?
(and possibly a bit more complicated: if misa.D, Smstateen.Zcmt can't both be set, so setting one must clear the other)

OR is that extra bit of functionality what makes it custom - though that would be the requirement of any extension that conflicts with other extension,
which should probably be made part of the spec so we don't go through this exercise every  time it happens.
Though I supposed I'd be happy if it never happens again...

On Mon, May 16, 2022 at 12:32 PM Greg Favor <gfavor@...> wrote:
On Mon, May 16, 2022 at 12:19 PM Allen Baum <allen.baum@...> wrote:
Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp


Then my earlier parenthetical comment is relevant:  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)
 
Off-hand (maybe naively) I would imagine that implementations will either implement the D extension or the Zcmt extension - as a fixed choice.  RVA-compliant implementations must implement D, so this is a non-issue for such designs.  It is only non-RVA embedded designs that either care about code size reduction enough to want Zcmt and don't care about having DP FP, or vice-versa.  If there was ever such a design that wanted to support both, even though only one of the two extensions could be used by software in a given system using that design, then a custom enable/disable bit could be used by that design.

Greg


Re: Smstateen for Zcmt

Jeff Scott
 

Thanks Greg.  Would like to know what drove that decision.

 

Jeff

 

From: Greg Favor <gfavor@...>
Sent: Monday, May 16, 2022 4:49 PM
To: Jeff Scott <jeff.scott@...>
Cc: Allen Baum <allen.baum@...>; Tariq Kurd <tariq.kurd@...>; markhimelstein <markhimelstein@...>; tech-privileged <tech-privileged@...>
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Smstateen for Zcmt

 

Caution: EXT Email

On Mon, May 16, 2022 at 2:42 PM Jeff Scott <jeff.scott@...> wrote:

Why are Zcmt opcodes using FP opcodes?  Is this a final decision by the committee?

 

This is what is proposed by the Code Size Reduction TG.  Tariq can comment on the reasons why.

 

Any "final decision" by the AR committee will only come when it reviews the final spec being proposed.  (But if I remember right, Tariq and the TG have good reasons for resorting to reusing some of the DP FP encoding space.  And I forget what related "working" feedback has come from other AR members to Tariq in the past.)

 

So, for now, this issue is in the TG's hands as part of developing the final spec.

 

Greg

 


Re: Smstateen for Zcmt

Greg Favor
 

On Mon, May 16, 2022 at 2:42 PM Jeff Scott <jeff.scott@...> wrote:

Why are Zcmt opcodes using FP opcodes?  Is this a final decision by the committee?


This is what is proposed by the Code Size Reduction TG.  Tariq can comment on the reasons why.

Any "final decision" by the AR committee will only come when it reviews the final spec being proposed.  (But if I remember right, Tariq and the TG have good reasons for resorting to reusing some of the DP FP encoding space.  And I forget what related "working" feedback has come from other AR members to Tariq in the past.)

So, for now, this issue is in the TG's hands as part of developing the final spec.

Greg


Re: Smstateen for Zcmt

Jeff Scott
 

Why are Zcmt opcodes using FP opcodes?  Is this a final decision by the committee?

 

Jeff

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Greg Favor via lists.riscv.org
Sent: Monday, May 16, 2022 2:32 PM
To: Allen Baum <allen.baum@...>
Cc: Tariq Kurd <tariq.kurd@...>; markhimelstein <markhimelstein@...>; tech-privileged <tech-privileged@...>
Subject: [EXT] Re: [RISC-V] [tech-privileged] Smstateen for Zcmt

 

Caution: EXT Email

On Mon, May 16, 2022 at 12:19 PM Allen Baum <allen.baum@...> wrote:

Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp

 

Then my earlier parenthetical comment is relevant:  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)

 

Off-hand (maybe naively) I would imagine that implementations will either implement the D extension or the Zcmt extension - as a fixed choice.  RVA-compliant implementations must implement D, so this is a non-issue for such designs.  It is only non-RVA embedded designs that either care about code size reduction enough to want Zcmt and don't care about having DP FP, or vice-versa.  If there was ever such a design that wanted to support both, even though only one of the two extensions could be used by software in a given system using that design, then a custom enable/disable bit could be used by that design.

 

Greg


Re: Smstateen for Zcmt

Greg Favor
 

On Mon, May 16, 2022 at 12:19 PM Allen Baum <allen.baum@...> wrote:
Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp


Then my earlier parenthetical comment is relevant:  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)
 
Off-hand (maybe naively) I would imagine that implementations will either implement the D extension or the Zcmt extension - as a fixed choice.  RVA-compliant implementations must implement D, so this is a non-issue for such designs.  It is only non-RVA embedded designs that either care about code size reduction enough to want Zcmt and don't care about having DP FP, or vice-versa.  If there was ever such a design that wanted to support both, even though only one of the two extensions could be used by software in a given system using that design, then a custom enable/disable bit could be used by that design.

Greg


Re: Smstateen for Zcmt

Allen Baum
 

Doesn't Zcmt repurpose FP opcodfes, so is in that second rare case?

Zcm* all reuse encodings for c.fld, c.fsd, c.fldsp, c.fsdsp


On Mon, May 16, 2022 at 10:46 AM Greg Favor <gfavor@...> wrote:
On Mon, May 16, 2022 at 10:02 AM Tariq Kurd <tariq.kurd@...> wrote:
Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
The question which arose was prompted by this text from the Smstateen spec:

"In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA
extensions that introduce the controlled state."

And so the question is whether the instructions are also disabled.

The intent is that if Smstateen is needed to provide a backward compatibility mechanism, then the extension AS A WHOLE would be enabled or disabled.  (This, as I noted earlier, should be a rare case.)

In the common use case for Smstateen and the case of Zcmt, this does not apply and only access to the new JVT CSR would be enabled or disabled,

Greg


Re: Smstateen for Zcmt

Greg Favor
 

On Mon, May 16, 2022 at 10:02 AM Tariq Kurd <tariq.kurd@...> wrote:
Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
The question which arose was prompted by this text from the Smstateen spec:

"In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA
extensions that introduce the controlled state."

And so the question is whether the instructions are also disabled.

The intent is that if Smstateen is needed to provide a backward compatibility mechanism, then the extension AS A WHOLE would be enabled or disabled.  (This, as I noted earlier, should be a rare case.)

In the common use case for Smstateen and the case of Zcmt, this does not apply and only access to the new JVT CSR would be enabled or disabled,

Greg


Re: Smstateen for Zcmt

Tariq Kurd
 

<gmail web has a shortcut to send an email which I accidentally hit>

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
The question which arose was prompted by this text from the Smstateen spec:

"In some cases, the bits of the stateen CSRs will have a dual purpose as enables for the ISA
extensions that introduce the controlled state."

And so the question is whether the instructions are also disabled.

Can we clarify this?

Tariq


On Mon, 16 May 2022 at 17:59, Tariq Kurd <tariq.kurd@...> wrote:
HI Greg,

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
the question which arose was prompted by this text from the Smstateen spec:




On Mon, 16 May 2022 at 17:36, Greg Favor <gfavor@...> wrote:
Tariq,

Thanks for enquiring about new ISA extension coordination with the Smstateen extension that was ratified last year.

The first thing to note is that the primary purpose of and motivation for Smstateen is to close off covert communication channels created by new extensions that add new arch state that needs to be context switched (but may not be context switched by an unaware OS or hypervisor).  (A secondary usage of Smstateen is for rare cases of extensions that are not backward compatible and need to be disablable for backward compatibility.)  This extension is not intended to provide a general mechanism for disabling arch extensions.  Many extensions don't need such and one that does would define its own appropriate mechanism based on the nature of the extension.  (Smepmp, for example, implicitly provides practical backward compatibility by how it defines the semantics of the new CSR bits that it introduces - such that new or modified functionality only becomes active when explicitly enabled by software.)

The second thing to note is that Smstateen, as ratified last year, comprehended the few other extensions that were ratified last year that needed Smstateen support.  Going forward, a new ISA extension that fits the preceding primary and secondary Smstateen use cases should specify any new bit(s) it adds to the *stateenX CSRs.  Then, once it is ratified, this should be moved into the Smstateen chapter that will exist in the Priv spec (when the Smstateen extension itself is merged into the Priv spec - tbd whether before or after Priv conversion to adoc).  The post-ratified ISA extension spec should retain a short mention of and cross reference to the added Smstateen bit(s).

This will put all the new arch functionality introduced by a new ISA extension into one spec document for use during TG reviews, Arch Review, Tech Chairs/TSC/BoD votes, and public review.  Then the added Smstateen detailed functionality can be moved into the Smstateen chapter after ratification.

Regarding Zcmt in particular (which is due to be ratified this year I believe), it seems like adding Smstateen functionality might be necessary only if Zcmt breaks backward compatibility by redefining existing defined opcodes.  I don't remember if that applies here.  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)

Greg


On Mon, May 16, 2022 at 6:58 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.
As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:
Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks
Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).
There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.


Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com


Re: Smstateen for Zcmt

Tariq Kurd
 

HI Greg,

Thanks for the very helpful email - I think this is the first time that a new state enable has been added since Smstateen was ratified.
The reason that it's required is that there's a new CSR: JVT, which must not be used as a covert channel.
My intention was only to disable this CSR, and not to disable any of the new instructions from any of the Zc extensions.
the question which arose was prompted by this text from the Smstateen spec:




On Mon, 16 May 2022 at 17:36, Greg Favor <gfavor@...> wrote:
Tariq,

Thanks for enquiring about new ISA extension coordination with the Smstateen extension that was ratified last year.

The first thing to note is that the primary purpose of and motivation for Smstateen is to close off covert communication channels created by new extensions that add new arch state that needs to be context switched (but may not be context switched by an unaware OS or hypervisor).  (A secondary usage of Smstateen is for rare cases of extensions that are not backward compatible and need to be disablable for backward compatibility.)  This extension is not intended to provide a general mechanism for disabling arch extensions.  Many extensions don't need such and one that does would define its own appropriate mechanism based on the nature of the extension.  (Smepmp, for example, implicitly provides practical backward compatibility by how it defines the semantics of the new CSR bits that it introduces - such that new or modified functionality only becomes active when explicitly enabled by software.)

The second thing to note is that Smstateen, as ratified last year, comprehended the few other extensions that were ratified last year that needed Smstateen support.  Going forward, a new ISA extension that fits the preceding primary and secondary Smstateen use cases should specify any new bit(s) it adds to the *stateenX CSRs.  Then, once it is ratified, this should be moved into the Smstateen chapter that will exist in the Priv spec (when the Smstateen extension itself is merged into the Priv spec - tbd whether before or after Priv conversion to adoc).  The post-ratified ISA extension spec should retain a short mention of and cross reference to the added Smstateen bit(s).

This will put all the new arch functionality introduced by a new ISA extension into one spec document for use during TG reviews, Arch Review, Tech Chairs/TSC/BoD votes, and public review.  Then the added Smstateen detailed functionality can be moved into the Smstateen chapter after ratification.

Regarding Zcmt in particular (which is due to be ratified this year I believe), it seems like adding Smstateen functionality might be necessary only if Zcmt breaks backward compatibility by redefining existing defined opcodes.  I don't remember if that applies here.  (It might be worth considering whether that is truly necessary since such a Zcmt extension would be incompatible with the existing arch extension that it conflicts with, and the question would then be whether some implementations are expected to implement both conflicting extensions - and hence need an extension enable.  Otherwise extension discovery via the new RV "unified low-level discovery" method would inform software as to whether Zcmt is implemented and the conflicting extension is not implemented.)

Greg


On Mon, May 16, 2022 at 6:58 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
In this particular case, the issue is that the Smstateen spec comes later, and hasn't been addressed yet. I believe it's out of scope for Zc, it is simply noted that new state (the JVT CSR) is added so a state enable is required.
As SiLabs are actually implementing Zc right now, they are asking sensible questions about it, so we need to complete this part of the Smstateen spec.

Greg - any input on this would be appreciated.

Tariq

On Mon, 16 May 2022 at 15:47, Mark Himelstein <markhimelstein@...> wrote:
Please talk with Greg and decide.

This is why we have cross group involvement. When a spec is ratified and a TG is disbanded, the Committee has ultimate responsibility.

I have a question though. Is there learning we need to have from this? If the issue wasn't raised how would we have found this? Do we need a list of standard dependencies/interactions?

Thanks
Mark

On Mon, May 16, 2022 at 5:55 AM Tariq Kurd via lists.riscv.org <tariq.kurd=codasip.com@...> wrote:
Hi,

We have a question on github about the implementation of smstateen for Zcmt (table jump).
There's the JVT CSR which needs a state enable. The question is whether there is also a state-enable for the ISA extension.


Who is responsible for the Zcmt Smstateen spec?

Thanks

Tariq

--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com



--

Tariq Kurd | Lead CPU Architect | Codasip UK Design Centre | www.codasip.com

181 - 200 of 1210