On Tue, Aug 27, 2024 at 11:36 AM Richard Henderson <richard.hender...@linaro.org> wrote: > > On 8/27/24 10:52, Deepak Gupta wrote: > > senvcfg and menvcfg belong to S and M state and don't actually mean anything > > for qemu-user. > > Certainly they do, in that you obviously have arch_prctl calls that adjust > them. The fact > that you've modeled those so far as separate variables is part of what is > confusing. > > > However if that's how it is for arm as well (i.e. exposing system > > state for qemu-user), then probably there is precedent. > > I think having special paths for qemu-user in target/arch/ is maintenance > burden, and > should be avoided if possible. The best way to reason with user-only is to > treat it just > like the full machine, and set the fields just like the real bios and kernel > would do.
I agree about avoiding adding these special variables. Can't we just use the extension check to enable it for userspace? Exposing the *envcfg CSRs to userspace seems tricky as everything is currently built with the S/M CSRs removed from user builds. Alistair > > > So while shadow stack and zicbo are similar in terms of enabling. Landing > > pad > > enable differs. > > You still want me to generalize *envcfg flow? > > Hmm. I'll leave that to riscv maintainers; perhaps a third user is required > to show > generality... > > > r~ >
