KVM: arm64: Handle PSCI calls for protected VMs at EL2

EL2 implements PSCI 1.1 for protected VMs: CPU_ON, CPU_OFF,
PSCI_VERSION and PSCI_FEATURES are resolved at EL2 (CPU_ON and CPU_OFF
still exit to the host, which only schedules the target or stops
scheduling it), AFFINITY_INFO, CPU_SUSPEND and the platform power
operations are forwarded to the host, and anything else returns
NOT_SUPPORTED, including the TRNG calls and the functions above 1.1,
SYSTEM_OFF2 among them, that the host handled for a protected guest
until now. TRNG for protected guests is a follow-up. AFFINITY_INFO
stays with the host, which returns OFF only once it has stopped
scheduling the target: the host is what a guest polls to see a CPU_OFF
complete before it issues the next CPU_ON, as Linux does on hotplug.

Three consequences follow:

  - A protected VM has one primary vCPU, the first whose hyp vCPU is
    created with mp_state RUNNABLE. A second one, or an mp_state other
    than RUNNABLE or STOPPED, fails that vCPU's first KVM_RUN with
    -EINVAL.

  - CPU_ON finds its target among the hyp vCPUs, which exist from the
    target's first KVM_RUN; before that the guest gets
    INVALID_PARAMETERS.

  - A vCPU EL2 holds powered off doesn't run: handle___kvm_vcpu_run()
    returns ARM_EXCEPTION_IL, reported as KVM_EXIT_FAIL_ENTRY. Its
    existing bail-outs return the same code, for every hyp vCPU, instead
    of an -EINVAL whose bit 31 the host read as a pending SError.

Non-protected VMs keep power_state ON and accept any mp_state.

Each protected vCPU is OFF, ON_PENDING or ON. CPU_ON moves the target
to ON_PENDING, and the target's next run resets it and moves it to ON.
The racing transitions are cmpxchg, and the reset state is published
with a release/acquire pair, documented at each site. CPU_OFF clears
the reset flag and stores OFF with a release, and CPU_ON's writes are
control dependent on its cmpxchg reading OFF, so the target's accesses
to reset_state are ordered before the winner's writes. Rolling a CPU_ON
the host failed back to OFF requires the host's return value, which
the per-EC marshalling patch delivers along with the rollback. Until
then such a target stays ON_PENDING, and the reset has no observable
effect: flush_hyp_vcpu() copies the host's context in on every entry
until that patch removes the copy, so the target enters on the host's
values rather than the ones EL2 reset.

Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20261001135711.1640520-11-fuad.tabba@linux.dev
Signed-off-by: Marc Zyngier <maz@kernel.org>

0 files changed, 0 insertions, 0 deletions