| Message ID | 20220303185440.512391-1-atishp@rivosinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Privilege version update | expand |
On Fri, Mar 4, 2022 at 4:59 AM Atish Patra <atishp@rivosinc.com> wrote: > > RISC-V International (RVI) has ratified many RISC-V ISA extensions recently[1]. > The privileged specification version is also upgraded to v1.12. It means > certain CSRs introduced in v1.12 should only be accessible only if the > priv specification version supported is equal or greater than v1.12. > Doing this check in predicate function is not scalable as there will be > new CSRs introduced in the future versions of the privileged specification. > > This series tries to address this problem by adding a field in the csr_ops > which can be checked in csrrw function before invoking the predicate function. > To keep the code churn to minimum, it is assumed that the minimum version of > the privilege version supported for any CSR is v1.10 unless specified > explicitly in the csr_ops table. Any new CSRs introduced in v1.12 have been > updated accordingly. > > This will work fine for any ratified extensions. However, it is bit unclear > what should be done for the stable draft extensions. My suggestion is not > to update the priv field in the CSR ops table until the extension is > marked experimental (i.e. not frozen/ratified). Once the extension is > ratified and graduated from experimental to available stage, the privileged > spec version should be updated in the csr table if required. I am open to > other suggestions as well. > > [1] https://wiki.riscv.org/display/TECH/Recently+Ratified+Extensions > > Changes from v4->v5: > 1. Rebased on top of riscv-to-apply.next > > Changes from v3->v4: > 1. Added reviewed-by tags. > 2. Improved the commit text in PATCH 3 & 6. > > Changes from v2->v3: > 1. Only update the bits defined in *envcfg CSR > > Changes from v1->v2: > 1. Unified both [m/h]envcfg & [m/h]envcfgh into one. > 2. Changed the priv spec version enumeration > 3. Improved csr_ops table to provide better redability. > 4. Fixed the compilation error for CONFIG_USER_ONLY > 5. Rebased on top of the AIA series. > > Atish Patra (6): > target/riscv: Define simpler privileged spec version numbering > target/riscv: Add the privileged spec version 1.12.0 > target/riscv: Introduce privilege version field in the CSR ops. > target/riscv: Add support for mconfigptr > target/riscv: Add *envcfg* CSRs support > target/riscv: Enable privileged spec version 1.12 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Alistair > > target/riscv/cpu.c | 8 +- > target/riscv/cpu.h | 15 ++- > target/riscv/cpu_bits.h | 40 ++++++++ > target/riscv/csr.c | 217 +++++++++++++++++++++++++++++++++------- > target/riscv/machine.c | 23 +++++ > 5 files changed, 263 insertions(+), 40 deletions(-) > > -- > 2.30.2 > >
On Mon, Mar 7, 2022 at 12:14 PM Alistair Francis <alistair23@gmail.com> wrote: > > On Fri, Mar 4, 2022 at 4:59 AM Atish Patra <atishp@rivosinc.com> wrote: > > > > RISC-V International (RVI) has ratified many RISC-V ISA extensions recently[1]. > > The privileged specification version is also upgraded to v1.12. It means > > certain CSRs introduced in v1.12 should only be accessible only if the > > priv specification version supported is equal or greater than v1.12. > > Doing this check in predicate function is not scalable as there will be > > new CSRs introduced in the future versions of the privileged specification. > > > > This series tries to address this problem by adding a field in the csr_ops > > which can be checked in csrrw function before invoking the predicate function. > > To keep the code churn to minimum, it is assumed that the minimum version of > > the privilege version supported for any CSR is v1.10 unless specified > > explicitly in the csr_ops table. Any new CSRs introduced in v1.12 have been > > updated accordingly. > > > > This will work fine for any ratified extensions. However, it is bit unclear > > what should be done for the stable draft extensions. My suggestion is not > > to update the priv field in the CSR ops table until the extension is > > marked experimental (i.e. not frozen/ratified). Once the extension is > > ratified and graduated from experimental to available stage, the privileged > > spec version should be updated in the csr table if required. I am open to > > other suggestions as well. > > > > [1] https://wiki.riscv.org/display/TECH/Recently+Ratified+Extensions > > > > Changes from v4->v5: > > 1. Rebased on top of riscv-to-apply.next > > > > Changes from v3->v4: > > 1. Added reviewed-by tags. > > 2. Improved the commit text in PATCH 3 & 6. > > > > Changes from v2->v3: > > 1. Only update the bits defined in *envcfg CSR > > > > Changes from v1->v2: > > 1. Unified both [m/h]envcfg & [m/h]envcfgh into one. > > 2. Changed the priv spec version enumeration > > 3. Improved csr_ops table to provide better redability. > > 4. Fixed the compilation error for CONFIG_USER_ONLY > > 5. Rebased on top of the AIA series. > > > > Atish Patra (6): > > target/riscv: Define simpler privileged spec version numbering > > target/riscv: Add the privileged spec version 1.12.0 > > target/riscv: Introduce privilege version field in the CSR ops. > > target/riscv: Add support for mconfigptr > > target/riscv: Add *envcfg* CSRs support > > target/riscv: Enable privileged spec version 1.12 > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Whoops, meant to say: Thanks! Applied to riscv-to-apply.next Alistair > > Alistair > > > > > target/riscv/cpu.c | 8 +- > > target/riscv/cpu.h | 15 ++- > > target/riscv/cpu_bits.h | 40 ++++++++ > > target/riscv/csr.c | 217 +++++++++++++++++++++++++++++++++------- > > target/riscv/machine.c | 23 +++++ > > 5 files changed, 263 insertions(+), 40 deletions(-) > > > > -- > > 2.30.2 > > > >