Re: [PATCH v2 0/2] KVM Support for imx8mp-evk Machine

[Peter Maydell <peter.maydell@linaro.org>]

On Fri, 31 Oct 2025 at 18:18, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 31/10/25 18:12, Peter Maydell wrote:
> > On Fri, 31 Oct 2025 at 16:57, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>
> >> On Wed, 29 Oct 2025 at 14:23, Bernhard Beschow <shentey@gmail.com> 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-BPGehr6sxBQw@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