Re: [PATCH 06/16] hw/arm/xlnx-zcu102: Don't enable PSCI conduit when booting guest in EL3

[Alexander Graf]

On 07.02.22 17:06, Philippe Mathieu-Daudé wrote:
> On 7/2/22 16:59, Alexander Graf wrote:
> > On 07.02.22 16:52, Edgar E. Iglesias wrote:
>
> > > Both Versal and ZynqMP require MicroBlaze firmware to run the 
> > > reference implementations of Trusted Firmware. We never supported 
> > > this in upstream QEMU but we do support it with our fork (by running 
> > > multiple QEMU instances co-simulating).
> > >
> > > Having said that, we do have tons of EL3 test-cases that we use to 
> > > validate QEMU that run with EL3 enabled in upstream.
> > >
> > > So there's two user flows:
> > > 1. Direct boots using QEMUs builtin PSCI (Most users use this to run 
> > > Linux, Xen, U-boot, etc)
> > > 2. Firmware boot at EL3 without QEMUs builtin PSCI (Mostly used by 
> > > test-code)
> > >
> > > Number #2 is the one affected here and that by accident used to have 
> > > the builtin PSCI support enabled but now requires more power control 
> > > modelling to keep working.
> > > Unless I'm missing something, the -kernel boots will continue to use 
> > > the builtin PSCI implementation.
> >
> >
> > So nobody is using upstream QEMU to validate and prototype 
> > ATF/EL1s/EL0s code? That's a shame :). I suppose there is little 
> > value without the bitstream emulation and R cluster. Do you have 
> > plans to bring multi process emulation upstream some day to enable 
> > these there?
>
> The R cluster is already in mainstream, isn't it?


In that case, wouldn't it make sense to build an emulation model of the 
PMU behavior so that normal ATF works out of the box?


Thanks,

Alex