Re: Qemu and ARM secure state.

[Peter Maydell]

On Tue, 9 Nov 2021 at 19:06, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote:
> So basically the Qemu i.MX7 processor code needs to set psci-conduit to SMC
> because we want to be able to boot the Linux kernel directly (without u-boot)
> with Qemu emulating the PSCI services when an SMC instruction is triggered.
>
> As I see it we also need a way to disable this Qemu PSCI emulation in case we
> want to boot an EL3 software (u-boot, optee or other).

Yes; we definitely want to support both of these use cases.

> We could certainly pass a command line option to explicitly tell Qemu to 
> disable
> the PCSI emulation. But this would be a bit cumbersome as the board level
> code would then need to call to the SOC code to disable the psci setting on 
> all cores.

We definitely don't want a new command line option. We just want to
use the information we already have (whether we're going to start the
guest code in secure/at EL3 or not) to make this decision.

> So I am wondering if we could be more "clever" solution and have things 
> sorted out automatically. I would like to suggest 2 solutions;
>
> The first solution could be based on the mode of the processor when it starts 
> executing the provided software. If I remember correctly what you explained, 
> if an ELF file is provided then the processor boots in the highest level (EL3 
> for i.MX6/i.MX7) while if a non ELF file is provided (uImage ...) then the 
> processor boots in EL2 (or lower depending on the processor) to emulate the 
> uboot behavior.
>
> if the processor starts the software in EL3 then we need to disable the 
> "psci-conduit" through SMC (if set) because the EL3 software should 
> install/provide the necessary firmware.
> If the processor starts the software in EL2 then we need to disable the 
> "psci-conduit" through HVC (if set) because the EL2 software should 
> install/provide the necessary firmware.

This is the right approach. The idea I suggested in the previous email
was that rather than having the SoC object code setting psci-conduit
always, and then something else coming along later and changing it,
we should instead not set it in the first place. It's a simple QOM property
which means it's not writable after the CPU object has been realized, I think,
so we'd have to jump through some hoops to get it to be writable later.
On the other hand looking in hw/arm/boot.c we don't decide whether this
is a Linux boot (which means it will be to non-secure) or a non-Linux
boot (which means it will be to EL3) until quite late, so that's awkward
too (plus there's potentially duplication between board/SoC code of
the logic to decide whether to set psci-conduit or not). Let me have
a think about the cleanest way to arrange this.

-- PMM