On 8/27/24 14:03, Alistair Francis wrote:
On Tue, Aug 27, 2024 at 1:58 PM Richard Henderson
<richard.hender...@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~
