Re: [PATCH v3 10/18] KVM: arm64: Handle PSCI calls for protected VMs at EL2

[Will Deacon <will@kernel.org>]

Hi Fuad,

On Thu, Sep 24, 2026 at 04:21:01PM +0100, Fuad Tabba wrote:
> On Thu, 24 Sep 2026 13:14:00 +0100, Will Deacon <will@kernel.org> wrote:
> [...]
> > > It's not publishing data, it's handing reset_state back.
> >
> > What's the difference? The usual pattern for acquire/release is:
> >
> > <write data>
> > <store-release flag>
> >
> > on one CPU and then on another:
> >
> > <load-acquire flag>     // If this reads from the release above...
> > <read data>             // ... then this is guaranteed to read the written data
> >
> > That's a message-passing shape and you would normally say that the first
> > CPU (the producer) is publishing the data to the other CPU (the consumer).
> >
> > Is this what is happening with the 'reset_state' (data) and the
> > 'power_state' (flag)? If not, then what is the shape?
> 
> I don't think so, it's the other direction. That pattern is the pair
> on reset_state.reset, and it isn't in question. The pair on
> power_state, as I see it, runs the other way: the target's last
> accesses to reset_state are its reads of the payload and its clear of
> the flag in pkvm_reset_vcpu(), and the next CPU_ON's accesses are
> stores. Release on OFF, acquire on the cmpxchg: unlock then lock, with
> power_state as the lock word. The winner takes it with the cmpxchg,
> hands it to the target through reset, and the target gives it up at
> CPU_OFF. Nothing is published. What I was after is the winner's stores
> being ordered after the target's reads and its clear.

For the benefit of everybody else, we had a fire alarm in the office
yesterday evening so Fuad and I sat outside a bar with a beer and a
piece of paper and went through this together...

There are two confusing aspects to the current code:

1. The OFF->ON_PENDING transition happens on the vCPU requesting CPU_ON
   whereas the ON_PENDING->ON transition happens on the incoming
   (target) vCPU, with reset_state->reset used to synchronise between
   the two.

2. reset_state->reset is cleared to false by the target vCPU on the
   guest entry path, rather than on the CPU_OFF path.

If we address (2), then I think the sequence becomes a little easier to
reason about. The OFF->ON_PENDING transition on the requestor looks
like:

	// PSCI CPU_ON
	cmpxchg_relaxed(power_state): OFF -> ON_PENDING
	<ctrl>
	write_reset_state();
	smp_store_release(reset_state->reset, true);

and then the whole ON_PENDING -> ON -> run_guest() -> OFF sequence on
the target looks like:

	// Target vCPU comes online
	smp_load_acquire(reset_state->reset) == true;
	cmpxchg_relaxed(power_state): ON_PENDING -> ON;
	read_reset_state();

	<run guest>

	// PSCI CPU_OFF
	WRITE_ONCE(reset_state->reset, false);
	smp_store_release(power_state, OFF);

which I think makes sense. WDYT? If you agree, I wonder if we can
include a comment similar to the above in the code?

Will