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

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

[Bernhard Beschow]

This series adds KVM support to the imx8mp-evk machine, both as a guest and as a
KVM host. Turning imx8mp-evk into a KVM host just required wiring up two
interrupts (patch 1) while implementing `-accel kvm` required more work, drawing
inspiration from the virt machine (patch 2).

Testing done:
* Run `qemu-system-aarch64 -M virt -accel kvm -cpu host" and
  `qemu-system-aarch64 -M imx8mp-evk -accel kvm -cpu host -smp 4` under
  `qemu-system-aarch64 -M imx8mp-evk -accel tcg -smp 4`
* Run `qemu-system-aarch64 -M imx8mp-evk -accel kvm -cpu host -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"

Bernhard Beschow (2):
  hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ
  hw/arm/imx8mp-evk: Add KVM support

 docs/system/arm/imx8mp-evk.rst |  7 +++++++
 hw/arm/fsl-imx8mp.c            | 37 +++++++++++++++++++++++++++++-----
 hw/arm/imx8mp-evk.c            | 11 ++++++++++
 hw/arm/Kconfig                 |  3 ++-
 hw/arm/meson.build             |  2 +-
 5 files changed, 53 insertions(+), 7 deletions(-)

-- 
2.50.0

[PATCH 1/2] hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ

[Bernhard Beschow]

Allows to run KVM guests inside the imx8mp-evk machine.

Fixes: a4eefc69b237 ("hw/arm: Add i.MX 8M Plus EVK board")
CC: qemu-stable
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 hw/arm/fsl-imx8mp.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/arm/fsl-imx8mp.c b/hw/arm/fsl-imx8mp.c
index 23e662c16c..866f4d1d74 100644
--- a/hw/arm/fsl-imx8mp.c
+++ b/hw/arm/fsl-imx8mp.c
@@ -356,6 +356,10 @@ static void fsl_imx8mp_realize(DeviceState *dev, Error **errp)
                                qdev_get_gpio_in(cpudev, ARM_CPU_IRQ));
             sysbus_connect_irq(gicsbd, i + ms->smp.cpus,
                                qdev_get_gpio_in(cpudev, ARM_CPU_FIQ));
+            sysbus_connect_irq(gicsbd, i + 2 * ms->smp.cpus,
+                               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));
         }
     }
 
-- 
2.50.0

Re: [PATCH 1/2] hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ

[Philippe Mathieu-Daudé]

On 29/6/25 22:48, Bernhard Beschow wrote:
> Allows to run KVM guests inside the imx8mp-evk machine.
> 
> Fixes: a4eefc69b237 ("hw/arm: Add i.MX 8M Plus EVK board")
> CC: qemu-stable
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
>   hw/arm/fsl-imx8mp.c | 4 ++++
>   1 file changed, 4 insertions(+)

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

Re: [PATCH 1/2] hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ

[Bernhard Beschow]

Am 30. Juni 2025 08:59:22 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>On 29/6/25 22:48, Bernhard Beschow wrote:
>> Allows to run KVM guests inside the imx8mp-evk machine.
>> 
>> Fixes: a4eefc69b237 ("hw/arm: Add i.MX 8M Plus EVK board")
>> CC: qemu-stable
>> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> ---
>>   hw/arm/fsl-imx8mp.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>
>Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Ping

This patch doesn't shift the security boundary and is already reviewed.

Best regards,
Bernhard

Re: [PATCH 1/2] hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ

[Peter Maydell]

On Tue, 8 Jul 2025 at 23:29, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 30. Juni 2025 08:59:22 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
> >On 29/6/25 22:48, Bernhard Beschow wrote:
> >> Allows to run KVM guests inside the imx8mp-evk machine.
> >>
> >> Fixes: a4eefc69b237 ("hw/arm: Add i.MX 8M Plus EVK board")
> >> CC: qemu-stable
> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> >> ---
> >>   hw/arm/fsl-imx8mp.c | 4 ++++
> >>   1 file changed, 4 insertions(+)
> >
> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
> Ping
>
> This patch doesn't shift the security boundary and is already reviewed.

Thanks for the ping -- I've applied this patch to target-arm.next.

-- PMM

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

[Bernhard Beschow]

Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.

Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
 docs/system/arm/imx8mp-evk.rst |  7 +++++++
 hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
 hw/arm/imx8mp-evk.c            | 11 +++++++++++
 hw/arm/Kconfig                 |  3 ++-
 hw/arm/meson.build             |  2 +-
 5 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/docs/system/arm/imx8mp-evk.rst b/docs/system/arm/imx8mp-evk.rst
index b2f7d29ade..1399820163 100644
--- a/docs/system/arm/imx8mp-evk.rst
+++ b/docs/system/arm/imx8mp-evk.rst
@@ -60,3 +60,10 @@ 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 Virtualization
+------------------
+
+To enable hardware-assisted acceleration via KVM, append
+``-accel kvm -cpu host`` to the command line.
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..30eb57318d 100644
--- a/hw/arm/imx8mp-evk.c
+++ b/hw/arm/imx8mp-evk.c
@@ -95,9 +95,20 @@ static void imx8mp_evk_init(MachineState *machine)
 
 static void imx8mp_evk_machine_init(MachineClass *mc)
 {
+    static const char *const valid_cpu_types[] = {
+        ARM_CPU_TYPE_NAME("cortex-a53"),
+#ifdef CONFIG_KVM
+        ARM_CPU_TYPE_NAME("host"),
+#endif /* CONFIG_KVM */
+        NULL
+    };
+
     mc->desc = "NXP i.MX 8M Plus EVK Board";
     mc->init = imx8mp_evk_init;
     mc->max_cpus = FSL_IMX8MP_NUM_CPUS;
+    mc->valid_cpu_types = valid_cpu_types;
+    mc->default_cpu_type = mc->valid_cpu_types[0];
     mc->default_ram_id = "imx8mp-evk.ram";
 }
+
 DEFINE_MACHINE("imx8mp-evk", imx8mp_evk_machine_init)
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index f543d944c3..d35f41331f 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -604,7 +604,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
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index d90be8f4c9..a4212a6ab2 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -59,7 +59,7 @@ arm_common_ss.add(when: 'CONFIG_MUSCA', if_true: files('musca.c'))
 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_EVK', if_true: files('imx8mp-evk.c'))
 arm_common_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmuv3.c'))
 arm_common_ss.add(when: 'CONFIG_FSL_IMX6UL', if_true: files('fsl-imx6ul.c', 'mcimx6ul-evk.c'))
 arm_common_ss.add(when: 'CONFIG_NRF51_SOC', if_true: files('nrf51_soc.c'))
-- 
2.50.0

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

[Philippe Mathieu-Daudé]

Hi,

On 29/6/25 22:48, Bernhard Beschow wrote:
> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
> 
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
>   docs/system/arm/imx8mp-evk.rst |  7 +++++++
>   hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>   hw/arm/imx8mp-evk.c            | 11 +++++++++++
>   hw/arm/Kconfig                 |  3 ++-
>   hw/arm/meson.build             |  2 +-
>   5 files changed, 49 insertions(+), 7 deletions(-)


> diff --git a/hw/arm/imx8mp-evk.c b/hw/arm/imx8mp-evk.c
> index b3082fa60d..30eb57318d 100644
> --- a/hw/arm/imx8mp-evk.c
> +++ b/hw/arm/imx8mp-evk.c
> @@ -95,9 +95,20 @@ static void imx8mp_evk_init(MachineState *machine)
>   
>   static void imx8mp_evk_machine_init(MachineClass *mc)
>   {
> +    static const char *const valid_cpu_types[] = {
> +        ARM_CPU_TYPE_NAME("cortex-a53"),
> +#ifdef CONFIG_KVM
> +        ARM_CPU_TYPE_NAME("host"),

IMO 'host' should be kept for 'virt' machines where we want the cpu
type with the maximum features possible.

For this case where a real SoC is virtualized with KVM, I'd keep the
SoC CPU type. If the host misses Cortex-A53 features, KVM will fail,
otherwise it will disable the extra features and only expose a A53
to the guest.

> +#endif /* CONFIG_KVM */
> +        NULL
> +    };

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

[Bernhard Beschow]

Am 30. Juni 2025 08:58:22 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>Hi,
>
>On 29/6/25 22:48, Bernhard Beschow wrote:
>> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>> 
>> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> ---
>>   docs/system/arm/imx8mp-evk.rst |  7 +++++++
>>   hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>>   hw/arm/imx8mp-evk.c            | 11 +++++++++++
>>   hw/arm/Kconfig                 |  3 ++-
>>   hw/arm/meson.build             |  2 +-
>>   5 files changed, 49 insertions(+), 7 deletions(-)
>
>
>> diff --git a/hw/arm/imx8mp-evk.c b/hw/arm/imx8mp-evk.c
>> index b3082fa60d..30eb57318d 100644
>> --- a/hw/arm/imx8mp-evk.c
>> +++ b/hw/arm/imx8mp-evk.c
>> @@ -95,9 +95,20 @@ static void imx8mp_evk_init(MachineState *machine)
>>     static void imx8mp_evk_machine_init(MachineClass *mc)
>>   {
>> +    static const char *const valid_cpu_types[] = {
>> +        ARM_CPU_TYPE_NAME("cortex-a53"),
>> +#ifdef CONFIG_KVM
>> +        ARM_CPU_TYPE_NAME("host"),
>
>IMO 'host' should be kept for 'virt' machines where we want the cpu
>type with the maximum features possible.
>
>For this case where a real SoC is virtualized with KVM, I'd keep the
>SoC CPU type. If the host misses Cortex-A53 features, KVM will fail,
>otherwise it will disable the extra features and only expose a A53
>to the guest.

I tried `-cpu cortex-a53` inside the `-M virt -cpu cortex-a72` machine and this resulted in an illegal argument. This happened even though the virt machine was using the 6.15.3 kernel which is pretty much the latest. Given that this very recent setup didn't work I added the 'host' CPU option as a fallback while cortex-a53 is of course the default. What about adjusting the DTB with ARMCPU::dtb_compatible?

Best regards,
Bernhard

>
>> +#endif /* CONFIG_KVM */
>> +        NULL
>> +    };
>

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

[Peter Maydell]

On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>
> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>
> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> ---
>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>  hw/arm/Kconfig                 |  3 ++-
>  hw/arm/meson.build             |  2 +-
>  5 files changed, 49 insertions(+), 7 deletions(-)

This puts a lot of IMX device models onto our security boundary,
which makes me a bit nervous -- that's a lot of code which
wasn't really written or reviewed carefully to ensure it
can't be exploited by a malicious guest.

-- PMM

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

[Bernhard Beschow]

Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>>
>> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> ---
>>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>>  hw/arm/Kconfig                 |  3 ++-
>>  hw/arm/meson.build             |  2 +-
>>  5 files changed, 49 insertions(+), 7 deletions(-)
>
>This puts a lot of IMX device models onto our security boundary,
>which makes me a bit nervous -- that's a lot of code which
>wasn't really written or reviewed carefully to ensure it
>can't be exploited by a malicious guest.

Hi Peter,

Does KVM increase the attack surface compared to TCG? Is there anything I could read to better understand the problem, both in technical and in policy terms? Since the i.MX 8M Plus has pretty capable CPUs it would be really to have KVM acceleration.

Thanks,
Bernhard

>
>-- PMM

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

[Peter Maydell]

On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
> >>
> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
> >>
> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> >> ---
> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
> >>  hw/arm/Kconfig                 |  3 ++-
> >>  hw/arm/meson.build             |  2 +-
> >>  5 files changed, 49 insertions(+), 7 deletions(-)
> >
> >This puts a lot of IMX device models onto our security boundary,
> >which makes me a bit nervous -- that's a lot of code which
> >wasn't really written or reviewed carefully to ensure it
> >can't be exploited by a malicious guest.
>
> Hi Peter,
>
> Does KVM increase the attack surface compared to TCG?

Yes, because our security policy says that TCG is not considered
a security boundary, whereas KVM is:

https://qemu-project.gitlab.io/qemu/system/security.html

(It would move from "non-virtualization use case" to
"virtualization use case".)

thanks
-- PMM

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

[Bernhard Beschow]

Am 30. Juni 2025 21:03:06 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>>
>>
>> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>> >>
>> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>> >>
>> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> >> ---
>> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>> >>  hw/arm/Kconfig                 |  3 ++-
>> >>  hw/arm/meson.build             |  2 +-
>> >>  5 files changed, 49 insertions(+), 7 deletions(-)
>> >
>> >This puts a lot of IMX device models onto our security boundary,
>> >which makes me a bit nervous -- that's a lot of code which
>> >wasn't really written or reviewed carefully to ensure it
>> >can't be exploited by a malicious guest.
>>
>> Hi Peter,
>>
>> Does KVM increase the attack surface compared to TCG?
>
>Yes, because our security policy says that TCG is not considered
>a security boundary, whereas KVM is:
>
>https://qemu-project.gitlab.io/qemu/system/security.html
>
>(It would move from "non-virtualization use case" to
>"virtualization use case".)

Thanks, that document nails my question.

If KVM requires the imx devices to be inside the security boundary, what needs to be done to lift them there?

Best regards,
Bernhard

>
>thanks
>-- PMM

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

[Bernhard Beschow]

Am 8. Juli 2025 16:36:03 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>
>
>Am 30. Juni 2025 21:03:06 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>>On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
>>>
>>>
>>>
>>> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>>> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>>> >>
>>> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>>> >>
>>> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>>> >> ---
>>> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>>> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>>> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>>> >>  hw/arm/Kconfig                 |  3 ++-
>>> >>  hw/arm/meson.build             |  2 +-
>>> >>  5 files changed, 49 insertions(+), 7 deletions(-)
>>> >
>>> >This puts a lot of IMX device models onto our security boundary,
>>> >which makes me a bit nervous -- that's a lot of code which
>>> >wasn't really written or reviewed carefully to ensure it
>>> >can't be exploited by a malicious guest.
>>>
>>> Hi Peter,
>>>
>>> Does KVM increase the attack surface compared to TCG?
>>
>>Yes, because our security policy says that TCG is not considered
>>a security boundary, whereas KVM is:
>>
>>https://qemu-project.gitlab.io/qemu/system/security.html
>>
>>(It would move from "non-virtualization use case" to
>>"virtualization use case".)
>
>Thanks, that document nails my question.
>
>If KVM requires the imx devices to be inside the security boundary, what needs to be done to lift them there?

Ping

>
>Best regards,
>Bernhard
>
>>
>>thanks
>>-- PMM

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

[Bernhard Beschow]

Am 11. August 2025 11:01:53 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>
>
>Am 8. Juli 2025 16:36:03 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>>
>>
>>Am 30. Juni 2025 21:03:06 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>>>On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>>>> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>>>> >>
>>>> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>>>> >>
>>>> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>>>> >> ---
>>>> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>>>> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>>>> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>>>> >>  hw/arm/Kconfig                 |  3 ++-
>>>> >>  hw/arm/meson.build             |  2 +-
>>>> >>  5 files changed, 49 insertions(+), 7 deletions(-)
>>>> >
>>>> >This puts a lot of IMX device models onto our security boundary,
>>>> >which makes me a bit nervous -- that's a lot of code which
>>>> >wasn't really written or reviewed carefully to ensure it
>>>> >can't be exploited by a malicious guest.
>>>>
>>>> Hi Peter,
>>>>
>>>> Does KVM increase the attack surface compared to TCG?
>>>
>>>Yes, because our security policy says that TCG is not considered
>>>a security boundary, whereas KVM is:
>>>
>>>https://qemu-project.gitlab.io/qemu/system/security.html
>>>
>>>(It would move from "non-virtualization use case" to
>>>"virtualization use case".)
>>
>>Thanks, that document nails my question.
>>
>>If KVM requires the imx devices to be inside the security boundary, what needs to be done to lift them there?
>
>Ping

Ping^2

>
>>
>>Best regards,
>>Bernhard
>>
>>>
>>>thanks
>>>-- PMM

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

[Peter Maydell]

On Tue, 8 Jul 2025 at 17:36, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 30. Juni 2025 21:03:06 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
> >>
> >>
> >>
> >> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
> >> >>
> >> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
> >> >>
> >> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
> >> >> ---
> >> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
> >> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
> >> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
> >> >>  hw/arm/Kconfig                 |  3 ++-
> >> >>  hw/arm/meson.build             |  2 +-
> >> >>  5 files changed, 49 insertions(+), 7 deletions(-)
> >> >
> >> >This puts a lot of IMX device models onto our security boundary,
> >> >which makes me a bit nervous -- that's a lot of code which
> >> >wasn't really written or reviewed carefully to ensure it
> >> >can't be exploited by a malicious guest.
> >>
> >> Hi Peter,
> >>
> >> Does KVM increase the attack surface compared to TCG?
> >
> >Yes, because our security policy says that TCG is not considered
> >a security boundary, whereas KVM is:
> >
> >https://qemu-project.gitlab.io/qemu/system/security.html
> >
> >(It would move from "non-virtualization use case" to
> >"virtualization use case".)
>
> Thanks, that document nails my question.
>
> If KVM requires the imx devices to be inside the security boundary, what needs to be done to lift them there?

Code audit, fuzzing, commitments to maintenance. Basically
I would strongly prefer not to.

-- PMM

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

[Bernhard Beschow]

Am 26. August 2025 09:21:25 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Tue, 8 Jul 2025 at 17:36, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>>
>>
>> Am 30. Juni 2025 21:03:06 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> >On Mon, 30 Jun 2025 at 21:22, Bernhard Beschow <shentey@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> Am 30. Juni 2025 09:09:31 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> >> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <shentey@gmail.com> wrote:
>> >> >>
>> >> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>> >> >>
>> >> >> Signed-off-by: Bernhard Beschow <shentey@gmail.com>
>> >> >> ---
>> >> >>  docs/system/arm/imx8mp-evk.rst |  7 +++++++
>> >> >>  hw/arm/fsl-imx8mp.c            | 33 ++++++++++++++++++++++++++++-----
>> >> >>  hw/arm/imx8mp-evk.c            | 11 +++++++++++
>> >> >>  hw/arm/Kconfig                 |  3 ++-
>> >> >>  hw/arm/meson.build             |  2 +-
>> >> >>  5 files changed, 49 insertions(+), 7 deletions(-)
>> >> >
>> >> >This puts a lot of IMX device models onto our security boundary,
>> >> >which makes me a bit nervous -- that's a lot of code which
>> >> >wasn't really written or reviewed carefully to ensure it
>> >> >can't be exploited by a malicious guest.
>> >>
>> >> Hi Peter,
>> >>
>> >> Does KVM increase the attack surface compared to TCG?
>> >
>> >Yes, because our security policy says that TCG is not considered
>> >a security boundary, whereas KVM is:
>> >
>> >https://qemu-project.gitlab.io/qemu/system/security.html
>> >
>> >(It would move from "non-virtualization use case" to
>> >"virtualization use case".)
>>
>> Thanks, that document nails my question.
>>
>> If KVM requires the imx devices to be inside the security boundary, what needs to be done to lift them there?
>
>Code audit, fuzzing, commitments to maintenance. Basically
>I would strongly prefer not to.

I agree that this is asking for a bit too much, especially volunteers. These requirements also seem very related to maintenance status "supported". Can we find a way for lowering the bar for KVM support?

Best regards,
Bernhard

>
>-- PMM