[PATCH v3 10/18] KVM: arm64: Handle PSCI calls for protected VMs at EL2
Fuad Tabba
fuad.tabba at linux.dev
Wed Sep 23 02:51:34 PDT 2026
Hi Vincent,
> > +/*
> > + * Returns true when handled at EL2, false when the host must stop scheduling
> > + * the vCPU.
> > + */
> > +static bool pvm_psci_vcpu_off(struct pkvm_hyp_vcpu *hyp_vcpu)
> > +{
> > + /* No other writer runs while this vCPU is ON and executing. */
> > + WARN_ON(READ_ONCE(hyp_vcpu->power_state) != PSCI_0_2_AFFINITY_LEVEL_ON);
> > +
> > + /*
> > + * Orders pkvm_reset_vcpu()'s clear of reset_state.reset before OFF, so
> > + * a CPU_ON that wins on OFF republishes after it. Pairs with the
> > + * cmpxchg in pvm_psci_vcpu_on().
> > + */
> > + smp_store_release(&hyp_vcpu->power_state, PSCI_0_2_AFFINITY_LEVEL_OFF);
>
> Is there an issue either with the comment or with pvm_psci_vcpu_on()? the
> cmpxchg is relaxed. I would have expected cmpxchg_acquire().
It's the comment. The ordering it describes holds with the relaxed
cmpxchg. The release of OFF orders the clear before OFF. The winner's
smp_store_release(&reset_state->reset, true) orders its cmpxchg before
that store. So the clear can't land after the republish. The comment
should name that store-release as the pair, not the cmpxchg.
You're right about the acquire though, for the plain stores to
reset_state.{pc, r0, be} after the cmpxchg. I'll make it
cmpxchg_acquire() in v4 and reword both comments.
Cheers,
/fuad
More information about the linux-arm-kernel
mailing list