Re: [PATCH] KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks
From: Nicholas Piggin <npiggin@gmail.com>
Date: 2021-05-06 04:58:17
Also in:
kvm
Excerpts from Sean Christopherson's message of May 6, 2021 1:52 am:
On Wed, May 05, 2021, Nicholas Piggin wrote:quoted
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.
quoted
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 <redacted> Tested-by: Bharata B Rao <redacted> Signed-off-by: Nicholas Piggin <npiggin@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