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);