On 07.02.22 19:59, Philippe Mathieu-Daudé wrote:
On 7/2/22 19:13, Edgar E. Iglesias wrote:
On Mon, Feb 7, 2022 at 5:24 PM Alexander Graf <[email protected]
<mailto:[email protected]>> wrote:
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
Yes, that makes sense and there are several ways to implement it. To
fully support the programmability of the PMU we'd need to model the
MicroBlazes together with the ARM cores.
But PMU support does not really conflict with this patch series, or
is there something I'm missing?
My understanding is Alex generically wonders about code coverage, not
about the ZynqMP in particular :)
I'm more curious what the purpose of zynqmp / versal simulation in QEMU
is. What we're saying here is that we only care about "Linux at EL2 and
below" plus a Xilinx validation test suite. I understand how multi-QEMU
emulation may be difficult, but EL3 simulation with Cortex-A plus
Cortex-R clusters and a simulated PMU sounds like it would get you a
very long way on simulation coverage.
That said, Xilinx probably knows their user base the best, so if they
decide that the ability to run TrustZone code is not something they
believe their users need in QEMU, I'm definitely happy with that stance.
Alex
