hw/arm/virt: Assume EL3 boot rom will handle PSCI if one is provided
commit4824a61a6dc1ce768be5c0a81f16224618104a63
authorPeter Maydell <peter.maydell@linaro.org>
Fri, 4 Mar 2016 11:30:18 +0000 (4 11:30 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Fri, 4 Mar 2016 11:30:18 +0000 (4 11:30 +0000)
tree8b261cfe1d00af3b795a0a4eefb27a7f6cda2a38
parent738a5d9fbbd242b4a16cd1837fd3ded610ef1b43
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
hw/arm/virt.c