From f51d89df30140074ab90de41a5b29a03d1c84833 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Wed, 6 Apr 2022 21:09:54 -0400 Subject: [PATCH] riscv: pmp: work around a QEMU bug The NAPOT mode isn't computed properly in qemu when the full address range is covered. Let's hardcode the value that the qemu code checks explicitly until the appropriate fix is applied to qemu itself. For reference, here's the qemu patch: https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00961.html Signed-off-by: Nicolas Pitre --- arch/riscv/core/pmp.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/riscv/core/pmp.c b/arch/riscv/core/pmp.c index 4af0a541537..4df0a12912c 100644 --- a/arch/riscv/core/pmp.c +++ b/arch/riscv/core/pmp.c @@ -327,6 +327,16 @@ void z_riscv_pmp_stackguard_prepare(struct k_thread *thread) */ set_pmp_entry(&index, PMP_R | PMP_W | PMP_X, 0, 0, PMP_M_MODE(thread)); +#ifdef CONFIG_QEMU_TARGET + /* + * Workaround: The above produced 0x1fffffff which is correct. + * But there is a QEMU bug that prevents it from interpreting this + * value correctly. Hardcode the special case used by QEMU to + * bypass this bug for now. The QEMU fix is here: + * https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg00961.html + */ + thread->arch.m_mode_pmpaddr_regs[index-1] = -1L; +#endif /* remember how many entries we use */ thread->arch.m_mode_pmp_end_index = index;