| Message ID | 20201028085918.14580-1-maxim.uvarov@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] hw/arm/virt: use sbsa-ec for reboot and poweroff in secure mode | expand |
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/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 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) But let's find out if that's the route we want to take first. thanks -- PMM
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/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 > 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. Ard: is this a config supported/able by ArmVirtPkg? Best Regards, Leif > But let's find out if that's the route we want to take first. > > thanks > -- PMM
On Thu, 29 Oct 2020 at 11:19, Leif Lindholm <leif@nuviainc.com> wrote: > > Hi Peter, (+Ard) > > Graeme is on holiday this week, and I would like his input. Sure. There's no rush here, as QEMU has just entered freeze for 5.2, so at the very earliest patches for this feature wouldn't go into master until mid-December. > On Wed, Oct 28, 2020 at 20:31:41 +0000, Peter Maydell wrote: > > 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). Well, for sbsa-ref it doesn't need to go into the DTB. For virt we mandate that everything is described in the DTB (and that secure firmware should consume the DTB to figure out where things live), so whatever power-control device we come up with would have to be described there. I'm less sure about ACPI because I think that is used only for describing the non-secure environment to the non-secure EL2/EL1 code so it doesn't need to describe devices that aren't visible there. But I'm not very familiar with ACPI, hence my uncertainty. > 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. Yeah, that's the kind of complexity that we would want to avoid in 'virt', I think. thanks -- PMM
On Thu, 29 Oct 2020 at 12:26, Peter Maydell <peter.maydell@linaro.org> wrote: > On Thu, 29 Oct 2020 at 11:19, Leif Lindholm <leif@nuviainc.com> wrote: > > > > Hi Peter, (+Ard) > > > > Graeme is on holiday this week, and I would like his input. > > Sure. There's no rush here, as QEMU has just entered freeze for > 5.2, so at the very earliest patches for this feature wouldn't go > into master until mid-December. > > > On Wed, Oct 28, 2020 at 20:31:41 +0000, Peter Maydell wrote: > > > 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). > > Well, for sbsa-ref it doesn't need to go into the DTB. For > virt we mandate that everything is described in the DTB > (and that secure firmware should consume the DTB to figure > out where things live), so whatever power-control device we > come up with would have to be described there. I'm less sure > about ACPI because I think that is used only for describing > the non-secure environment to the non-secure EL2/EL1 code > so it doesn't need to describe devices that aren't visible there. > But I'm not very familiar with ACPI, hence my uncertainty. > > > 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. > Arm SystemReady now defines BSA as the generic hardware requirements for which S(erver)BSA is a special case. It feels like there are three use cases driving three different QEMU platforms: - virt = FW:{Qemu}, simple cloud native workloads, - sbsa = HW:{watchdog, random number generator, secure flash, TPM, BMC?...} FW:{EDK2, KASLR, SecureBoot capabilities} --> developer vehicle for sbbr - bsa = HW:{watchdog, random number generator, secure flash...} FW:{U-boot,TF-A, OP-TEE, firmwareTPM} --> developer vehicle for ebbr, may be automotive workloads to have virtual TAs/TPMs I also think that ultimately SCP ( https://github.com/ARM-software/SCP-firmware) may end up running in the context of QEMU. > > Yeah, that's the kind of complexity that we would want to avoid > in 'virt', I think. > > thanks > -- PMM >
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/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 > > 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
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/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 > > > 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.
On Thu, 5 Nov 2020 at 07:48, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > Thanks. Is there anything I need to do with this RFC patch or it can > be accepted as is? It sounds to me like the input from the sbsa-ref maintainers is that they plan to do a lot with sbsa-ec that we would not work in virt. So it would be better to take the "add a secure pl061 whose pins are wired up to reset/shutdown" approach instead. thanks -- PMM
diff --git a/hw/arm/virt.c b/hw/arm/virt.c index e465a988d6..6b77912f02 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -152,6 +152,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN }, [VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN}, [VIRT_PVTIME] = { 0x090a0000, 0x00010000 }, + [VIRT_EC] = { 0x090c0000, 0x00001000 }, [VIRT_MMIO] = { 0x0a000000, 0x00000200 }, /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */ [VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 }, @@ -1729,6 +1730,13 @@ static void virt_cpu_post_init(VirtMachineState *vms, int max_cpus, } } +static void init_ec_controller(VirtMachineState *vms) +{ + vms->ec = qdev_new("sbsa-ec"); + + sysbus_mmio_map(SYS_BUS_DEVICE(vms->ec), 0, vms->memmap[VIRT_EC].base); +} + static void machvirt_init(MachineState *machine) { VirtMachineState *vms = VIRT_MACHINE(machine); @@ -1797,6 +1805,7 @@ static void machvirt_init(MachineState *machine) */ if (vms->secure && firmware_loaded) { vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED; + init_ec_controller(vms); } else if (vms->virt) { vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC; } else { diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index aad6d69841..6f2ce4e4ff 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -85,6 +85,7 @@ enum { VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, VIRT_PVTIME, + VIRT_EC, VIRT_LOWMEMMAP_LAST, }; @@ -163,6 +164,7 @@ struct VirtMachineState { DeviceState *gic; DeviceState *acpi_dev; Notifier powerdown_notifier; + DeviceState *ec; }; #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
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> --- 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/6d3339a0081f6f2b45d99bd7e1b67bcbce8f4e0e Best regards, Maxim. hw/arm/virt.c | 9 +++++++++ include/hw/arm/virt.h | 2 ++ 2 files changed, 11 insertions(+)