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

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

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

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.

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.

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

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

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

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

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