On Thu, Nov 23, 2023 at 5:24 PM Akihiko Odaki <akihiko.od...@daynix.com> wrote: > > On 2023/11/23 12:04, Alistair Francis wrote: > > On Mon, Oct 30, 2023 at 3:50 PM Akihiko Odaki <akihiko.od...@daynix.com> > > wrote: > >> > >> The effective MXL value matters when booting. > > > > This doesn't sound right. Surely the max is what matters here > > > > Also, this was specifically changed to misa_mxl_max in db23e5d981a > > "target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl". > > > > This needs a much better description of why this change should be made > > > > Alistair > > The kernel will be executed with the current MXL rather than the initial > MXL value so the current MXL should be used here. > > For example, if you are going to emulate a system that has a RV64 CPU > and a firmware that sets the MXL to RV32, then mxl_max should be > MXL_RV64 and mxl should be MXL_RV32, and the kernel should be assumed as > a RV32 binary. Loading a 64-bit kernel will not work in such a case.
But this is called before the firmware runs, so it won't be changed by firmware. Maybe it's worth putting what this fixes in the commit message? Alistair > > You can find a similar example in x86_64: x86_64 systems typically > starts in 16-bit mode, and the firmware switches to 64-bit mode. When > emulating those systems, QEMU switches to 64-bit mode and loads a 64-bit > kernel. > > Regards, > Akihiko Odaki
