KVM: arm64: Reject host power-on of a vCPU that EL2 holds powered off

A protected vCPU's power state belongs to EL2, which changes it only
on the guest's own PSCI calls. KVM_SET_MP_STATE(RUNNABLE) on a vCPU
EL2 holds powered off changes the host's copy alone, and the guest's
next CPU_ON of that vCPU then fails: mp_state is no longer STOPPED, so
the host returns ALREADY_ON, and the guest's retry fails the same way
until the VMM stops the vCPU again. SUSPENDED has the same effect.

Record a vCPU EL2 holds powered off as KVM_MP_STATE_UNINITIALIZED, an
encoding arm64 didn't use: the guest's CPU_OFF writes it, as does hyp
vCPU creation for a vCPU that starts STOPPED, and only the guest's
CPU_ON writes RUNNABLE over it. RUNNABLE and SUSPENDED from the VMM
return -EPERM on it, the VMM can't write the value itself, and
KVM_ARM_VCPU_INIT, which would write STOPPED or RUNNABLE over it, is
rejected once the vCPU has run.

The VMM can still pause and resume a vCPU EL2 has powered on. Neither
STOPPED nor kvm_prepare_system_event() overwrites the value: a vCPU at
it is already off, and a STOPPED in its place would turn the guest's
next CPU_ON into ALREADY_ON, after a SYSTEM_RESET exit the VMM runs on
from. kvm_arm_vcpu_stopped() covers it, so the run loop sleeps the
vCPU as before.

The guest's CPU_ON is gated on the value rather than on STOPPED. A
STOPPED written between the target's CPU_OFF exit and the host's
power-off of it, which kvm_prepare_system_event() can do from another
vCPU's SYSTEM_OFF or SYSTEM_RESET, would otherwise let the CPU_ON
through, and the power-off would then record the target powered off
while EL2 holds it ON_PENDING, with no way back before VM teardown.
Gated on the value, that CPU_ON returns ALREADY_ON and the retry
succeeds once the power-off has run.

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

0 files changed, 0 insertions, 0 deletions