Re: [Qemu-devel] [sw-dev] The problem of write misa on QEMU and BBL

[Michael Clark]

Hi Zong,

> On 19/04/2018, at 2:40 PM, Zong Li <address@hidden> wrote:
> 
> Hi all,
> 
> For BBL part, in fp_init at machine/minit.c,
> it will clear the D and F bits of misa register, and assertion that
> the bits is cleared.
> But the misa is WARL register, so there is no effect for writing it,
> and the assertion not be true.
> So is there has necessary to do that if toolchain not support D and F 
> extension?
> 
> For QEMU part, when writing misa, it will trigger the illegal
> instruction exception, but I think that the WARL allow write behavior?

QEMU in the riscv-all branch should have WARL behavior.

- https://github.com/riscv/riscv-qemu/commits/riscv-all

There is a bug in upstream. We have submitted patches to fix the issue for 
review on the qemu-devel mailing list. The patch series will be submitted for 
upstream review again shortly. We were holding off on the series as we didn’t 
classify it as a “critical bug” as QEMU was in soft-freeze for 2.12 and we 
weren’t able to get review in time to include this fix in the 2.12 release.

See “No traps on writes to misa,minstret,mcycle"

- https://github.com/riscv/riscv-qemu/commits/qemu-2.13-for-upstream

The history is that there were several unimplemented CSRs that had printf 
followed by exit. Richard Henderson said we should fix this. I changed several 
CSRs to cause illegal instruction traps instead of calling exit. That was a 
mistake as CSRs that don’t support write are WARL (Write Any Read Legal). It 
was certainly better than having the simulation exit as a cpu doesn’t typically 
have a way to ”exit” like a C program, nevertheless trapping was wrong. My 
mistake. See here for the history:

- 
https://github.com/riscv/riscv-qemu/blob/ff36f2f77ec3e6a6211c63bfe1707ec057b12f7d/target-riscv/op_helper.c

The implementation in the current tree is quite different. We have recently 
made the CSR system more modular so that with minor changes, custom CPUs will 
be able to hook their own control and status registers.

- 
https://github.com/riscv/riscv-qemu/blob/qemu-2.13-for-upstream/target/riscv/csr.c#L780-L867

See these changes:

- 
https://github.com/riscv/riscv-qemu/commit/9d9c1bfef911c520a35bd3f8c0ed2e14cc96bbb7
- 
https://github.com/riscv/riscv-qemu/commit/b5a4cd79ce6c7fbb65fdcf078fb9a8391da1d6b1

We know have a flexible system that will allow implementations to hook per-cpu 
control and status registers, and we have predicates that make CSRs appear on 
some processor but not on others. i.e. if misa.S is not present, then S-mode s* 
CSRs will trap. Sometimes WARL is the correct behaviour, but sometimes trapping 
is the correct behaviour i.e. if the processor does not implement S-mode.

misa traps on write should only affect bootloaders as Supervisor’s like Linux 
don’t yet have access to the isa register. It’s not a major issuse.

Michael.