|
Status of v1.12 privileged specification
There will be an annual release of all the specs, which can be reference as Andrew says. But, use the extension name as a key. If the extension doesn't have a name, we'll give it a name. Krste | On Tu
There will be an annual release of all the specs, which can be reference as Andrew says. But, use the extension name as a key. If the extension doesn't have a name, we'll give it a name. Krste | On Tu
|
By
Krste Asanovic
· #1072
·
|
|
[EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
The current PMP checks isolate M mode from lower-privilege modes. In terms of software compatibility and profiles, for U/S/HS modes - which are not aware of PMPs - the discussion can be pushed to plat
The current PMP checks isolate M mode from lower-privilege modes. In terms of software compatibility and profiles, for U/S/HS modes - which are not aware of PMPs - the discussion can be pushed to plat
|
By
Krste Asanovic
· #996
·
|
|
[RFC] Toolchain interface for privilege spec related stuff.
For the case of the Alibaba vector extension based on pre-frozen 0.7.1 draft, we had already agreed to use the -X custom extension name for this, so there is no confusion about this being a RISC-V sta
For the case of the Alibaba vector extension based on pre-frozen 0.7.1 draft, we had already agreed to use the -X custom extension name for this, so there is no confusion about this being a RISC-V sta
|
By
Krste Asanovic
· #874
·
|
|
[RFC] Toolchain interface for privilege spec related stuff.
The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use. There is a related issue of how the support is managed upstream. Ther
The syntax is fine, but the version number was meant for pre-ratified extensions during development, not for final production use. There is a related issue of how the support is managed upstream. Ther
|
By
Krste Asanovic
· #867
·
|
|
[RFC] Toolchain interface for privilege spec related stuff.
Yes, that was the plan, Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote: | For non-priverage extension, toolchain can control version for each | extension by ISA strin
Yes, that was the plan, Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote: | For non-priverage extension, toolchain can control version for each | extension by ISA strin
|
By
Krste Asanovic
· #837
·
|
|
RISC-V H-extension freeze consideration
Resending from correct email address Begin forwarded message: From: krste@... Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration Date: August 1, 2021 at 1:41:10 P
Resending from correct email address Begin forwarded message: From: krste@... Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration Date: August 1, 2021 at 1:41:10 P
|
By
Krste Asanovic
· #786
·
|
|
[RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Jessica and Greg are right - I was wrong about the existing use of "p". Actually, elsewhere in CSR names, we haven't really used "Hungarian Notation" at all: https://en.wikipedia.org/wiki/Hungarian_no
Jessica and Greg are right - I was wrong about the existing use of "p". Actually, elsewhere in CSR names, we haven't really used "Hungarian Notation" at all: https://en.wikipedia.org/wiki/Hungarian_no
|
By
Krste Asanovic
· #776
·
|
|
[RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
| I didn't understand the point of #3) Alignment | If I understand the proposed format (*not* a given), fields are either always a byte long, or are byte - not word - aligned. Fields aren't padded, as
| I didn't understand the point of #3) Alignment | If I understand the proposed format (*not* a given), fields are either always a byte long, or are byte - not word - aligned. Fields aren't padded, as
|
By
Krste Asanovic
· #773
·
|
|
[RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Some input: 1) Read-only or writeable. For super-minimalist spec, it's fine to only define a CSR number and say it holds the config address and every thing else is TBD. This at least allows folks to g
Some input: 1) Read-only or writeable. For super-minimalist spec, it's fine to only define a CSR number and say it holds the config address and every thing else is TBD. This at least allows folks to g
|
By
Krste Asanovic
· #765
·
|
|
RISC-V H-extension freeze consideration
| On Mon, May 31, 2021 at 11:17 AM John Hauser <jh.riscv@...> wrote: | There is nothing novel about the situation I'm describing. I'm certain | that hypervisors have emulated such devices in ju
| On Mon, May 31, 2021 at 11:17 AM John Hauser <jh.riscv@...> wrote: | There is nothing novel about the situation I'm describing. I'm certain | that hypervisors have emulated such devices in ju
|
By
Krste Asanovic
· #691
·
|
|
[RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal
RNMI has separate exception vector from regular exceptions. Krste | Oops - I reread that - Paul is correct; nmcause is not modified. The handler has no guaranteed way of handling an exception. | IT ca
RNMI has separate exception vector from regular exceptions. Krste | Oops - I reread that - Paul is correct; nmcause is not modified. The handler has no guaranteed way of handling an exception. | IT ca
|
By
Krste Asanovic
· #433
·
|
|
Resumable NMI proposal
| 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 stat
| 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 stat
|
By
Krste Asanovic
· #432
·
|
|
Resumable NMI proposal
M-mode or HS-mode can always create equivalent for S-mode. I don't believe hardware delegation makes sense for NMIs. Krste | I'd expect that S-mode software will also want to be able to receive RNMIs,
M-mode or HS-mode can always create equivalent for S-mode. I don't believe hardware delegation makes sense for NMIs. Krste | I'd expect that S-mode software will also want to be able to receive RNMIs,
|
By
Krste Asanovic
· #431
·
|
|
Resumable NMI proposal
| I'll jump in with a few more. :) | From an architectural point of view, I don't like the fact that an NMI blocks further NMI until it leaves its handler. There may be NMIs that can save | the state
| I'll jump in with a few more. :) | From an architectural point of view, I don't like the fact that an NMI blocks further NMI until it leaves its handler. There may be NMIs that can save | the state
|
By
Krste Asanovic
· #430
·
|
|
Resumable NMI proposal
| Even though this is hot off the press, I'll jump in with a few small comments: | - In mnstatus, shouldn't there also be a bit like the mstatus.MPV bit (for when the H extension is implemented and en
| Even though this is hot off the press, I'll jump in with a few small comments: | - In mnstatus, shouldn't there also be a bit like the mstatus.MPV bit (for when the H extension is implemented and en
|
By
Krste Asanovic
· #429
·
|
|
Resumable NMI proposal
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
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
|
By
Krste Asanovic
· #421
·
|
|
rv(64) address space size
The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits, Krste
The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits, Krste
|
By
Krste Asanovic
· #393
·
|
|
P extension fixed-point saturation flag CSR
Yes, should share the flag. Code that has an outer check for saturation to check if re-scaling needed, won’t want to care whether it was caused by scalar or vector routine. Krste
Yes, should share the flag. Code that has an outer check for saturation to check if re-scaling needed, won’t want to care whether it was caused by scalar or vector routine. Krste
|
By
Krste Asanovic
· #271
·
|
|
mcycle behavior during stalled wfi
mcycle is considered part of the HPM facility. If the clock to the core is not running, mcycle does not need to increment. If part of the core is being clocked (including just mcycle), then mcycle can
mcycle is considered part of the HPM facility. If the clock to the core is not running, mcycle does not need to increment. If part of the core is being clocked (including just mcycle), then mcycle can
|
By
Krste Asanovic
· #199
·
|