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

[PATCH v3 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 `make check`
* Run Buildroot image with TCG
* 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.

v3:
* Fix crash in qtest (Peter) by using cortex-a53 CPU when ms->cpu_type == NULL
* Apply Peter's style fixes in board documentation
* Apply Phil's R-b -- thanks!
* Rebase onto master

v2:
* Rebase onto master
* Mention various tradeoffs in the board documentation (Peter)
* Accommodate for single-binary (Peter, Pierrick) by having CPU defaults
* Add quirk to fix guest clock

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 | 19 +++++++++++++++++++
 hw/arm/fsl-imx8mp.c            | 34 +++++++++++++++++++++++++++++-----
 hw/arm/imx8mp-evk.c            | 20 ++++++++++++++++++++
 hw/arm/Kconfig                 |  3 ++-
 4 files changed, 70 insertions(+), 6 deletions(-)

-- 
2.51.2

[PATCH v3 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 | 19 +++++++++++++++++++
 hw/arm/fsl-imx8mp.c            | 34 +++++++++++++++++++++++++++++-----
 hw/arm/imx8mp-evk.c            | 11 +++++++++++
 hw/arm/Kconfig                 |  3 ++-
 4 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/docs/system/arm/imx8mp-evk.rst b/docs/system/arm/imx8mp-evk.rst
index b2f7d29ade..75c8fbd366 100644
--- a/docs/system/arm/imx8mp-evk.rst
+++ b/docs/system/arm/imx8mp-evk.rst
@@ -60,3 +60,22 @@ 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:
+
+* 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 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..ee6f3e42d2 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"
 
@@ -193,15 +195,15 @@ static void fsl_imx8mp_init(Object *obj)
 {
     MachineState *ms = MACHINE(qdev_get_machine());
     FslImx8mpState *s = FSL_IMX8MP(obj);
+    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
     int i;
 
     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], 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 +276,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 +289,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 +317,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 +374,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 fc880a1d44..3ddcf1af5a 100644
--- a/hw/arm/imx8mp-evk.c
+++ b/hw/arm/imx8mp-evk.c
@@ -13,6 +13,7 @@
 #include "hw/arm/machines-qom.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"
@@ -94,12 +95,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_AARCH64("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 v3 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.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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 3ddcf1af5a..44e0601967 100644
--- a/hw/arm/imx8mp-evk.c
+++ b/hw/arm/imx8mp-evk.c
@@ -44,6 +44,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 v3 0/2] KVM Support for imx8mp-evk Machine

[Bernhard Beschow]

Am 1. November 2025 12:01:28 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 `make check`
>
>* Run Buildroot image with TCG
>
>* 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.
>
>
>
>v3:
>
>* Fix crash in qtest (Peter) by using cortex-a53 CPU when ms->cpu_type == NULL
>
>* Apply Peter's style fixes in board documentation
>
>* Apply Phil's R-b -- thanks!
>
>* Rebase onto master
>

Is there still a chance to get this series into 10.2? Soft feature freeze is tomorrow.

Best regards,
Bernhard

>
>
>v2:
>
>* Rebase onto master
>
>* Mention various tradeoffs in the board documentation (Peter)
>
>* Accommodate for single-binary (Peter, Pierrick) by having CPU defaults
>
>* Add quirk to fix guest clock
>
>
>
>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 | 19 +++++++++++++++++++
>
> hw/arm/fsl-imx8mp.c            | 34 +++++++++++++++++++++++++++++-----
>
> hw/arm/imx8mp-evk.c            | 20 ++++++++++++++++++++
>
> hw/arm/Kconfig                 |  3 ++-
>
> 4 files changed, 70 insertions(+), 6 deletions(-)
>
>
>
>-- >
>2.51.2
>
>
>

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

[Peter Maydell]

On Mon, 3 Nov 2025 at 08:55, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 1. November 2025 12:01:28 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 `make check`
> >
> >* Run Buildroot image with TCG
> >
> >* 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.
> >
> >
> >
> >v3:
> >
> >* Fix crash in qtest (Peter) by using cortex-a53 CPU when ms->cpu_type == NULL
> >
> >* Apply Peter's style fixes in board documentation
> >
> >* Apply Phil's R-b -- thanks!
> >
> >* Rebase onto master
> >
>
> Is there still a chance to get this series into 10.2? Soft feature freeze is tomorrow.

I've put this into the pullreq I've just sent out for softfreeze.

thanks
-- PMM

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

[Bernhard Beschow]

Am 3. November 2025 15:47:29 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Mon, 3 Nov 2025 at 08:55, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>>
>>
>> Am 1. November 2025 12:01:28 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 `make check`
>> >
>> >* Run Buildroot image with TCG
>> >
>> >* 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.
>> >
>> >
>> >
>> >v3:
>> >
>> >* Fix crash in qtest (Peter) by using cortex-a53 CPU when ms->cpu_type == NULL
>> >
>> >* Apply Peter's style fixes in board documentation
>> >
>> >* Apply Phil's R-b -- thanks!
>> >
>> >* Rebase onto master
>> >
>>
>> Is there still a chance to get this series into 10.2? Soft feature freeze is tomorrow.
>
>I've put this into the pullreq I've just sent out for softfreeze.

Thanks, Peter!

>
>thanks
>-- PMM

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

[Cornelia Huck]

On Sat, Nov 01 2025, Bernhard Beschow <shentey@gmail.com> wrote:

> 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 | 19 +++++++++++++++++++
>  hw/arm/fsl-imx8mp.c            | 34 +++++++++++++++++++++++++++++-----
>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>  hw/arm/Kconfig                 |  3 ++-
>  4 files changed, 61 insertions(+), 6 deletions(-)
>
> diff --git a/docs/system/arm/imx8mp-evk.rst b/docs/system/arm/imx8mp-evk.rst
> index b2f7d29ade..75c8fbd366 100644
> --- a/docs/system/arm/imx8mp-evk.rst
> +++ b/docs/system/arm/imx8mp-evk.rst
> @@ -60,3 +60,22 @@ 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:
> +
> +* 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 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..ee6f3e42d2 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"
>  
> @@ -193,15 +195,15 @@ static void fsl_imx8mp_init(Object *obj)
>  {
>      MachineState *ms = MACHINE(qdev_get_machine());
>      FslImx8mpState *s = FSL_IMX8MP(obj);
> +    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
>      int i;
>  
>      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], cpu_type);
>      }
>  
> -    object_initialize_child(obj, "gic", &s->gic, TYPE_ARM_GICV3);
> +    object_initialize_child(obj, "gic", &s->gic, gicv3_class_name());

Running current master (resp. with this patch applied), I'm getting make
check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
unknown type 'arm-gicv3'" while using this machine); going back right
before this patch, everything works fine. Haven't tried to debug this
yet (maybe I'm the one with the weird config again...)

>  
>      object_initialize_child(obj, "ccm", &s->ccm, TYPE_IMX8MP_CCM);
>  
> @@ -274,7 +276,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 +289,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 +317,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 +374,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 fc880a1d44..3ddcf1af5a 100644
> --- a/hw/arm/imx8mp-evk.c
> +++ b/hw/arm/imx8mp-evk.c
> @@ -13,6 +13,7 @@
>  #include "hw/arm/machines-qom.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"
> @@ -94,12 +95,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_AARCH64("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

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

[Peter Maydell]

On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
> Running current master (resp. with this patch applied), I'm getting make
> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
> unknown type 'arm-gicv3'" while using this machine); going back right
> before this patch, everything works fine. Haven't tried to debug this
> yet (maybe I'm the one with the weird config again...)

Is this a KVM-only config (no TCG) ?

I think this happens because the KConfig now says
+    depends on TCG || KVM

but because the machine by default doesn't use KVM then
trying to run the machine with no extra arguments falls
over if TCG isn't present.

This thing we put in to handle "creation of the SoC object
via device introspection means it doesn't have an ms->cpu_type
to look at":

+    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");

also probably won't do anything useful under a KVM-only config.

I think the simplest thing here is to put the KConfig back to:

  depends on TCG && AARCH64

People building a KVM-only config almost certainly do not
want this machine type and its devices, because the main
reason to build KVM-only is because you're in the
"virtualization use case" and want to not build in a
load of not-security-supported machine types.

thanks
-- PMM

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

[Bernhard Beschow]

Am 17. November 2025 17:38:03 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
>> Running current master (resp. with this patch applied), I'm getting make
>> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
>> unknown type 'arm-gicv3'" while using this machine); going back right
>> before this patch, everything works fine. Haven't tried to debug this
>> yet (maybe I'm the one with the weird config again...)
>
>Is this a KVM-only config (no TCG) ?
>
>I think this happens because the KConfig now says
>+    depends on TCG || KVM
>
>but because the machine by default doesn't use KVM then
>trying to run the machine with no extra arguments falls
>over if TCG isn't present.
>
>This thing we put in to handle "creation of the SoC object
>via device introspection means it doesn't have an ms->cpu_type
>to look at":
>
>+    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
>
>also probably won't do anything useful under a KVM-only config.
>
>I think the simplest thing here is to put the KConfig back to:
>
>  depends on TCG && AARCH64
>
>People building a KVM-only config almost certainly do not
>want this machine type and its devices, because the main
>reason to build KVM-only is because you're in the
>"virtualization use case" and want to not build in a
>load of not-security-supported machine types.

Do we need this treatment for further machines, e.g. isapc, e500, mips? Or shall the CPU type handling in the SoC consider kvm_enabled()?

Best regards,
Bernhard

>
>thanks
>-- PMM

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

[Cornelia Huck]

On Mon, Nov 17 2025, Peter Maydell <peter.maydell@linaro.org> wrote:

> On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
>> Running current master (resp. with this patch applied), I'm getting make
>> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
>> unknown type 'arm-gicv3'" while using this machine); going back right
>> before this patch, everything works fine. Haven't tried to debug this
>> yet (maybe I'm the one with the weird config again...)
>
> Is this a KVM-only config (no TCG) ?

Yes, it is. (Forgot about that...)

However, I noticed that a build I did after enabling tcg still failed,
and only after starting over with a fresh build directory, it worked  --
I'm wondering if I managed to trigger an unrelated problem?

>
> I think this happens because the KConfig now says
> +    depends on TCG || KVM
>
> but because the machine by default doesn't use KVM then
> trying to run the machine with no extra arguments falls
> over if TCG isn't present.
>
> This thing we put in to handle "creation of the SoC object
> via device introspection means it doesn't have an ms->cpu_type
> to look at":
>
> +    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
>
> also probably won't do anything useful under a KVM-only config.
>
> I think the simplest thing here is to put the KConfig back to:
>
>   depends on TCG && AARCH64
>
> People building a KVM-only config almost certainly do not
> want this machine type and its devices, because the main
> reason to build KVM-only is because you're in the
> "virtualization use case" and want to not build in a
> load of not-security-supported machine types.

I think that's a reasonable assumption.

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

[Cornelia Huck]

On Tue, Nov 18 2025, Cornelia Huck <cohuck@redhat.com> wrote:

> However, I noticed that a build I did after enabling tcg still failed,
> and only after starting over with a fresh build directory, it worked  --
> I'm wondering if I managed to trigger an unrelated problem?

At least, that one seems to have been a fluke, maybe I fat-fingered
something.

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

[Philippe Mathieu-Daudé]

On 18/11/25 10:49, Bernhard Beschow wrote:
> 
> 
> Am 17. November 2025 17:38:03 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
>>> Running current master (resp. with this patch applied), I'm getting make
>>> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
>>> unknown type 'arm-gicv3'" while using this machine); going back right
>>> before this patch, everything works fine. Haven't tried to debug this
>>> yet (maybe I'm the one with the weird config again...)
>>
>> Is this a KVM-only config (no TCG) ?
>>
>> I think this happens because the KConfig now says
>> +    depends on TCG || KVM
>>
>> but because the machine by default doesn't use KVM then
>> trying to run the machine with no extra arguments falls
>> over if TCG isn't present.
>>
>> This thing we put in to handle "creation of the SoC object
>> via device introspection means it doesn't have an ms->cpu_type
>> to look at":
>>
>> +    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
>>
>> also probably won't do anything useful under a KVM-only config.
>>
>> I think the simplest thing here is to put the KConfig back to:
>>
>>   depends on TCG && AARCH64
>>
>> People building a KVM-only config almost certainly do not
>> want this machine type and its devices, because the main
>> reason to build KVM-only is because you're in the
>> "virtualization use case" and want to not build in a
>> load of not-security-supported machine types.
> 
> Do we need this treatment for further machines, e.g. isapc, e500, mips? Or shall the CPU type handling in the SoC consider kvm_enabled()?

Good point. My understanding is only virt x86/arm/ppc64/s390x are
"security covered", but there is no explicit mention of that in
our doc. (btw why not include isapc? as it is a subset of other
covered x86 machines?)

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, 18 Nov 2025, Philippe Mathieu-Daudé wrote:
> On 18/11/25 10:49, Bernhard Beschow wrote:
>> Am 17. November 2025 17:38:03 UTC schrieb Peter Maydell 
>> <peter.maydell@linaro.org>:
>>> On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
>>>> Running current master (resp. with this patch applied), I'm getting make
>>>> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
>>>> unknown type 'arm-gicv3'" while using this machine); going back right
>>>> before this patch, everything works fine. Haven't tried to debug this
>>>> yet (maybe I'm the one with the weird config again...)
>>> 
>>> Is this a KVM-only config (no TCG) ?
>>> 
>>> I think this happens because the KConfig now says
>>> +    depends on TCG || KVM
>>> 
>>> but because the machine by default doesn't use KVM then
>>> trying to run the machine with no extra arguments falls
>>> over if TCG isn't present.
>>> 
>>> This thing we put in to handle "creation of the SoC object
>>> via device introspection means it doesn't have an ms->cpu_type
>>> to look at":
>>> 
>>> +    const char *cpu_type = ms->cpu_type ?: 
>>> ARM_CPU_TYPE_NAME("cortex-a53");
>>> 
>>> also probably won't do anything useful under a KVM-only config.
>>> 
>>> I think the simplest thing here is to put the KConfig back to:
>>>
>>>   depends on TCG && AARCH64
>>> 
>>> People building a KVM-only config almost certainly do not
>>> want this machine type and its devices, because the main
>>> reason to build KVM-only is because you're in the
>>> "virtualization use case" and want to not build in a
>>> load of not-security-supported machine types.
>> 
>> Do we need this treatment for further machines, e.g. isapc, e500, mips? Or 
>> shall the CPU type handling in the SoC consider kvm_enabled()?
>
> Good point. My understanding is only virt x86/arm/ppc64/s390x are
> "security covered", but there is no explicit mention of that in
> our doc. (btw why not include isapc? as it is a subset of other
> covered x86 machines?)

Maybe because you can't run isapc with KVM because it's limited to Pentium 
but 32bit host support is removed? Or should we keep the ability to run it 
with newer CPUs for KVM?

Regards,
BALATON Zoltan

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

[Daniel P. Berrangé]

On Tue, Nov 18, 2025 at 01:25:23PM +0100, BALATON Zoltan wrote:
> On Tue, 18 Nov 2025, Philippe Mathieu-Daudé wrote:
> > On 18/11/25 10:49, Bernhard Beschow wrote:
> > > Am 17. November 2025 17:38:03 UTC schrieb Peter Maydell
> > > <peter.maydell@linaro.org>:
> > > > On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
> > > > > Running current master (resp. with this patch applied), I'm getting make
> > > > > check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
> > > > > unknown type 'arm-gicv3'" while using this machine); going back right
> > > > > before this patch, everything works fine. Haven't tried to debug this
> > > > > yet (maybe I'm the one with the weird config again...)
> > > > 
> > > > Is this a KVM-only config (no TCG) ?
> > > > 
> > > > I think this happens because the KConfig now says
> > > > +    depends on TCG || KVM
> > > > 
> > > > but because the machine by default doesn't use KVM then
> > > > trying to run the machine with no extra arguments falls
> > > > over if TCG isn't present.
> > > > 
> > > > This thing we put in to handle "creation of the SoC object
> > > > via device introspection means it doesn't have an ms->cpu_type
> > > > to look at":
> > > > 
> > > > +    const char *cpu_type = ms->cpu_type ?:
> > > > ARM_CPU_TYPE_NAME("cortex-a53");
> > > > 
> > > > also probably won't do anything useful under a KVM-only config.
> > > > 
> > > > I think the simplest thing here is to put the KConfig back to:
> > > > 
> > > >   depends on TCG && AARCH64
> > > > 
> > > > People building a KVM-only config almost certainly do not
> > > > want this machine type and its devices, because the main
> > > > reason to build KVM-only is because you're in the
> > > > "virtualization use case" and want to not build in a
> > > > load of not-security-supported machine types.
> > > 
> > > Do we need this treatment for further machines, e.g. isapc, e500,
> > > mips? Or shall the CPU type handling in the SoC consider
> > > kvm_enabled()?
> > 
> > Good point. My understanding is only virt x86/arm/ppc64/s390x are
> > "security covered", but there is no explicit mention of that in
> > our doc. (btw why not include isapc? as it is a subset of other
> > covered x86 machines?)
> 
> Maybe because you can't run isapc with KVM because it's limited to Pentium
> but 32bit host support is removed? Or should we keep the ability to run it
> with newer CPUs for KVM?

32-bit host support removal is irrelevant. We still fully support 32-bit
guests, and they can use KVM. It is upto the user to disable the LM CPU
flag if they wish to, though it shouldn't matter because if the OS running
on isapc is that old it'll not even look for the "LM" flag to begin with,
and so the CPU will never get switchd into 64-bit mode. 

Note, a run of ./configure' with TCG disabled only is NOT claiming to be
providing a minimal virtualization build. It is simply discarding TCG.

If people want a minimal build, they're expected to customize the
KConfig files to suit their needs.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Bernhard Beschow]

Am 18. November 2025 11:24:44 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>On 18/11/25 10:49, Bernhard Beschow wrote:
>> 
>> 
>> Am 17. November 2025 17:38:03 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>>> On Mon, 17 Nov 2025 at 17:13, Cornelia Huck <cohuck@redhat.com> wrote:
>>>> Running current master (resp. with this patch applied), I'm getting make
>>>> check failures on an aarch64 (Mt. Snow) host ("qemu-system-aarch64:
>>>> unknown type 'arm-gicv3'" while using this machine); going back right
>>>> before this patch, everything works fine. Haven't tried to debug this
>>>> yet (maybe I'm the one with the weird config again...)
>>> 
>>> Is this a KVM-only config (no TCG) ?
>>> 
>>> I think this happens because the KConfig now says
>>> +    depends on TCG || KVM
>>> 
>>> but because the machine by default doesn't use KVM then
>>> trying to run the machine with no extra arguments falls
>>> over if TCG isn't present.
>>> 
>>> This thing we put in to handle "creation of the SoC object
>>> via device introspection means it doesn't have an ms->cpu_type
>>> to look at":
>>> 
>>> +    const char *cpu_type = ms->cpu_type ?: ARM_CPU_TYPE_NAME("cortex-a53");
>>> 
>>> also probably won't do anything useful under a KVM-only config.
>>> 
>>> I think the simplest thing here is to put the KConfig back to:
>>> 
>>>   depends on TCG && AARCH64
>>> 
>>> People building a KVM-only config almost certainly do not
>>> want this machine type and its devices, because the main
>>> reason to build KVM-only is because you're in the
>>> "virtualization use case" and want to not build in a
>>> load of not-security-supported machine types.
>> 
>> Do we need this treatment for further machines, e.g. isapc, e500, mips? Or shall the CPU type handling in the SoC consider kvm_enabled()?
>
>Good point. My understanding is only virt x86/arm/ppc64/s390x are
>"security covered", but there is no explicit mention of that in
>our doc. (btw why not include isapc? as it is a subset of other
>covered x86 machines?)

Hi Phil,

Peter merged the updated security policy which enumerates all "security covered" machines (sorry, don't have a link right now).

Since the policy change was about decoupling of acceleration/virtualization technologies from use cases, I'd actually prefer the imx8 machine(s) to be enabled in a KVM-only configuration. For 10.2 I'd go for "depends on TCG && AARCH64" for simplicity. Will send a patch later.

Best regards,
Bernhard