[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] hw/arm/virt: use sbsa-ec for reboot and poweroff in secu
Re: [RFC PATCH] hw/arm/virt: use sbsa-ec for reboot and poweroff in secure mode
Wed, 28 Oct 2020 20:31:41 +0000
On Wed, 28 Oct 2020 at 08:59, Maxim Uvarov <email@example.com> wrote:
> If we're emulating EL3 then the EL3 guest firmware is responsible for
> providing the PSCI ABI, including reboot, core power down, etc.
> sbsa-ref machine has an embedded controller to do reboot, poweroff. Machine
> virt,secure=on can reuse this code to do reboot inside ATF.
> Signed-off-by: Maxim Uvarov <firstname.lastname@example.org>
(I've cc'd the sbsa-ref machine maintainers.)
> This patch implements reboot for the secure machine inside ATF firmware.
> I.e. current qemu
> patch should be used with  ATF patch. It looks like that Embedded
> Controller qemu
> driver (sbsa-ec) can be common and widely used for other emulated machines.
> While if
> there are plans to extend sbsa-ec then we might find some other solution.
> So for the long term it looks like machine virt was used as an initial
> playground for secure
> firmware. While the original intent was a runner for kvm guests. Relation
> between kvm guest
> and firmware is not very clear now. If everyone agree it might be good
> solution to move secure
> firmware things from virt machine to bsa-ref and make this machine reference
> for secure boot,
> firmware updates etc.
Thanks for this patch. It is definitely a missing
bit of functionality that we intend to allow virt to run
EL3 guest code but don't provide a trigger-shutdown/reboot
device that works in that setup.
I think the key question here is whether we want to implement
(1) providing the sbsa-ec device in the virt board
(2) some other mechanism, eg a secure-only pl061 GPIO
some of whose output pins can trigger shutdown or reboot
The sbsa-ec device has the advantage of doing the
shutdown/reboot functionality at the moment. The question
I have for the sbsa-ref board folks is: what are your future
plans for that device? If the idea is that it's going to end
up stuffed full of sbsa-ref specific functionality that we
wouldn't want to try to expose in the virt board, then we
should probably go with the pl061 approach instead. But if
it's not likely to grow new functionality then it might be
A couple of notes on this patch if we do go down that route:
* we would need to arrange to only add the new device for
new versions of the virt board (that is, the "virt-5.0"
machine must not have this device because it must look
like the version of "virt" that shipped with QEMU 5.0)
* the device needs to be mapped into the Secure address
space only, because Secure firmware wants control over
it and doesn't want to allow NS code to reboot the system
without asking the firmware
* it would need to be described in the DTB (and maybe also
ACPI tables? I forget whether we need to describe Secure-only
But let's find out if that's the route we want to take first.