opensbi
opensbi copied to clipboard
riscv-software-src
Access to time CSR is trap-emulated even when scounteren.TM is clear
Seems that OpenSBI is emulating missing CSRs on illegal instruction traps, for example unprivileged time counter via access to aclint-mtimer device.
This is not always correct since the S-mode may explicitly clear scounteren bits to disable unprivileged counters and receive illegal instruction traps.
Currently OpenSBI ignores that, and it breaks my virtualization solution that relies on running the guest in U-mode and trapping on privileged operations (including the timer access). It explicitly clears scounteren but OpenSBI does me a disservice and allows the virtualized guest to read host timer which effectively breaks the guest.
It would be also good if anyone has an idea how to tell older OpenSBI versions to give up on instruction emulation and just delegate illegal instruction traps to S-mode since a fixed OpenSBI version will take a long time to get on actual hardware.
This line confirms my thoughts: https://github.com/riscv-software-src/opensbi/blob/b9c091ed890224dc83a152d897965c7a332c1504/lib/sbi/sbi_emulate_csr.c#L73
It seems fairly weird that this is a thing even, CSR reads are not supposed to slow down the trap handling much? (unless they are missing too, but then they are just variables on OpenSBI side anyways).
Most newer boards this days include a fast rdtime implementation unless we are talking about 2018-2019 hardware.
Plus OpenSBI is meant to be a reference implementation, but this clearly violates the spec:
I agree, and I sent a patch to fix this: http://lists.infradead.org/pipermail/opensbi/2024-August/007304.html
It might also make sense to delegate illegal instruction traps to supervisor mode if it's figured at runtime that no instruction emulation is necessary for the board in question (To speed up user->supervisor traps when necessary). But this is of course a separate proposal. Maybe makes sense for another SBI call to ask for proper delegation?
How would you know that no instruction emulation is necessary? Right now that's not tracked anywhere; there is code to emulate everything, and if a platform doesn't need it, it just doesn't get called. And "necessary" depends on which ISA extensions you want to pretend the platform supports.
I think that would need a hardcoded list of "known-good" CPUs or SoCs in the firmware. An SBI call wouldn't be sufficient by itself, because S-mode software doesn't know which instructions can be emulated by a specific firmware version.
I think that would need a hardcoded list of "known-good" CPUs or SoCs in the firmware. An SBI call wouldn't be sufficient by itself, because S-mode software doesn't know which instructions can be emulated by a specific firmware version.
Maybe. But my situation is: I'm working on a virtualization solution that works in S-mode, and runs the guest in U-mode with shadow pagetables. When guest lands on a privileged instruction, it's expected to trap into host S-mode, then interpret the instruction properly and return to U-mode virtualization.
Currrently the OpenSBI behavior pessimizes my solution because now all traps have to go U->M->S modes and OpenSBI emulation code is traversed but not useful at the end. And it would be ideal if I could just ask OpenSBI "i'm fine on my own, please just delegate me all exceptions that happen here"
The "known-good" SoCs solution is good too, but the Linux kernel or other S-mode entity can decide if SoC is good anytime in future via using this "delegation request". Please let me know if any such implementation is desired or worked upon, so I can decide what contributions of mine can be theoretically accepted into OpenSBI.