Message ID | 20231109210325.3806151-1-amoorthy@google.com (mailing list archive) |
---|---|
Headers | show |
Series | Improve KVM + userfaultfd performance via KVM_MEMORY_FAULT_EXITs on stage-2 faults | expand |
On Thu, Nov 09, 2023, Anish Moorthy wrote: > Base Commit > ~~~~~~~~~~~ > This series is based off of kvm/next (45b890f7689e) with v14 of the > guest_memfd series applied, with some fixes on top [3]. Please use `--base`. I have gotten spoiled by git appending the object ID at the bottom, and get annoyed every time I have to go spelunking for the base :-) Also, in the future, when posting a series that has multiple dependencies, it is *very* helpful to reviewers and maintainers to provide a full branch somewhere, e.g. on github, gitlab, etc. That way someone that wants to actually test things doesn't need to hunt down and splice together a bunch of different assets. From Documentation/process/maintainer-kvm-x86.rst: Git Base ~~~~~~~~ If you are using git version 2.9.0 or later (Googlers, this is all of you!), use ``git format-patch`` with the ``--base`` flag to automatically include the base tree information in the generated patches. Note, ``--base=auto`` works as expected if and only if a branch's upstream is set to the base topic branch, e.g. it will do the wrong thing if your upstream is set to your personal repository for backup purposes. An alternative "auto" solution is to derive the names of your development branches based on their KVM x86 topic, and feed that into ``--base``. E.g. ``x86/pmu/my_branch_name``, and then write a small wrapper to extract ``pmu`` from the current branch name to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to track the KVM x86 remote. > Anish Moorthy (14): > KVM: Documentation: Clarify meaning of hva_to_pfn()'s 'atomic' > parameter > KVM: Documentation: Add docstrings for __kvm_read/write_guest_page() > KVM: Simplify error handling in __gfn_to_pfn_memslot() > KVM: Define and communicate KVM_EXIT_MEMORY_FAULT RWX flags to > userspace > KVM: Try using fast GUP to resolve read faults > KVM: Add memslot flag to let userspace force an exit on missing hva > mappings > KVM: x86: Enable KVM_CAP_EXIT_ON_MISSING and annotate EFAULTs from > stage-2 fault handler > KVM: arm64: Enable KVM_CAP_MEMORY_FAULT_INFO > KVM: arm64: Enable KVM_CAP_EXIT_ON_MISSING and annotate an EFAULT from > stage-2 fault-handler > KVM: selftests: Report per-vcpu demand paging rate from demand paging > test > KVM: selftests: Allow many vCPUs and reader threads per UFFD in demand > paging test > KVM: selftests: Use EPOLL in userfaultfd_util reader threads and > signal errors via TEST_ASSERT > KVM: selftests: Add memslot_flags parameter to memstress_create_vm() > KVM: selftests: Handle memory fault exits in demand_paging_test > > Documentation/virt/kvm/api.rst | 33 +- > arch/arm64/kvm/Kconfig | 1 + > arch/arm64/kvm/arm.c | 1 + > arch/arm64/kvm/mmu.c | 7 +- > arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- > arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +- > arch/x86/kvm/Kconfig | 1 + > arch/x86/kvm/mmu/mmu.c | 8 +- > include/linux/kvm_host.h | 21 +- > include/uapi/linux/kvm.h | 5 + > .../selftests/kvm/aarch64/page_fault_test.c | 4 +- > .../selftests/kvm/access_tracking_perf_test.c | 2 +- > .../selftests/kvm/demand_paging_test.c | 295 ++++++++++++++---- > .../selftests/kvm/dirty_log_perf_test.c | 2 +- > .../testing/selftests/kvm/include/memstress.h | 2 +- > .../selftests/kvm/include/userfaultfd_util.h | 17 +- > tools/testing/selftests/kvm/lib/memstress.c | 4 +- > .../selftests/kvm/lib/userfaultfd_util.c | 159 ++++++---- > .../kvm/memslot_modification_stress_test.c | 2 +- > .../x86_64/dirty_log_page_splitting_test.c | 2 +- > virt/kvm/Kconfig | 3 + > virt/kvm/kvm_main.c | 46 ++- > 22 files changed, 444 insertions(+), 175 deletions(-) A few nits throughout, but this is looking good for 6.9. Oliver / Marc, Any objection to taking this through kvm-x86? (when you feel it's ready, obviously) My plan is to put it in a dedicated topic branch, with a massaged cover letter as the tag used for the pull request so that we can capture the motivation/benefits.
On Wed, Feb 7, 2024 at 7:46 AM Sean Christopherson <seanjc@google.com> wrote: > > A few nits throughout, but this is looking good for 6.9. > > Oliver / Marc, > > Any objection to taking this through kvm-x86? (when you feel it's ready, obviously) > My plan is to put it in a dedicated topic branch, with a massaged cover letter as > the tag used for the pull request so that we can capture the motivation/benefits. Oliver and Marc, I have a v7 ready based on the feedback I've received so far- please let me know if I should send it or wait for you to take a look at this version first. On the one hand I obviously want to incorporate any feedback you have for the next version, but on the other I suspect that if/when you look at this you'll want to see a version with as few (known) flaws as possible