On Sat, Jun 25, 2022 at 05:13:22PM +0800, Paolo Bonzini wrote:
> On 6/25/22 01:06, Sean Christopherson wrote:
> >>("KVM: Replace old tlb flush function with new one to flush a specified range.")
> >>replaces old tlb flush function with kvm_flush_remote_tlbs_with_address()
> >>to do tlb flushing. However, the gfn range of tlb flushing is wrong in
> >>some cases. E.g., when a spte is dropped, the start gfn of tlb flushing
> >Heh, "some" cases. Looks like KVM is wrong on 7 of 15 cases. And IIRC, there
> >were already several rounds of fixes due to passing "end" instead of "nr_pages".
> >
> >Patches look ok on a quick read through, but I'd have to stare a bunch more to
> >be confident.
> >
> >Part of me wonders if we should just revert the whole thing and then only reintroduce
> >range-based flushing with proper testing and maybe even require performance numbers
> >to justify the benefits. Give that almost 50% of the users are broken, it's pretty
> >obvious that no one running KVM actually tests the behavior.
> >
>
> I'm pretty sure it's in use on Azure. Some of the changes are
> flushing less, for the others it's more than likely that Hyper-V
> treats a 1-page flush the same if the address points to a huge page.
>
I lookup hyperv_fill_flush_guest_mapping_list(), gpa_list.page.largepage
is always false. Or the behaviour you said is implemented in Hyper-V not
in KVM ?
> Paolo
