aboutsummaryrefslogtreecommitdiff
path: root/target-i386/cc_helper.c
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2016-03-04 11:30:18 +0000
committerPeter Maydell <peter.maydell@linaro.org>2016-03-04 11:30:18 +0000
commit4824a61a6dc1ce768be5c0a81f16224618104a63 (patch)
tree8b261cfe1d00af3b795a0a4eefb27a7f6cda2a38 /target-i386/cc_helper.c
parent738a5d9fbbd242b4a16cd1837fd3ded610ef1b43 (diff)
downloadqemu-4824a61a6dc1ce768be5c0a81f16224618104a63.zip
qemu-4824a61a6dc1ce768be5c0a81f16224618104a63.tar.gz
qemu-4824a61a6dc1ce768be5c0a81f16224618104a63.tar.bz2
hw/arm/virt: Assume EL3 boot rom will handle PSCI if one is provided
If the user passes us an EL3 boot rom, then it is going to want to implement the PSCI interface itself. In this case, disable QEMU's internal PSCI implementation so it does not get in the way, and instead start all CPUs in an SMP configuration at once (the boot rom will catch them all and pen up the secondaries until needed). The boot rom code is also responsible for editing the device tree to include any necessary information about its own PSCI implementation before eventually passing it to a NonSecure guest. (This "start all CPUs at once" approach is what both ARM Trusted Firmware and UEFI expect, since it is what the ARM Foundation Model does; the other approach would be to provide some emulated hardware for "start the secondaries" but this is simplest.) This is a compatibility break, but I don't believe that anybody was using a secure boot ROM with an SMP configuration. Such a setup would be somewhat broken since there was nothing preventing nonsecure guest code from calling the QEMU PSCI function to start up a secondary core in a way that completely bypassed the secure world. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1456853976-7592-1-git-send-email-peter.maydell@linaro.org
Diffstat (limited to 'target-i386/cc_helper.c')
0 files changed, 0 insertions, 0 deletions