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

[Alexander Graf <agraf@csgraf.de>]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]


On 07.02.22 16:52, Edgar E. Iglesias wrote:
>
>
> On Mon, Feb 7, 2022 at 4:33 PM Alexander Graf <agraf@csgraf.de> wrote:
>
>
>     On 07.02.22 16:22, Peter Maydell wrote:
>     > On Mon, 7 Feb 2022 at 14:21, Alexander Graf <agraf@csgraf.de> wrote:
>     >>
>     >> On 27.01.22 16:46, Peter Maydell wrote:
>     >>> Change the Xilinx ZynqMP-based board xlnx-zcu102 to use the new
>     >>> boot.c functionality to allow us to enable psci-conduit only if
>     >>> the guest is being booted in EL1 or EL2, so that if the user runs
>     >>> guest EL3 firmware code our PSCI emulation doesn't get in its
>     >>> way.
>     >>>
>     >>> To do this we stop setting the psci-conduit property on the CPU
>     >>> objects in the SoC code, and instead set the psci_conduit field in
>     >>> the arm_boot_info struct to tell the common boot loader code that
>     >>> we'd like PSCI if the guest is starting at an EL that it makes
>     >>> sense with.
>     >>>
>     >>> Note that this means that EL3 guest code will have no way
>     >>> to power on secondary cores, because we don't model any
>     >>> kind of power controller that does that on this SoC.
>     >>>
>     >>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>     >>
>     >> It's been a while since I worked with ZynqMP, but typically
>     your ATF in
>     >> EL3 will want to talk to a microblaze firmware blob on the PMU.
>     >>
>     >> I only see a stand alone PMU machine for microblaze and a PMU IRQ
>     >> handling I/O block in QEMU, but nothing that would listen to
>     the events.
>     >> So I'm fairly sure it will be broken after this patch - and
>     really only
>     >> worked by accident before.
>     > Edgar submitted a power-control model patchset:
>     >
>     https://patchew.org/QEMU/20220203140141.310870-1-edgar.iglesias@gmail.com/
>
>
>     Ah, nice. Would this also work for Versal?
>
>
>     Thanks,
>
>     Alex
>
>
> Hi,
>
> 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?


Alex

[-- Attachment #2: Type: text/html, Size: 5641 bytes --]