[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae122f06f0de1075cf266b639ce36da3@mailhost.ics.forth.gr>
Date: Sat, 09 Oct 2021 16:18:48 +0300
From: Nick Kossifidis <mick@....forth.gr>
To: Alexandre Ghiti <alexandre.ghiti@...onical.com>
Cc: Nick Kossifidis <mick@....forth.gr>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>,
linux-riscv <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] riscv: Don't use va_pa_offset on kdump
Στις 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).
>
> This patch fixes a regression introduced when moving the kernel to the
> end of the address space, so we should add:
> Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear
> mapping")
>
> And it should be backported to 5.13 and 5.14. It seems that the
> following tags should be enough:
>
> Cc: <stable@...r.kernel.org> # 5.13
> Cc: <stable@...r.kernel.org> # 5.14
>
> And finally, you can add:
>
> Reviewed-by: Alexandre Ghiti <alex@...ti.fr>
>
ACK, thanks ! I'll resend the patch with the tags you mentioned.
Regards,
Nick
Powered by blists - more mailing lists