On Mon, 2 Nov 2020 at 16:53, Graeme Gregory graeme@nuviainc.com wrote:
On Thu, Oct 29, 2020 at 11:19:39AM +0000, Leif Lindholm wrote:
Hi Peter, (+Ard)
Graeme is on holiday this week, and I would like his input.
On Wed, Oct 28, 2020 at 20:31:41 +0000, Peter Maydell wrote:
On Wed, 28 Oct 2020 at 08:59, Maxim Uvarov maxim.uvarov@linaro.org 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 maxim.uvarov@linaro.org
(I've cc'd the sbsa-ref machine maintainers.)
Hello,
This patch implements reboot for the secure machine inside ATF firmware. I.e. current qemu patch should be used with [1] 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.
[1] https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d99...
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 this by: (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 simpler...
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
devices there)
Would it? Could it be something that goes into the virt spec? We don't consume ACPI in firmware (but TF-A will of course have access to the DT regardless).
For sbsa-ref, I would ideally like to move to emulating communicating with an SCP over time, as opposed to TF-A directly controlling the EC. I am unsure if that leaves much opportunity for code sharing with virt.
I would agree that would be the ideal end point for the sbsa-ref.
I am now kicking myself that the GPIO style solution did not occur to me.
I do see the EC device being a stopgap until a proper comms protocol can be implemented to replace it.
Graeme
Thanks. Is there anything I need to do with this RFC patch or it can be accepted as is?
Maxim.