On 1/23/26 10:39 AM, Jan Beulich wrote:
+} + +static void dump_csrs(unsigned long cause) +{ + unsigned long hstatus; + + printk("\nDumping CSRs...\n"); + + printk("Supervisor CSRs\n"); + print_csr(CSR_STVEC); + print_csr(CSR_SATP); + print_csr(CSR_SEPC); + + hstatus = csr_read(CSR_HSTATUS); + + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); + + printk("\tCSR_SCAUSE: %016lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_SSTATUS); + + printk("\nVirtual Supervisor CSRs\n"); + print_csr(CSR_VSTVEC); + print_csr(CSR_VSATP); + print_csr(CSR_VSEPC); + print_csr(CSR_VSTVAL); + cause = csr_read(CSR_VSCAUSE); + printk("\tCSR_VSCAUSE: %016lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_VSSTATUS);As before, imo justification is wanted (in the description) for logging VS* values.It is hard to describe in general why they could be needed. The best I can come up is: Dump VS* CSRs to provide full guest exception context. When handling traps originating from VS-mode, host CSRs alone do not describe the fault; VSCAUSE, VSEPC, VSTVAL, and related state are required to diagnose guest crashes and hypervisor misconfiguration, and to correlate host-side handling with guest-visible exceptions. Does it good enough justification?I think diagnosing guest crashes doesn't belong here. An unexpected trap is entirely different from a guest crash. Hypervisor misconfig I might buy, just that I don't (yet?) see the connection to the three particular registers you name in the suggested text. (As mentioned before, this may simply be because of my lack of a proper global picture of RISC-V.)
One of the options which could be stored in VSTVAL is a faulty instruction, so without checking VSEPC we could understand what is the instruction and check what is in HS-mode register to understand if enough permissions were given to VS-mode to use this instruction without trap to HS-mode. Considering that even if a source of trap is faulty instruction it doesn't guarantee that VSTVAL will contain this faulty instruction, so we should go to check VSEPC and then use objdump to understand what was faulty instruction. VSCAUSE could be useful for the case if for some reason guest doesn't dump VSCAUSE to its console, at least, we could get some extra information what was wrong during execution of faulty instruction. Also, there are a cases when from hypervisor some trap redirection to a guest happens and VSCAUSE is used for this purpose, VSTATUS and VSTVEC are used too, so it would be nice to check them too if such redirection leads to another trap because of incorrectly set VSCAUSE, VSTATUS and VSTVEC. I don't really see any reason to print VSATP, at least, at the moment. So I can drop it. ~ Oleksii
