|
From: | Richard Henderson |
Subject: | Re: [PATCH v9 03/17] target/riscv: save and restore elp state on priv transitions |
Date: | Tue, 27 Aug 2024 14:29:10 +1000 |
User-agent: | Mozilla Thunderbird |
On 8/27/24 14:03, Alistair Francis wrote:
On Tue, Aug 27, 2024 at 1:58 PM Richard Henderson <richard.henderson@linaro.org> wrote:On 8/27/24 13:53, Alistair Francis wrote:Exposing the *envcfg CSRs to userspace seems tricky as everything is currently built with the S/M CSRs removed from user builds.It is as simple as moving them out of ifdefs, then initializing them as needed in reset for CONFIG_USER_ONLY. That's what we do for Arm.Is that really better though? Then we have these CSRs that are included in the build, so people can write code that checks the CSRs, but they are never actually changed. I guess it simplified the CONFIG_USER_ONLY checks, which is handy and your original point. But it seems like it is clunky that we have these CSRs that are kind of fake
They're not fake. They're a reflection of how the system-mode kernel configures the system-mode user environment.
The u[bf]cfien variables introduced in this patch set are an indication of this. Within this patch set they're always false. But the intent is to implement the (proposed) prctl syscalls that will set them to true (on hold waiting for kernel abi to land upstream, but were present in an earlier patch set revision.)
The correct implementation of those syscalls, in my opinion, is to set the corresponding [ms]envcfg bits. Just as linux-user/aarch64/target_prctl.h does for SVE et al.
r~
[Prev in Thread] | Current Thread | [Next in Thread] |