From: Sean Christopherson <seanjc@google.com>
To: James Houghton <jthoughton@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Yan Zhao <yan.y.zhao@intel.com>,
Nikita Kalyazin <kalyazin@amazon.com>,
Anish Moorthy <amoorthy@google.com>,
Peter Gonda <pgonda@google.com>, Peter Xu <peterx@redhat.com>,
David Matlack <dmatlack@google.com>,
wei.w.wang@intel.com, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v2 05/13] KVM: x86/mmu: Add support for KVM_MEM_USERFAULT
Date: Tue, 6 May 2025 17:05:50 -0700 [thread overview]
Message-ID: <aBqj3s8THH9SFzLO@google.com> (raw)
In-Reply-To: <20250109204929.1106563-6-jthoughton@google.com>
On Thu, Jan 09, 2025, James Houghton wrote:
> Adhering to the requirements of KVM Userfault:
>
> 1. Zap all sptes for the memslot when KVM_MEM_USERFAULT is toggled on
> with kvm_arch_flush_shadow_memslot().
> 2. Only all PAGE_SIZE sptes when KVM_MEM_USERFAULT is enabled (for both
> normal/GUP memory and guest_memfd memory).
> 3. Reconstruct huge mappings when KVM_MEM_USERFAULT is toggled off with
> kvm_mmu_recover_huge_pages(). This is the behavior when dirty logging
> is disabled; remain consistent with it.
>
> With the new logic in kvm_mmu_slot_apply_flags(), I've simplified the
> two dirty-logging-toggle checks into one, and I have dropped the
> WARN_ON() that was there.
>
> Signed-off-by: James Houghton <jthoughton@google.com>
> ---
> arch/x86/kvm/Kconfig | 1 +
> arch/x86/kvm/mmu/mmu.c | 27 +++++++++++++++++++++----
> arch/x86/kvm/mmu/mmu_internal.h | 20 +++++++++++++++---
> arch/x86/kvm/x86.c | 36 ++++++++++++++++++++++++---------
> include/linux/kvm_host.h | 5 ++++-
> 5 files changed, 71 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index ea2c4f21c1ca..286c6825cd1c 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -47,6 +47,7 @@ config KVM_X86
> select KVM_GENERIC_PRE_FAULT_MEMORY
> select KVM_GENERIC_PRIVATE_MEM if KVM_SW_PROTECTED_VM
> select KVM_WERROR if WERROR
> + select HAVE_KVM_USERFAULT
>
> config KVM
> tristate "Kernel-based Virtual Machine (KVM) support"
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 2401606db260..5cab2785b97f 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4280,14 +4280,19 @@ static inline u8 kvm_max_level_for_order(int order)
> return PG_LEVEL_4K;
> }
>
> -static u8 kvm_max_private_mapping_level(struct kvm *kvm, kvm_pfn_t pfn,
> - u8 max_level, int gmem_order)
> +static u8 kvm_max_private_mapping_level(struct kvm *kvm,
> + struct kvm_memory_slot *slot,
> + kvm_pfn_t pfn, u8 max_level,
> + int gmem_order)
> {
> u8 req_max_level;
>
> if (max_level == PG_LEVEL_4K)
> return PG_LEVEL_4K;
>
> + if (kvm_memslot_userfault(slot))
Unless I'm missing something, this can go in kvm_mmu_hugepage_adjust():
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a4439e9e0726..49eb6b9b268c 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3304,7 +3304,7 @@ void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault
if (is_error_noslot_pfn(fault->pfn))
return;
- if (kvm_slot_dirty_track_enabled(slot))
+ if (kvm_slot_dirty_track_enabled(slot) || kvm_is_userfault_memslot(slot))
return;
> static inline int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 1b04092ec76a..2abb425a6514 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13053,12 +13053,36 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm,
> u32 new_flags = new ? new->flags : 0;
> bool log_dirty_pages = new_flags & KVM_MEM_LOG_DIRTY_PAGES;
>
> + /*
> + * When toggling KVM Userfault on, zap all sptes so that userfault-ness
> + * will be respected at refault time. All new faults will only install
> + * small sptes. Therefore, when toggling it off, recover hugepages.
> + *
> + * For MOVE and DELETE, there will be nothing to do, as the old
> + * mappings will have already been deleted by
> + * kvm_arch_flush_shadow_memslot().
> + *
> + * For CREATE, no mappings will have been created yet.
> + */
Eh, trim this down and the reference the comment below to explain why FLAGS_ONLY
is the only case that needs to be handled.
> + if ((old_flags ^ new_flags) & KVM_MEM_USERFAULT &&
> + (change == KVM_MR_FLAGS_ONLY)) {
> + if (old_flags & KVM_MEM_USERFAULT)
> + kvm_mmu_recover_huge_pages(kvm, new);
> + else
> + kvm_arch_flush_shadow_memslot(kvm, old);
The call to kvm_arch_flush_shadow_memslot() should definitely go in common code.
The fancy recovery logic is arch specific, but blasting the memslot when userfault
is toggled on is not.
next prev parent reply other threads:[~2025-05-07 0:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 20:49 [PATCH v2 00/13] KVM: Introduce KVM Userfault James Houghton
2025-01-09 20:49 ` [PATCH v2 01/13] KVM: Add KVM_MEM_USERFAULT memslot flag and bitmap James Houghton
2025-05-07 0:01 ` Sean Christopherson
2025-05-28 15:21 ` James Houghton
2025-01-09 20:49 ` [PATCH v2 02/13] KVM: Add KVM_MEMORY_EXIT_FLAG_USERFAULT James Houghton
2025-01-09 20:49 ` [PATCH v2 03/13] KVM: Allow late setting of KVM_MEM_USERFAULT on guest_memfd memslot James Houghton
2025-05-07 0:03 ` Sean Christopherson
2025-01-09 20:49 ` [PATCH v2 04/13] KVM: Advertise KVM_CAP_USERFAULT in KVM_CHECK_EXTENSION James Houghton
2025-01-09 20:49 ` [PATCH v2 05/13] KVM: x86/mmu: Add support for KVM_MEM_USERFAULT James Houghton
2025-05-07 0:05 ` Sean Christopherson [this message]
2025-05-28 20:21 ` Oliver Upton
2025-05-28 21:22 ` Sean Christopherson
2025-05-29 14:56 ` Sean Christopherson
2025-05-29 15:37 ` James Houghton
2025-01-09 20:49 ` [PATCH v2 06/13] KVM: arm64: " James Houghton
2025-05-07 0:06 ` Sean Christopherson
2025-05-28 15:09 ` James Houghton
2025-05-28 15:25 ` James Houghton
2025-05-28 17:30 ` Sean Christopherson
2025-05-28 20:17 ` James Houghton
2025-05-28 23:25 ` Sean Christopherson
2025-06-09 23:04 ` James Houghton
2025-01-09 20:49 ` [PATCH v2 07/13] KVM: selftests: Fix vm_mem_region_set_flags docstring James Houghton
2025-01-09 20:49 ` [PATCH v2 08/13] KVM: selftests: Fix prefault_mem logic James Houghton
2025-01-09 20:49 ` [PATCH v2 09/13] KVM: selftests: Add va_start/end into uffd_desc James Houghton
2025-01-09 20:49 ` [PATCH v2 10/13] KVM: selftests: Add KVM Userfault mode to demand_paging_test James Houghton
2025-01-09 20:49 ` [PATCH v2 11/13] KVM: selftests: Inform set_memory_region_test of KVM_MEM_USERFAULT James Houghton
2025-01-09 20:49 ` [PATCH v2 12/13] KVM: selftests: Add KVM_MEM_USERFAULT + guest_memfd toggle tests James Houghton
2025-01-09 20:49 ` [PATCH v2 13/13] KVM: Documentation: Add KVM_CAP_USERFAULT and KVM_MEM_USERFAULT details James Houghton
2025-05-06 23:48 ` [PATCH v2 00/13] KVM: Introduce KVM Userfault Sean Christopherson
2025-05-07 0:13 ` Sean Christopherson
2025-05-28 15:48 ` James Houghton
2025-05-29 15:28 ` Sean Christopherson
2025-05-29 16:17 ` James Houghton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBqj3s8THH9SFzLO@google.com \
--to=seanjc@google.com \
--cc=amoorthy@google.com \
--cc=corbet@lwn.net \
--cc=dmatlack@google.com \
--cc=jthoughton@google.com \
--cc=kalyazin@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pgonda@google.com \
--cc=wei.w.wang@intel.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.