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.) Philippe may know if there's a nicer way to deal with this. (Would it be too ugly to just handle ms->cpu_type == NULL as "assume default"?) thanks -- PMM
