qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 02/22] arm: tcg: Adhere to SMCCC 1.3 section 5.2


From: Peter Maydell
Subject: Re: [PULL 02/22] arm: tcg: Adhere to SMCCC 1.3 section 5.2
Date: Fri, 19 Nov 2021 14:15:28 +0000

On Fri, 19 Nov 2021 at 10:35, Alexander Graf <agraf@csgraf.de> wrote:
> Ugh :(. Conceptually, once you tell QEMU to handle PSCI, you're
> basically giving up that EL to it. It sounds almost as if what these
> boards (imx6ul + highbank) want is an EL4 they can call into to deflect
> PSCI calls into from EL3 they own. We would basically have to allocate a
> currently undefinied/reserved instruction as "QEMU SMC" and make the EL3
> code call that when it needs to call QEMU for PSCI operations. Or a PV
> MMIO device. Or a PV sysreg. But at the end of the day, EL3 calling into
> QEMU differently than on real hardware is paravirtualization.

I think in practice what they're doing is "we want an emulated
firmware that provides PSCI and also stubs out some other SMCs".
(My extremely vague recollection is that the SMC in question was
some kind of "flush cache" operation on the l2x0 cache controller,
which was secure-mode-access only.) So probably the eventual
answer is going to be "PSCI setting x0 is OK, get rid of the
infrastructure for setting up the do-nothing-SMC-handler. But it's
too complicated and needs too much archaeology on why we added
this code to be doable for 6.2.

> Just to double check: Is the broken monitor code that expects QEMU to
> partially handle SMCs only ever injected into the guest by us or is
> there existing guest payload code for EL3 that makes the same assumption?

We only write the boot stub code that uses SMC if we're booting a
Linux kernel (ie not running the guest at EL3). So for guest EL3
code the highbank board is in the same bucket as the other
affected boards (mcimx6ul-evk, mcimx7d-sabre, orangepi, xlnx-zcu102,
plus for EL3 code loaded via -kernel: virt and xlnx-versal-virt):
maybe somebody had EL3 guest code that was assuming that QEMU
provided PSCI, but that would be something that could only run
on QEMU's model, not on the real hardware. So I'm OK with
breaking that if it exists.

(In particular to get SMP to work on these boards
with EL3 guest code we need to model a power controller or some
other way to get the secondary CPUs to power up, unless the EL3
code expects the "all cores start the bios code simultaneously"
pattern.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]