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

[Zong Li]

2018-04-19 12:43 GMT+08:00 Michael Clark <address@hidden>:
> 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.

Hi Michael,

Thanks for the information. The new CSR system is helpful for custom
CPU such as ours. Thanks.

In the future, maybe we can do something like this in BBL for flexible
custom platform which has own device to control the timer, ipi and so
on.

Back to the misa problem in BBL, at fp_init in BBL initial phrase, the
assertion will has problem because the bits of misa will not be
cleared.

the code piece like below:
    uintptr_t fd_mask = (1 << ('F' - 'A')) | (1 << ('D' - 'A'));
    clear_csr(misa, fd_mask);
    assert(!(read_csr(misa) & fd_mask));

I think that the assertion is not necessary even the clear misa.