From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Wed, 05 May 2021 15:52:08 +0000 Subject: Re: [PATCH] KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacks Message-Id: List-Id: References: <20210505121509.1470207-1-npiggin@gmail.com> In-Reply-To: <20210505121509.1470207-1-npiggin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Nicholas Piggin Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "Aneesh Kumar K . V" , Paolo Bonzini , Bharata B Rao 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 :-/ > 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 > Tested-by: Bharata B Rao > Signed-off-by: Nicholas Piggin > --- > 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.