From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
Bernhard Beschow <shentey@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Pierrick Bouvier <pierrick.bouvier@linaro.org>,
Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Subject: Re: [PATCH v2 0/2] KVM Support for imx8mp-evk Machine
Date: Fri, 31 Oct 2025 19:18:28 +0100 [thread overview]
Message-ID: <a7f5d348-1243-4c52-8dc1-66e2c3da40ae@linaro.org> (raw)
In-Reply-To: <CAFEAcA_sbvMEJ-oTxTYOutgUrH0iapNcJrsZd3=Ov6wNn-NE3w@mail.gmail.com>
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/
>
> 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"?)
I will think about it, but unfortunately I am not sure I'll have time
before the freeze...
This might help (untested) -- although going backward w.r.t. single
binary but not important for the 10.2 release --:
---
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 61c66ee2d0b..151ed020d1a 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -62,4 +62,4 @@ arm_common_ss.add(when: 'CONFIG_ARMSSE', if_true:
files('armsse.c'))
arm_common_ss.add(when: 'CONFIG_FSL_IMX7', if_true:
files('fsl-imx7.c', 'mcimx7d-sabre.c'))
-arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP', if_true:
files('fsl-imx8mp.c'))
-arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP_EVK', if_true:
files('imx8mp-evk.c'))
+arm_ss.add(when: 'CONFIG_FSL_IMX8MP', if_true: files('fsl-imx8mp.c'))
+arm_ss.add(when: 'CONFIG_FSL_IMX8MP_EVK', if_true: files('imx8mp-evk.c'))
arm_common_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmuv3.c'))
---
next prev parent reply other threads:[~2025-10-31 18:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 14:23 [PATCH v2 0/2] KVM Support for imx8mp-evk Machine Bernhard Beschow
2025-10-29 14:23 ` [PATCH v2 1/2] hw/arm/imx8mp-evk: Add KVM support Bernhard Beschow
2025-10-29 14:23 ` [PATCH v2 2/2] hw/arm/imx8mp-evk: Fix guest time in KVM mode Bernhard Beschow
2025-10-31 14:03 ` Philippe Mathieu-Daudé
2025-10-31 11:16 ` [PATCH v2 0/2] KVM Support for imx8mp-evk Machine Bernhard Beschow
2025-10-31 16:57 ` Peter Maydell
2025-10-31 17:12 ` Peter Maydell
2025-10-31 18:18 ` Philippe Mathieu-Daudé [this message]
2025-10-31 18:30 ` Peter Maydell
2025-11-01 12:09 ` Bernhard Beschow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7f5d348-1243-4c52-8dc1-66e2c3da40ae@linaro.org \
--to=philmd@linaro.org \
--cc=manos.pitsidianakis@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shentey@gmail.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).