[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
Thu, 29 Oct 2020 11:19:39 +0000
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 <firstname.lastname@example.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 <email@example.com>
> (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  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.
> > 
> > https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d99bd7e1b67bcbce8f4e0e
> 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
> 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
Ard: is this a config supported/able by ArmVirtPkg?
> But let's find out if that's the route we want to take first.
> -- PMM