On Wed, 17 Oct 2018 23:44:26 PDT (-0700), day...@berkeley.edu wrote:
There is a data type demotion bug in target/riscv/pmp.c When the target_ulong is 8 bytes, pmpcfg_csr_read returns only lower 4 bytes.
This is missing at least the first requirement from https://wiki.qemu.org/Contribute/SubmitAPatch -- that's as far as I checked :). I can't take this one, please submit a v2.
--- target/riscv/pmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c index c828950..4b6c20e 100644 --- a/target/riscv/pmp.c +++ b/target/riscv/pmp.c @@ -337,7 +337,7 @@ target_ulong pmpcfg_csr_read(CPURISCVState *env, uint32_t reg_index) for (i = 0; i < sizeof(target_ulong); i++) { val = pmp_read_cfg(env, (reg_index * sizeof(target_ulong)) + i); - cfg_val |= (val << (i * 8)); + cfg_val |= ((target_ulong)val << ((target_ulong)i * 8)); } PMP_DEBUG("hart " TARGET_FMT_ld ": reg%d, val: 0x" TARGET_FMT_lx,
I believe this is correct: pmp_read_cfg() gives us the 8-bit PMP value, which then needs to be mixed together to form a single CSR value. The default promotion rules will result in an integer here ("i*8" is integer, which flows through) resulting in a 32-bit signed value on most hosts. That's obviously bogus on RV64I, with the high bits of the CSR being wrong.
Aside from the metadata Reviewed-by: Palmer Dabbelt <pal...@sifive.com> Thanks!