Am 28. Oktober 2025 16:09:50 UTC schrieb Peter Maydell 
<[email protected]>:
>On Tue, 28 Oct 2025 at 14:41, Bernhard Beschow <[email protected]> wrote:
>>
>>
>>
>> Am 28. Oktober 2025 12:46:34 UTC schrieb Peter Maydell 
>> <[email protected]>:
>> >On Sun, 29 Jun 2025 at 21:49, Bernhard Beschow <[email protected]> wrote:
>> >>
>> >> Allows the imx8mp-evk machine to be run with KVM acceleration as a guest.
>> >>
>> >> Signed-off-by: Bernhard Beschow <[email protected]>
>> >> ---
>> >>  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

Reply via email to