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