Nicholas Piggin <npig...@gmail.com> writes:
> When new work is created that requires attention from the hypervisor
> (e.g., to inject an interrupt into the guest), fast_vcpu_kick is used to
> pull the target vcpu out of the guest if it may have been running.
>
> Therefore the work creation side looks like this:
>
> vcpu->arch.doorbell_request = 1;
> kvmppc_fast_vcpu_kick_hv(vcpu) {
> smp_mb();
> cpu = vcpu->cpu;
> if (cpu != -1)
> send_ipi(cpu);
> }
>
> And the guest entry side *should* look like this:
>
> vcpu->cpu = smp_processor_id();
> smp_mb();
> if (vcpu->arch.doorbell_request) {
> // do something (abort entry or inject doorbell etc)
> }
>
> But currently the store and load are flipped, so it is possible for the
> entry to see no doorbell pending, and the doorbell creation misses the
> store to set cpu, resulting lost work (or at least delayed until the
> next guest exit).
>
> Fix this by reordering the entry operations and adding a smp_mb
> between them. The P8 path appears to have a similar race which is
> commented but not addressed yet.
>
> Signed-off-by: Nicholas Piggin <npig...@gmail.com>
Reviewed-by: Fabiano Rosas <faro...@linux.ibm.com>
