On Wed, 30 Mar 2022 at 02:16, Atish Patra <ati...@atishpatra.org> wrote: > > This is in for-next on Alistair's tree and fails to boot the kernel > with the following error (found -d in_asm mode). > Reverting the patch solves the issue. > > ---------------- > IN: > Priv: 1; Virt: 0 > 0x0000000080201040: 18051073 csrrw zero,satp,a0 > > ---------------- > IN: > Priv: 1; Virt: 0 > 0x0000000080201044: Address 0x80201044 is out of bounds. > > 0x0000000080201049: Address 0x80201049 is out of bounds. > > 0x000000008020104e: Address 0x8020104e is out of bounds. > > Disassembler disagrees with translator over instruction decoding > Please report this to qemu-devel@nongnu.org > > ---------------- > IN: > Priv: 1; Virt: 0 > 0x0000000080201050: Address 0x80201050 is out of bounds. > > 0x0000000080201055: Address 0x80201055 is out of bounds. > > 0x000000008020105a: Address 0x8020105a is out of bounds. > > Disassembler disagrees with translator over instruction decoding > Please report this to qemu-devel@nongnu.org > > ---------------- > IN: > Priv: 1; Virt: 0 > 0x000000008020105c: Address 0x8020105c is out of bounds. > > Disassembler disagrees with translator over instruction decoding > Please report this to qemu-devel@nongnu.org > > -- > Regards, > Atish
Do you have more specific information about which kernel image doesn't boot? The errors you're seeing simply mean that these addresses are not translated by the new address translation context set by the write to the satp. To be honest I don't immediately see how this could be caused by the patch, as it modifies the behaviour of the sfence.vma instruction, and there are none in your trace. Idan Horowitz
