tree c9e0af2e64c39e5c1142238737e105a86d14cfa5
parent 417296c8d8588f782018d01a317f88957e9786d6
author Daniel Henrique Barboza <dbarboza@ventanamicro.com> 1675692020 -0300
committer Palmer Dabbelt <palmer@rivosinc.com> 1676562916 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEKzw3R0RoQ7JKlDp6LhMZ81+7GIkFAmPuUe0THHBhbG1lckBk
 YWJiZWx0LmNvbQAKCRAuExnzX7sYiRMgD/9yykQ9Yu6sNvzkYejZGQeYjEEOa6ZO
 1zdHvadJz8VAp9f0rp/AB8dl6yZS8zNl8+4oOfQs1/61aZlWYutW6f5MnO6nRwYR
 u79ud1T1s5srVonTEewC7I9h9tUCYksI0msQQnKPqXiFSF9CJyNvMPr9EFUhhwG/
 CZlOFNki4KEBqu9dM319nQc3obQFtZj67GCZgW8TjBOMO6YNVWHlAd6nNHSN2e5C
 AQUWy6qNhJQgeZ7rRtW2IyRQngJlPEPtB9n8xi0B1b7Ta2U5TgxtE2awIF57SXhO
 oWBQvLvdcDaJ9o5za4pof6G1TFu6Gut0SF5KD0Cp9BmW1DszskI1YMTvHWLOggKg
 K/scXR3CDL5pjzAowVNX34qiVFNNj6MUQupbR8CekqFDa5Zikup6LeqZYRj8nQFp
 FmdwxaMGsulHnvMgdqrzQvZrrae9jzIpZzPHEKOecJqJeVRMZ2ZfHTEcFaPL1xlc
 3WfBfCesB66NOShC1xyN5ZlzrREkDE7CivFt/B4/vyhfPcPLN2u3L8lncMOwIEwa
 br2zsX0E9TZmLONuwB/XzL/qWwFKWzco1z4I1M+cpxioOslqi8R/iRcNfXb5fzxN
 Xny/10+d4CBlHnFa+ZdvRS0S+Pn68VBVMXKT+ujlorMgFtRZbN3oodwv2aSnSKgL
 a0i3uJ0yjDckCg==
 =8WkW
 -----END PGP SIGNATURE-----

hw/riscv: handle 32 bit CPUs kernel_entry in riscv_load_kernel()

Next patch will move all calls to riscv_load_initrd() to
riscv_load_kernel(). Machines that want to load initrd will be able to
do via an extra flag to riscv_load_kernel().

This change will expose a sign-extend behavior that is happening in
load_elf_ram_sym() when running 32 bit guests [1]. This is currently
obscured by the fact that riscv_load_initrd() is using the return of
riscv_load_kernel(), defined as target_ulong, and this return type will
crop the higher 32 bits that would be padded with 1s by the sign
extension when running in 32 bit targets. The changes to be done will
force riscv_load_initrd() to use an uint64_t instead, exposing it to the
padding when dealing with 32 bit CPUs.

There is a discussion about whether load_elf_ram_sym() should or should
not sign extend the value returned by 'lowaddr'. What we can do is to
prevent the behavior change that the next patch will end up doing.
riscv_load_initrd() wasn't dealing with 64 bit kernel entries when
running 32 bit CPUs, and we want to keep it that way.

One way of doing it is to use target_ulong in 'kernel_entry' in
riscv_load_kernel() and rely on the fact that this var will not be sign
extended for 32 bit targets. Another way is to explictly clear the
higher 32 bits when running 32 bit CPUs for all possibilities of
kernel_entry.

We opted for the later. This will allow us to be clear about the design
choices made in the function, while also allowing us to add a small
comment about what load_elf_ram_sym() is doing. With this change, the
consolation patch can do its job without worrying about unintended
behavioral changes.

[1] https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg02281.html

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230206140022.2748401-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>