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

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(-)
>
> 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.

Coming back to this now we've resolved the "does this put
things inside our security-promises that we don't want"
question...

I think we should be a bit clearer in the documentation
about what tradeoffs the user is making here when they select
KVM. Specifically:

 * we should note that this is intended only to improve
   performance, and is not covered by QEMU's security policy
 * we should say that you will not get a Cortex-A53, so any
   guest code with tight dependencies on the host CPU type
   might not work correctly
 * we should say that the guest will only be able to run
   at EL1, and (unlike TCG) there is no EL2 or EL3

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

Why does this include get removed ?

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

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

Philippe, Pierrick: is it OK that this moves the
fsl-imx8p.c file from arm_common to arm_ss, or is there
a preferable way to do this from a single-binary point
of view?

thanks
-- PMM

Am 28. Oktober 2025 12:46:34 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(-)
>>
>> 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.
>
>Coming back to this now we've resolved the "does this put
>things inside our security-promises that we don't want"
>question...
>
>I think we should be a bit clearer in the documentation
>about what tradeoffs the user is making here when they select
>KVM. Specifically:
>
> * we should note that this is intended only to improve
>   performance, and is not covered by QEMU's security policy

Sure, I'll add it.

> * we should say that you will not get a Cortex-A53, so any
>   guest code with tight dependencies on the host CPU type
>   might not work correctly

Ack. I'd also hardcode the CPU type to host since asking for a Cortex-A53 always failed on me with KVM.

> * we should say that the guest will only be able to run
>   at EL1, and (unlike TCG) there is no EL2 or EL3

Real U-Boot calls back into the on-chip ROM which isn't implemented yet. Furthermore, there are some unimplemented USDHC extensions which prevent complete loading of binaries into RAM by U-Boot (similar limitation exists for e500 boards). Therefore the board documentation only advertises direct kernel boot. AFAIU EL2 and EL3 aren't usable there anyway. Correct? Do we need to mention this limitation regardless?

>
>> 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"
>
>Why does this include get removed ?

It was used for accessing `TYPE_ARM_GICV3` which has been replaced by `gicv3_class_name()` whose header is included in fsl-imx8mp.h already.

>
>>  #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"
>
>> 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'))
>
>Philippe, Pierrick: is it OK that this moves the
>fsl-imx8p.c file from arm_common to arm_ss, or is there
>a preferable way to do this from a single-binary point
>of view?

Hardcoding to host CPU type in the KVM case might also resolve this issue.

Thanks,
Bernhard

>
>thanks
>-- PMM

On Tue, 28 Oct 2025 at 14:41, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 28. Oktober 2025 12:46:34 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(-)
> >>
> >> 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.
> >
> >Coming back to this now we've resolved the "does this put
> >things inside our security-promises that we don't want"
> >question...
> >
> >I think we should be a bit clearer in the documentation
> >about what tradeoffs the user is making here when they select
> >KVM. Specifically:
> >
> > * we should note that this is intended only to improve
> >   performance, and is not covered by QEMU's security policy
>
> Sure, I'll add it.
>
> > * we should say that you will not get a Cortex-A53, so any
> >   guest code with tight dependencies on the host CPU type
> >   might not work correctly
>
> Ack. I'd also hardcode the CPU type to host since asking for a Cortex-A53 always failed on me with KVM.

Yes, this is the right thing (at least until some distant
day when we add support for having KVM give the guest a vcpu
that looks like a particular cpu type). The 'cortex-a53'
cpu type with KVM will only work if the host happens to be
that, which isn't very useful for most people.

> > * we should say that the guest will only be able to run
> >   at EL1, and (unlike TCG) there is no EL2 or EL3
>
> Real U-Boot calls back into the on-chip ROM which isn't implemented yet. Furthermore, there are some unimplemented USDHC extensions which prevent complete loading of binaries into RAM by U-Boot (similar limitation exists for e500 boards). Therefore the board documentation only advertises direct kernel boot. AFAIU EL2 and EL3 aren't usable there anyway. Correct? Do we need to mention this limitation regardless?

I think it's worth mentioning anyway -- not every EL3
payload is necessarily u-boot.

thanks
-- PMM

Am 28. Oktober 2025 16:09:50 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Tue, 28 Oct 2025 at 14:41, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>>
>>
>> Am 28. Oktober 2025 12:46:34 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(-)
>> >>
>> >> 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.
>> >
>> >Coming back to this now we've resolved the "does this put
>> >things inside our security-promises that we don't want"
>> >question...
>> >
>> >I think we should be a bit clearer in the documentation
>> >about what tradeoffs the user is making here when they select
>> >KVM. Specifically:
>> >
>> > * we should note that this is intended only to improve
>> >   performance, and is not covered by QEMU's security policy
>>
>> Sure, I'll add it.
>>
>> > * we should say that you will not get a Cortex-A53, so any
>> >   guest code with tight dependencies on the host CPU type
>> >   might not work correctly
>>
>> Ack. I'd also hardcode the CPU type to host since asking for a Cortex-A53 always failed on me with KVM.
>
>Yes, this is the right thing (at least until some distant
>day when we add support for having KVM give the guest a vcpu
>that looks like a particular cpu type). The 'cortex-a53'
>cpu type with KVM will only work if the host happens to be
>that, which isn't very useful for most people.
>
>> > * we should say that the guest will only be able to run
>> >   at EL1, and (unlike TCG) there is no EL2 or EL3
>>
>> Real U-Boot calls back into the on-chip ROM which isn't implemented yet. Furthermore, there are some unimplemented USDHC extensions which prevent complete loading of binaries into RAM by U-Boot (similar limitation exists for e500 boards). Therefore the board documentation only advertises direct kernel boot. AFAIU EL2 and EL3 aren't usable there anyway. Correct? Do we need to mention this limitation regardless?
>
>I think it's worth mentioning anyway -- not every EL3
>payload is necessarily u-boot.

Thanks for.the feedback! Version 2 is out.

Best regards,
Bernhard

>
>thanks
>-- PMM

On 2025-10-28 13:46, Peter Maydell wrote:
> 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(-)
>>
>> 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.
> 
> Coming back to this now we've resolved the "does this put
> things inside our security-promises that we don't want"
> question...
> 
> I think we should be a bit clearer in the documentation
> about what tradeoffs the user is making here when they select
> KVM. Specifically:
> 
>   * we should note that this is intended only to improve
>     performance, and is not covered by QEMU's security policy
>   * we should say that you will not get a Cortex-A53, so any
>     guest code with tight dependencies on the host CPU type
>     might not work correctly
>   * we should say that the guest will only be able to run
>     at EL1, and (unlike TCG) there is no EL2 or EL3
> 
>> 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"
> 
> Why does this include get removed ?
> 
>>   #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"
> 
>> 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'))
> 
> Philippe, Pierrick: is it OK that this moves the
> fsl-imx8p.c file from arm_common to arm_ss, or is there
> a preferable way to do this from a single-binary point
> of view?
>

Looking at original patch, this is needed because an ifdef CONFIG_KVM is 
introduced.

  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
+    };
+

This is not needed, and valid_cpu_types array can be dynamically 
created, adding "host" only if kvm_enabled().

See this patch for reference:
https://lore.kernel.org/qemu-devel/20251021210144.58108-4-philmd@linaro.org/

> thanks
> -- PMM

Pierrick

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

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

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

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

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

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

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

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

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
> +    };

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
>> +    };
>