[PATCH] KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks

[Nicholas Piggin]

Excerpts from Sean Christopherson's message of May 6, 2021 1:52 am:
> On Wed, May 05, 2021, Nicholas Piggin wrote:
>> Commit b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier
>> callbacks") causes unmap_gfn_range and age_gfn callbacks to only work
>> on the first gfn in the range. It also makes the aging callbacks call
>> into both radix and hash aging functions for radix guests. Fix this.
> 
> Ugh, the rest of kvm_handle_hva_range() was so similar to the x86 code that I
> glossed right over the for-loop.  My apologies :-/

No problem, we should have noticed it here in testing earlier too.

> 
>> Add warnings for the single-gfn calls that have been converted to range
>> callbacks, in case they ever receieve ranges greater than 1.
>> 
>> Fixes: b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")
>> Reported-by: Bharata B Rao <bharata at linux.ibm.com>
>> Tested-by: Bharata B Rao <bharata at linux.ibm.com>
>> Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
>> ---
>> The e500 change in that commit also looks suspicious, why is it okay
>> to remove kvm_flush_remote_tlbs() there? Also is the the change from
>> returning false to true intended?
> 
> The common code interprets a return of "true" as "do kvm_flush_remote_tlbs()".
> There is technically a functional change, as the deferring the flush to common
> code will batch flushes if the invalidation spans multiple memslots.  But the
> mmu_lock is held the entire time, so batching is a good thing unless e500 has
> wildly different MMU semantics.

Ah okay that explains it. That sounds good, but I don't know the e500 
KVM code or have a way to test it myself.

Thanks,
Nick