Differential D26544
riscv: Panic on PMP errors Authored by kp on Sep 24 2020, 10:54 AM. Tags None Referenced Files
Details Load/store/fetch access exceptions always indicate a violation of a PMP We cannot recover from these exceptions, so panic instead. Sponsored by: Axiado
Diff Detail
Event TimelineComment Actions That's not true. You can get those faults even without a PMP if you try and access non-existent memory or if the hardware gives a bus fault due to an access that's not legal for a given peripheral. Comment Actions Those would also be unrecoverable errors, right? The problem I'm trying to address here is that if FreeBSD touches PMP protected memory it'll get a load/store/fetch fault and right now it treats that like a TLB miss, tries to load the right page table entry and then tries again. Which faults again, which ... (And as an aside, is there a better resource about RISC-V in these situations than "RISC-V Instruction Set Manual: Volume II: Privileged Architecture"? I can't seem to find anything relevant about bus errors there, but I may also be overlooking it.) Comment Actions Panicking here makes sense. Perhaps call it a "memory access exception" rather than a "PMP violation" per Jess's comment. I don't know of any other reference besides the priv spec. Comment Actions Yeah, the privileged spec calls each an "X access fault". The non-PMP discussion is in the "Physical Memory Attributes" section, and is a more general thing that can include bus faults on implementations where they can occur. Comment Actions Or maybe a panic if we don't expect that to ever happen (though if you start doing memory-mapped devices that's no longer the case). Comment Actions Yes, we should. See https://reviews.freebsd.org/D26621 I mmap()ed /dev/mem and accessed PMP protected memory. I see the same endless fault loop as in kernel mode, but it's easily "fixed" by terminating the process. I did need to implement /dev/mem mmap to test that: https://reviews.freebsd.org/D26622 |