On Thu, Feb 23, 2023 at 2:53 AM Daniel Henrique Barboza <dbarb...@ventanamicro.com> wrote: > > At this moment, and apparently since ever, we have no way of enabling > RISCV_FEATURE_MISA. This means that all the code from write_misa(), all > the nuts and bolts that handles how to properly write this CSR, has > always been a no-op as well because write_misa() will always exit > earlier. > > This seems to be benign in the majority of cases. Booting an Ubuntu > 'virt' guest and logging all the calls to 'write_misa' shows that no > writes to MISA CSR was attempted. Writing MISA, i.e. enabling/disabling > RISC-V extensions after the machine is powered on, seems to be a niche > use. > > After discussions in the mailing list, most notably in [1], we reached > the consensus that this code is not suited to be exposed to users > because it's not well tested, but at the same time removing it is a bit > extreme because we would like to fix it, and it's easier to do so with > the code available to use instead of fetching it from git log. > > The approach taken here is to get rid of RISCV_FEATURE_MISA altogether > and use a new experimental flag called x-misa-w. The default value is > false, meaning that we're keeping the existing behavior of doing nothing > if a write_misa() is attempted. As with any existing experimental flag, > x-misa-w is also a temporary flag that we need to remove once we fix > write_misa(). > > [1] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg05092.html > > Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com> > --- > target/riscv/cpu.c | 6 ++++++ > target/riscv/cpu.h | 2 +- > target/riscv/csr.c | 2 +- > 3 files changed, 8 insertions(+), 2 deletions(-) >
Reviewed-by: Bin Meng <bm...@tinylab.org>
