Re: [PATCH] riscv: Don't use va_pa_offset on kdump

From: Nick Kossifidis
Date: Sun Oct 24 2021 - 21:00:28 EST


Στις 2021-10-23 23:14, Palmer Dabbelt έγραψε:
On Sat, 09 Oct 2021 06:18:48 PDT (-0700), mick@xxxxxxxxxxxx wrote:
Στις 2021-10-06 14:13, Alexandre Ghiti έγραψε:
+
+ /* This will trigger a jump to CSR_STVEC anyway */
jalr zero, a2, 0

The last jump to a2 can be removed since the fault will be triggered
before even reaching this instruction.


Just switching SATP to zero doesn't generate a trap unless mstatus.TVM
is set (for visualization purposes). The hart will try and execute the
next instruction but it's not clear in the spec what happens in case the
code is cached, I don't want to rely solely on STVEC. I prefer having
this instruction there, note that some earlier QEMU versions also had
this behavior (the original kdump patch didn't set STVEC and it worked
fine after setting SATP to zero).

IIRC this came down to some very specific wording in the spec.
Something along the lines of the 0 in SATP meaning "no translation",
SFENCE.VMA ordering translations, and the general "if the spec doesn't
mention it then it has to work" logic. I thought I opened a spec
issue about this for clarification, but I can't find it.


I guess you mean this one:
https://github.com/riscv/riscv-isa-manual/issues/538

I couldn't find anything though regarding cached code, it's not that there's going to be a load after setting satp to 0 if the code has been cached, so even if the translation is cached we don't have a guarantee that the next instruction will result a trap.

That said, I'm perfectly fine taking the safe approach here as it's
not like the performance matters here. Warrants a comment, though.


ACK


I don't have a v2 in my inbox, did I miss something? Also, if it's
just the tags then it's generally not necessary to re-send something.
The comment does, though.

LMK if you want me to deal with this, or if there's going to be a v2.

Thanks!

I'll send a v2 with the tags and the comment.

Regards,
Nick