| Message ID | 20240827231906.553327-2-debug@rivosinc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | riscv support for control flow integrity extensions | expand |
On Wed, Aug 28, 2024 at 9:21 AM Deepak Gupta <debug@rivosinc.com> wrote: > > Execution environment config CSR controlling user env and current > privilege state shouldn't be limited to qemu-system only. *envcfg > CSRs control enabling of features in next lesser mode. In some cases > bits *envcfg CSR can be lit up by kernel as part of kernel policy or > software (user app) can choose to opt-in by issuing a system call > (e.g. prctl). In case of qemu-user, it should be no different because > qemu is providing underlying execution environment facility and thus > either should provide some default value in *envcfg CSRs or react to > system calls (prctls) initiated from application. > > `henvcfg` has been left for qemu-system only because it is not expected > that someone will use qemu-user where application is expected to have > hypervisor underneath which is controlling its execution environment. If > such a need arises then `henvcfg` could be exposed as well. > > Relevant discussion: > https://lore.kernel.org/all/CAKmqyKOTVWPFep2msTQVdUmJErkH+bqCcKEQ4hAnyDFPdWKe0Q@mail.gmail.com/ > > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Alistair > --- > target/riscv/cpu.h | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h > index 87742047ce..270a2a031c 100644 > --- a/target/riscv/cpu.h > +++ b/target/riscv/cpu.h > @@ -226,8 +226,12 @@ struct CPUArchState { > uint32_t elf_flags; > #endif > > -#ifndef CONFIG_USER_ONLY > target_ulong priv; > + /* CSRs for execution environment configuration */ > + uint64_t menvcfg; > + target_ulong senvcfg; > + > +#ifndef CONFIG_USER_ONLY > /* This contains QEMU specific information about the virt state. */ > bool virt_enabled; > target_ulong geilen; > @@ -429,12 +433,9 @@ struct CPUArchState { > target_ulong upmmask; > target_ulong upmbase; > > - /* CSRs for execution environment configuration */ > - uint64_t menvcfg; > uint64_t mstateen[SMSTATEEN_MAX_COUNT]; > uint64_t hstateen[SMSTATEEN_MAX_COUNT]; > uint64_t sstateen[SMSTATEEN_MAX_COUNT]; > - target_ulong senvcfg; > uint64_t henvcfg; > #endif > target_ulong cur_pmmask; > -- > 2.44.0 > >
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index 87742047ce..270a2a031c 100644 --- a/target/riscv/cpu.h +++ b/target/riscv/cpu.h @@ -226,8 +226,12 @@ struct CPUArchState { uint32_t elf_flags; #endif -#ifndef CONFIG_USER_ONLY target_ulong priv; + /* CSRs for execution environment configuration */ + uint64_t menvcfg; + target_ulong senvcfg; + +#ifndef CONFIG_USER_ONLY /* This contains QEMU specific information about the virt state. */ bool virt_enabled; target_ulong geilen; @@ -429,12 +433,9 @@ struct CPUArchState { target_ulong upmmask; target_ulong upmbase; - /* CSRs for execution environment configuration */ - uint64_t menvcfg; uint64_t mstateen[SMSTATEEN_MAX_COUNT]; uint64_t hstateen[SMSTATEEN_MAX_COUNT]; uint64_t sstateen[SMSTATEEN_MAX_COUNT]; - target_ulong senvcfg; uint64_t henvcfg; #endif target_ulong cur_pmmask;
Execution environment config CSR controlling user env and current privilege state shouldn't be limited to qemu-system only. *envcfg CSRs control enabling of features in next lesser mode. In some cases bits *envcfg CSR can be lit up by kernel as part of kernel policy or software (user app) can choose to opt-in by issuing a system call (e.g. prctl). In case of qemu-user, it should be no different because qemu is providing underlying execution environment facility and thus either should provide some default value in *envcfg CSRs or react to system calls (prctls) initiated from application. `henvcfg` has been left for qemu-system only because it is not expected that someone will use qemu-user where application is expected to have hypervisor underneath which is controlling its execution environment. If such a need arises then `henvcfg` could be exposed as well. Relevant discussion: https://lore.kernel.org/all/CAKmqyKOTVWPFep2msTQVdUmJErkH+bqCcKEQ4hAnyDFPdWKe0Q@mail.gmail.com/ Signed-off-by: Deepak Gupta <debug@rivosinc.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> --- target/riscv/cpu.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)