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

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

[Bernhard Beschow]

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

[PATCH v2 1/2] hw/arm/imx8mp-evk: Add KVM support

[Bernhard Beschow]

Allows the imx8mp-evk machine to run guests with KVM acceleration.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 docs/system/arm/imx8mp-evk.rst | 18 ++++++++++++++++++
 hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
 hw/arm/imx8mp-evk.c            | 12 ++++++++++++
 hw/arm/Kconfig                 |  3 ++-
 4 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/docs/system/arm/imx8mp-evk.rst b/docs/system/arm/imx8mp-evk.rst
index b2f7d29ade..ccf81381b1 100644
--- a/docs/system/arm/imx8mp-evk.rst
+++ b/docs/system/arm/imx8mp-evk.rst
@@ -60,3 +60,21 @@ Now that everything is prepared the machine can be started as follows:
       -dtb imx8mp-evk.dtb \
       -append "root=/dev/mmcblk2p2" \
       -drive file=sdcard.img,if=sd,bus=2,format=raw,id=mmcblk2
+
+
+KVM Acceleration
+----------------
+
+To enable hardware-assisted acceleration via KVM, append
+``-accel kvm -cpu host`` to the command line. While this speeds up performance
+significantly, be aware of the following limitations:
+
+* 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
+  guests and you're relying on QEMU to be the security boundary, you want to
+  choose another machine such as ``virt``.
+* Rather than Cortex-A53 CPUs, the same CPU type as the host's will be used.
+  This is a limitation of KVM and may not work with guests with a tight
+  dependency on Cortex-A53.
+* No EL2 and EL3 exception levels are available which is also a KVM limitation.
+  Direct kernel boot should work but running U-Boot, TF-A, etc. won't succeed.
diff --git a/hw/arm/fsl-imx8mp.c b/hw/arm/fsl-imx8mp.c
index 866f4d1d74..7e61392abb 100644
--- a/hw/arm/fsl-imx8mp.c
+++ b/hw/arm/fsl-imx8mp.c
@@ -12,11 +12,13 @@
 #include "system/address-spaces.h"
 #include "hw/arm/bsa.h"
 #include "hw/arm/fsl-imx8mp.h"
-#include "hw/intc/arm_gicv3.h"
 #include "hw/misc/unimp.h"
 #include "hw/boards.h"
+#include "system/kvm.h"
 #include "system/system.h"
+#include "target/arm/cpu.h"
 #include "target/arm/cpu-qom.h"
+#include "target/arm/kvm_arm.h"
 #include "qapi/error.h"
 #include "qobject/qlist.h"
 
@@ -197,11 +199,10 @@ static void fsl_imx8mp_init(Object *obj)
 
     for (i = 0; i < MIN(ms->smp.cpus, FSL_IMX8MP_NUM_CPUS); i++) {
         g_autofree char *name = g_strdup_printf("cpu%d", i);
-        object_initialize_child(obj, name, &s->cpu[i],
-                                ARM_CPU_TYPE_NAME("cortex-a53"));
+        object_initialize_child(obj, name, &s->cpu[i], ms->cpu_type);
     }
 
-    object_initialize_child(obj, "gic", &s->gic, TYPE_ARM_GICV3);
+    object_initialize_child(obj, "gic", &s->gic, gicv3_class_name());
 
     object_initialize_child(obj, "ccm", &s->ccm, TYPE_IMX8MP_CCM);
 
@@ -274,7 +275,8 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
     /* CPUs */
     for (i = 0; i < ms->smp.cpus; i++) {
         /* On uniprocessor, the CBAR is set to 0 */
-        if (ms->smp.cpus > 1) {
+        if (ms->smp.cpus > 1 &&
+                object_property_find(OBJECT(&s->cpu[i]), "reset-cbar")) {
             object_property_set_int(OBJECT(&s->cpu[i]), "reset-cbar",
                                     fsl_imx8mp_memmap[FSL_IMX8MP_GIC_DIST].addr,
                                     &error_abort);
@@ -286,6 +288,16 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
         object_property_set_int(OBJECT(&s->cpu[i]), "cntfrq", 8000000,
                                 &error_abort);
 
+        if (object_property_find(OBJECT(&s->cpu[i]), "has_el2")) {
+            object_property_set_bool(OBJECT(&s->cpu[i]), "has_el2",
+                                     !kvm_enabled(), &error_abort);
+        }
+
+        if (object_property_find(OBJECT(&s->cpu[i]), "has_el3")) {
+            object_property_set_bool(OBJECT(&s->cpu[i]), "has_el3",
+                                     !kvm_enabled(), &error_abort);
+        }
+
         if (i) {
             /*
              * Secondary CPUs start in powered-down state (and can be
@@ -304,6 +316,7 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
     {
         SysBusDevice *gicsbd = SYS_BUS_DEVICE(&s->gic);
         QList *redist_region_count;
+        bool pmu = object_property_get_bool(OBJECT(first_cpu), "pmu", NULL);
 
         qdev_prop_set_uint32(gicdev, "num-cpu", ms->smp.cpus);
         qdev_prop_set_uint32(gicdev, "num-irq",
@@ -360,6 +373,16 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
                                qdev_get_gpio_in(cpudev, ARM_CPU_VIRQ));
             sysbus_connect_irq(gicsbd, i + 3 * ms->smp.cpus,
                                qdev_get_gpio_in(cpudev, ARM_CPU_VFIQ));
+
+            if (kvm_enabled()) {
+                if (pmu) {
+                    assert(arm_feature(&s->cpu[i].env, ARM_FEATURE_PMU));
+                    if (kvm_irqchip_in_kernel()) {
+                        kvm_arm_pmu_set_irq(&s->cpu[i], VIRTUAL_PMU_IRQ);
+                    }
+                    kvm_arm_pmu_init(&s->cpu[i]);
+                }
+            }
         }
     }
 
diff --git a/hw/arm/imx8mp-evk.c b/hw/arm/imx8mp-evk.c
index b3082fa60d..80036f8589 100644
--- a/hw/arm/imx8mp-evk.c
+++ b/hw/arm/imx8mp-evk.c
@@ -12,6 +12,7 @@
 #include "hw/arm/fsl-imx8mp.h"
 #include "hw/boards.h"
 #include "hw/qdev-properties.h"
+#include "system/kvm.h"
 #include "system/qtest.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
@@ -93,11 +94,22 @@ static void imx8mp_evk_init(MachineState *machine)
     }
 }
 
+static const char *imx8mp_evk_get_default_cpu_type(const MachineState *ms)
+{
+    if (kvm_enabled()) {
+        return ARM_CPU_TYPE_NAME("host");
+    }
+
+    return ARM_CPU_TYPE_NAME("cortex-a53");
+}
+
 static void imx8mp_evk_machine_init(MachineClass *mc)
 {
     mc->desc = "NXP i.MX 8M Plus EVK Board";
     mc->init = imx8mp_evk_init;
     mc->max_cpus = FSL_IMX8MP_NUM_CPUS;
     mc->default_ram_id = "imx8mp-evk.ram";
+    mc->get_default_cpu_type = imx8mp_evk_get_default_cpu_type;
 }
+
 DEFINE_MACHINE("imx8mp-evk", imx8mp_evk_machine_init)
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index b44b85f436..0cdeb60f1f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -622,7 +622,8 @@ config FSL_IMX8MP
 config FSL_IMX8MP_EVK
     bool
     default y
-    depends on TCG && AARCH64
+    depends on AARCH64
+    depends on TCG || KVM
     select FSL_IMX8MP
 
 config ARM_SMMUV3
-- 
2.51.2

[PATCH v2 2/2] hw/arm/imx8mp-evk: Fix guest time in KVM mode

[Bernhard Beschow]

The imx8mp DTB hardcodes the clock frequency of the system counter to 8MHz.
In KVM mode, the host CPU is used whose system counter runs at a different
frequency, resulting in the guest clock running slower or faster. Fix this
by not hardcoding the clock frequency which makes the Linux driver read
the real clock frequency from the register.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/arm/imx8mp-evk.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/hw/arm/imx8mp-evk.c b/hw/arm/imx8mp-evk.c
index 80036f8589..e26c62aee1 100644
--- a/hw/arm/imx8mp-evk.c
+++ b/hw/arm/imx8mp-evk.c
@@ -43,6 +43,15 @@ static void imx8mp_evk_modify_dtb(const struct arm_boot_info *info, void *fdt)
         fdt_nop_property(fdt, offset, "cpu-idle-states");
         offset = fdt_node_offset_by_compatible(fdt, offset, "arm,cortex-a53");
     }
+
+    if (kvm_enabled()) {
+        /* Use system counter frequency from host CPU to fix time in guest */
+        offset = fdt_node_offset_by_compatible(fdt, -1, "arm,armv8-timer");
+        while (offset >= 0) {
+            fdt_nop_property(fdt, offset, "clock-frequency");
+            offset = fdt_node_offset_by_compatible(fdt, offset, "arm,armv8-timer");
+        }
+    }
 }
 
 static void imx8mp_evk_init(MachineState *machine)
-- 
2.51.2

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

[Bernhard Beschow]

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
>
>
>

Re: [PATCH v2 2/2] hw/arm/imx8mp-evk: Fix guest time in KVM mode

[Philippe Mathieu-Daudé]

On 29/10/25 15:23, Bernhard Beschow wrote:
> The imx8mp DTB hardcodes the clock frequency of the system counter to 8MHz.
> In KVM mode, the host CPU is used whose system counter runs at a different
> frequency, resulting in the guest clock running slower or faster. Fix this
> by not hardcoding the clock frequency which makes the Linux driver read
> the real clock frequency from the register.
> 
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
>   hw/arm/imx8mp-evk.c | 9 +++++++++
>   1 file changed, 9 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

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

[Peter Maydell]

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

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

[Peter Maydell]

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

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

[Philippe Mathieu-Daudé]

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'))
---

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

[Peter Maydell]

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

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

[Bernhard Beschow]

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