riscv virt framebuffer mmio?
Hi, what is the mmio address for the virtio framebuffer for the riscv64 virt machine?
Re: error compiling qemu 6.2.0
On Thu, 17 Feb 2022 at 14:27, Glenn Michael Petrie via wrote: > > I have a problem compiling this version of QEMU which I didn't have people. I > am compiling it using the git repository and am in the process of "make"ing > it. I got up to [2072/9676] then I get a "Segmentation Fault", as shown below; > /tmp/ccddypkh.s: Assembler messages: > /tmp/ccddypkh.s:1052709: Internal error (Segmentation fault). > Please report this bug. > ninja: build stopped: subcommand failed. > during IPA pass: icf > ../target/arm/sve_helper.c:7651:1: internal compiler error: Segmentation fault > 7651 | DO_FCVTLT(sve2_fcvtlt_sd, uint64_t, uint32_t, H1_8, H1_4, > float32_to_float64) > | ^ > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > ninja: build stopped: subcommand failed. If the compiler and assembler are generating non-repeatable SIGSEGVs, this strongly suggests you have a hardware problem. Try testing your memory and/or cross checking using a different host system. -- PMM
error compiling qemu 6.2.0
I have a problem compiling this version of QEMU which I didn't have people. I am compiling it using the git repository and am in the process of "make"ing it. I got up to [2072/9676] then I get a "Segmentation Fault", as shown below; [2072/9676] Compiling C object libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o cc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/gmp/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/gmp/qemu -iquote /home/gmp/qemu/include -iquote /home/gmp/qemu/disas/libvixl -iquote /home/gmp/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o -c ../target/arm/sve_helper.c /tmp/ccddypkh.s: Assembler messages: /tmp/ccddypkh.s:1052709: Internal error (Segmentation fault). Please report this bug. ninja: build stopped: subcommand failed. make[1]: *** [Makefile:163: run-ninja] Error 1 make[1]: Leaving directory '/home/gmp/qemu/build' make: *** [GNUmakefile:11: all] Error 2 When I try compiling this again, something completely different appears: [2/7606] Compiling C object libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o cc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/gmp/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/gmp/qemu -iquote /home/gmp/qemu/include -iquote /home/gmp/qemu/disas/libvixl -iquote /home/gmp/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_sve_helper.c.o -c ../target/arm/sve_helper.c during IPA pass: icf ../target/arm/sve_helper.c:7651:1: internal compiler error: Segmentation fault 7651 | DO_FCVTLT(sve2_fcvtlt_sd, uint64_t, uint32_t, H1_8, H1_4, float32_to_float64) | ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ninja: build stopped: subcommand failed. make[1]: *** [Makefile:163: run-ninja] Error 1 make[1]: Leaving directory '/home/gmp/qemu/build' make: *** [GNUmakefile:11: all] Error 2 What these two blocks of errors have in common is the file libqemu-aarch64-softmmu.fa.p. I am using Zorion OS 16 (Ubuntu 20.04 base) and gcc 9.3.0
Re: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true
On Thu, 17 Feb 2022 at 08:49, Chan Kim wrote: > I found by setting -cpu max, this ID_AA64MMFR1 register value is read > correctly. The value is correct in both cases. The Cortex-A72 does not implement the VHE architecture feature (it is mandatory from Armv8.1, but the A72 is an Armv8.0 core). The 'max' CPU implements every feature our emulation supports, which includes VHE. > But with qemu-5.1.0, this register value’s VH value is read as “” so it > goes to ‘install_el2_stub’ and returns with ‘msr elr_el2, lr’ and ‘eret’ so > that it drops down to el1 and start_kernsl runs in el1. This is all expected -- if the CPU does not support VHE then the kernel will fall back to implementing KVM in the older way (running the kernel proper in EL1 and with stub code in EL2 to do the things that must be done from EL2). > I thought by setting ‘virtualization=true’, the VH value will be > read as 1 and other VH features will be enabled in qemu but it seems not. No. virtualization=true just means "CPU should support virtualization, ie have an EL2". thanks -- PMM
RE: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true
I found by setting -cpu max, this ID_AA64MMFR1 register value is read correctly. With this setting, the start_kernel is entered in el2 as in the fpga test. Thanks! Chan Kim From: Chan Kim Sent: Thursday, February 17, 2022 4:18 PM To: 'qemu-discuss' Subject: ID_AA64MMFR1 VHE fields read as 0 when virtualization=true Hello all, I hope somebody could help me here.(booting linux using u-boot-spl) In linux-5.4.21 arch/arm64/kernel/head.S, there is this code in function el2_setup. #ifdef CONFIG_ARM64_VHE /* * Check for VHE being present. For the rest of the EL2 setup, * x2 being non-zero indicates that we do have VHE, and that the * kernel is intended to run at EL2. */ mrs x2, id_aa64mmfr1_el1 ubfxx2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4 #else mov x2, xzr #endif By the way, linux was entered at EL2 by u-boot. and when x2 is non-zero, we do stuff for VHE (virtualization hardware extension). When I do experiment with FPGA (arm64 core, supporting up to armv8.4), the value of id_aa64mmfr1_el1 's VH (4bits) field are read as "0001" so the el2_setup function later returns with 'ret' and the program remains in el2 and enters start_kernel in el2. (I built the kernel with CONFIG_ARM64_VHE=y). But with qemu-5.1.0, this register value's VH value is read as "" so it goes to 'install_el2_stub' and returns with 'msr elr_el2, lr' and 'eret' so that it drops down to el1 and start_kernsl runs in el1. The command I used for qemu is : ~/prj/abdsn/ab21sim/ab21tsim/QEMU/qemu-5.1.0/build-baremetal/aarch64-softmmu /qemu-system-aarch64 -machine ab21q,gic-version=max,secure=true,virtualization=true -cpu cortex-a72 -kernel ~/U-BOOT/u-boot/spl/u-boot-spl -m 2048M -nographic -device loader,file=/home/ckim/U-BOOT/u-boot/images/Image,addr=0x8008 -device loader,file=/home/ckim/U-BOOT/u-boot/images/ab21m.dtb,addr=0x807fd000 I thought by setting 'virtualization=true', the VH value will be read as 1 and other VH features will be enabled in qemu but it seems not. What am I missing? (I tried doing it with qemu-6.2.0 today by adding my virtual machine there. Linux boots ok with 'kernel=Image' method but when I do u-boot method, it doesn't proceed somewhere in u-boot so I couldn't check the above code. But start_kernel is in el1 as in 5.1.0) Any comment will be appreciated. Thank you! Chan Kim
