On Fri, 31 Oct 2025 at 18:18, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 31/10/25 18:12, Peter Maydell wrote: > > On Fri, 31 Oct 2025 at 16:57, Peter Maydell <[email protected]> > > wrote: > >> > >> On Wed, 29 Oct 2025 at 14:23, Bernhard Beschow <[email protected]> wrote: > >>> > >>> This series adds KVM support to the imx8mp-evk machine, allowing it to run > >>> guests with KVM acceleration. Inspiration was taken from the virt > >>> machine. This > >>> required a device tree quirk for the guest clock to be kept in sync with > >>> the > >>> host. Without this quirk the guest's clock would advance with factor <host > >>> system counter> / 8Mhz. > >>> > >>> Testing done: > >>> * Run `qemu-system-aarch64 -M imx8mp-evk -accel kvm -smp 4` under > >>> `qemu-system-aarch64 -M virt,secure=on,virtualization=on,gic-version=4 > >>> \ > >>> -cpu cortex-a72 -smp 4 -accel tcg` and `qemu-system-aarch64 -M > >>> imx8mp-evk \ > >>> -accel tcg -smp 4". Observe that the `date` command reflects the > >>> host's date. > >>> > >>> v2: > >>> * Mention various tradeoffs in the board documentation (Peter) > >>> * Accommodate for single-binary (Peter, Pierrick) by having CPU defaults > >>> > >>> Bernhard Beschow (2): > >>> hw/arm/imx8mp-evk: Add KVM support > >>> hw/arm/imx8mp-evk: Fix guest time in KVM mode > >> > >> Thanks, I've applied this to target-arm.next. > > > > ...I've had to un-queue it, as it breaks "make check": > > > > test: qemu:qtest+qtest-aarch64 / > > qtest-aarch64/device-introspect-test > > start time: 17:06:52 > > duration: 3.70s > > result: killed by signal 6 SIGABRT > > command: MALLOC_PERTURB_=155 > > UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 > > PYTHON=/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/arm-clang/pyvenv/bin/python3 > > G_TEST_DBUS_DAEMON=/data_nvme1n1/linaro/qemu-from-laptop/qemu/tests/dbus-vmstate-daemon.sh > > RUST_BACKTRACE=1 > > MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 > > QTEST_QEMU_BINARY=./qemu-system-aarch64 > > QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon > > ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 > > QTEST_QEMU_IMG=./qemu-img MESON_TEST_ITERATION=1 > > /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/qtest/device-introspect-test > > --tap -k > > ----------------------------------- stdout > > ----------------------------------- > > [...] > > # Testing device 'fsl-imx8mp' > > ----------------------------------- stderr > > ----------------------------------- > > unknown type '(null)' > > Broken pipe > > ../../tests/qtest/libqtest.c:199: kill_qemu() tried to terminate QEMU > > process but encountered exit status 1 (expected 0) > > > > > > I think the problem is that you're trying to use ms->cpu_type > > in the fsl_imx8mp_init() function. This doesn't work in the > > device-introspect-test setup, because it is just instantiating > > each device for test, not running a full machine. > > > > I think the way we usually avoid this is that if an SoC > > device object needs to know what CPU type to instantiate > > it has a QOM property, and the board model tells it. > > (Annoyingly this then means the CPU instantiation has to > > move into the realize method where the property value is known.) > > Correct, this is the same issue I tried to address with the Raspi > machines and I noted your comments: > https://lore.kernel.org/qemu-devel/cafeaca961wkb4fxwas0whxxkwyeo7tnmovd4z-bpgehr6sx...@mail.gmail.com/
I think it's different, because for the raspi case the SoC object is trying to create a CPU type that it can't: unknown type 'cortex-a72-arm-cpu' (because it's the arm device-introspect-test and that CPU is an aarch64 one) whereas for this one we are in the aarch64 test, but trying to use a NULL pointer as our type string: unknown type '(null)' Single binary vs compile-everything is probably a red herring here. thanks -- PMM
