On Thu, 29 Oct 2020 at 12:26, Peter Maydell <peter.mayd...@linaro.org>
wrote:
> On Thu, 29 Oct 2020 at 11:19, Leif Lindholm <l...@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
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
