docs/system/arm/imx8mp-evk.rst | 18 ++++++++++++++++++ hw/arm/fsl-imx8mp.c | 33 ++++++++++++++++++++++++++++----- hw/arm/imx8mp-evk.c | 21 +++++++++++++++++++++ hw/arm/Kconfig | 3 ++- 4 files changed, 69 insertions(+), 6 deletions(-)
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 docs/system/arm/imx8mp-evk.rst | 18 ++++++++++++++++++ hw/arm/fsl-imx8mp.c | 33 ++++++++++++++++++++++++++++----- hw/arm/imx8mp-evk.c | 21 +++++++++++++++++++++ hw/arm/Kconfig | 3 ++- 4 files changed, 69 insertions(+), 6 deletions(-) -- 2.51.2
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 tweaked the docs for the bit about security slightly to add a link to the security policy page: -* Unlike other machines with KVM support, the ``imx8mp-evk`` machine makes no - attempt to protect itself from malicious guests. If you don't trust your +* The ``imx8mp-evk`` machine is not included under the "virtualization use + case" of :doc:`QEMU's security policy </system/security>`. This means that + you should not trust that it can contain malicious guests, whether it is + run using TCG or KVM. If you don't trust your -- PMM
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.) 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
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'))
---
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
Am 31. Oktober 2025 18:30:02 UTC schrieb 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. 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/20251101120130.236721-1-shentey@gmail.com/ > >thanks >-- PMM
Am 29. Oktober 2025 14:23:09 UTC schrieb Bernhard Beschow <shentey@gmail.com>: >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 > Any chance we could get this into 10.2? Best regards, Bernhard > > >Bernhard Beschow (2): > > hw/arm/imx8mp-evk: Add KVM support > > hw/arm/imx8mp-evk: Fix guest time in KVM mode > > > > docs/system/arm/imx8mp-evk.rst | 18 ++++++++++++++++++ > > hw/arm/fsl-imx8mp.c | 33 ++++++++++++++++++++++++++++----- > > hw/arm/imx8mp-evk.c | 21 +++++++++++++++++++++ > > hw/arm/Kconfig | 3 ++- > > 4 files changed, 69 insertions(+), 6 deletions(-) > > > >-- > >2.51.2 > > >
© 2016 - 2025 Red Hat, Inc.