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