| Message ID | 20230628213033.170315-3-dbarboza@ventanamicro.com |
|---|---|
| State | New |
| Headers | show |
| Series | target/riscv, KVM: fixes and enhancements | expand |
29.06.2023 00:30, Daniel Henrique Barboza wrote: > The absence of a satp mode in riscv_host_cpu_init() is causing the > following error: > > $ sudo ./qemu/build/qemu-system-riscv64 -machine virt,accel=kvm \ > -m 2G -smp 1 -nographic -snapshot \ > -kernel ./guest_imgs/Image \ > -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ > -append "earlycon=sbi root=/dev/ram rw" \ > -cpu host > ** > ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should not be > reached > Bail out! ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should > not be reached > Aborted Hi! Not a review/comment for the change itself, but a question about your work environment. Why do you run qemu with sudo? Is it just because your user lacks access to /dev/kvm device node (which is fixed by adding it to kvm group) ? I find it a bit worrying to see people run development as root and the recipes to run it as root ens up in even in commit messages. I think it's not good practice to do it like this, but more important is to teach users to do it this way. And this is more serious than one might think. Thanks, /mjt
On 6/30/23 04:36, Michael Tokarev wrote: > 29.06.2023 00:30, Daniel Henrique Barboza wrote: >> The absence of a satp mode in riscv_host_cpu_init() is causing the >> following error: >> >> $ sudo ./qemu/build/qemu-system-riscv64 -machine virt,accel=kvm \ >> -m 2G -smp 1 -nographic -snapshot \ >> -kernel ./guest_imgs/Image \ >> -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ >> -append "earlycon=sbi root=/dev/ram rw" \ >> -cpu host >> ** >> ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should not be >> reached >> Bail out! ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should >> not be reached >> Aborted > > Hi! > > Not a review/comment for the change itself, but a question about your > work environment. > > Why do you run qemu with sudo? Is it just because your user lacks access > to /dev/kvm device node (which is fixed by adding it to kvm group) ? Yes, it's because of /dev/kvm device access. These KVM tests were done in an emulated environment that don't have UAC properly set. > > I find it a bit worrying to see people run development as root and the > recipes to run it as root ens up in even in commit messages. I think > it's not good practice to do it like this, but more important is to > teach users to do it this way. And this is more serious than one might > think. Just removed all 'sudo' references from commit msgs for the next version. Daniel > > Thanks, > > /mjt
30.06.2023 10:46, Daniel Henrique Barboza wrote: > On 6/30/23 04:36, Michael Tokarev wrote: .. >> I find it a bit worrying to see people run development as root and the >> recipes to run it as root ens up in even in commit messages. I think >> it's not good practice to do it like this, but more important is to >> teach users to do it this way. And this is more serious than one might >> think. > > Just removed all 'sudo' references from commit msgs for the next version. Thank you Daniel! /mjt
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index 95708d890e..f025a0fcaf 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -243,13 +243,13 @@ static void create_fdt_socket_cpus(RISCVVirtState *s, int socket, s->soc[socket].hartid_base + cpu); qemu_fdt_add_subnode(ms->fdt, cpu_name); - satp_mode_max = satp_mode_max_from_map( - s->soc[socket].harts[cpu].cfg.satp_mode.map); - sv_name = g_strdup_printf("riscv,%s", - satp_mode_str(satp_mode_max, is_32_bit)); - qemu_fdt_setprop_string(ms->fdt, cpu_name, "mmu-type", sv_name); - g_free(sv_name); - + if (cpu_ptr->cfg.satp_mode.supported != 0) { + satp_mode_max = satp_mode_max_from_map(cpu_ptr->cfg.satp_mode.map); + sv_name = g_strdup_printf("riscv,%s", + satp_mode_str(satp_mode_max, is_32_bit)); + qemu_fdt_setprop_string(ms->fdt, cpu_name, "mmu-type", sv_name); + g_free(sv_name); + } name = riscv_isa_string(cpu_ptr); qemu_fdt_setprop_string(ms->fdt, cpu_name, "riscv,isa", name);
The absence of a satp mode in riscv_host_cpu_init() is causing the following error: $ sudo ./qemu/build/qemu-system-riscv64 -machine virt,accel=kvm \ -m 2G -smp 1 -nographic -snapshot \ -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ -append "earlycon=sbi root=/dev/ram rw" \ -cpu host ** ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should not be reached Bail out! ERROR:../target/riscv/cpu.c:320:satp_mode_str: code should not be reached Aborted The error is triggered from create_fdt_socket_cpus() in hw/riscv/virt.c. It's trying to get satp_mode_str for a NULL cpu->cfg.satp_mode.map. For this KVM cpu we would need to inherit the satp supported modes from the RISC-V host. At this moment this is not possible because the KVM driver does not support it. And even when it does we can't just let this broken for every other older kernel. Since mmu-type is not a required node, according to [1], skip the 'mmu-type' FDT node if there's no satp_mode set. We'll revisit this logic when we can get satp information from KVM. [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/cpu.yaml Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- hw/riscv/virt.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)