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