Thread (5 messages) flat view 5 messages, 4 authors, 2021-05-06

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help