Am 31. Oktober 2025 18:30:02 UTC schrieb Peter Maydell
<[email protected]>:
>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.
I've sent v3 [1] with a pragmatic fix for qtest in the hope that it could make
it into 10.2. If we find better ways to avoid the qtest crash I'm all for it.
Best regards,
Bernhard
[1] https://patchew.org/QEMU/[email protected]/
>
>thanks
>-- PMM
