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
Yeah, that's the kind of complexity that we would want to avoid
in 'virt', I think.
thanks
-- PMM