From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: pbonzini@redhat.com, peterx@redhat.com,
rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v3 2/3] KVM: Skip invoking shared memory handler for entirely private GFN ranges
Date: Mon, 25 Aug 2025 14:05:22 -0700 [thread overview]
Message-ID: <aKzQEi4fykQwvqLE@google.com> (raw)
In-Reply-To: <20250822080235.27274-1-yan.y.zhao@intel.com>
On Fri, Aug 22, 2025, Yan Zhao wrote:
> When a GFN range is entirely private, it's unnecessary for
> kvm_handle_hva_range() to invoke handlers for the GFN range, because
> 1) the gfn_range.attr_filter for the handler is KVM_FILTER_SHARED, which
> is for shared mappings only;
> 2) KVM has already zapped all shared mappings before setting the memory
> attribute to private.
>
> This can avoid unnecessary zaps on private mappings for VMs of type
> KVM_X86_SW_PROTECTED_VM, e.g., during auto numa balancing scans of VMAs.
This feels like the wrong place to try and optimize spurious zaps. x86 should
be skipping SPTEs that don't match. For KVM_X86_SW_PROTECTED_VM, I don't think
we care about spurious zpas, because that's a testing-only type that doesn't have
line of sight to be being a "real" type.
For SNP, we might care? But actually zapping private SPTEs would require
userspace to retain the shared mappings across a transition, _and_ be running
NUMA autobalancing in the first place. If someone actually cares about optimizing
this scenario, KVM x86 could track private SPTEs via a software-available bit.
We also want to move away from KVM_MEMORY_ATTRIBUTE_PRIVATE and instead track
private vs. shared in the gmem instance.
So I'm inclined to skip this...
> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
> ---
> virt/kvm/kvm_main.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index f769d1dccc21..e615ad405ce4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -620,6 +620,17 @@ static __always_inline kvm_mn_ret_t kvm_handle_hva_range(struct kvm *kvm,
> gfn_range.slot = slot;
> gfn_range.lockless = range->lockless;
>
> +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> + /*
> + * If GFN range are all private, no need to invoke the
> + * handler.
> + */
> + if (kvm_range_has_memory_attributes(kvm, gfn_range.start,
> + gfn_range.end, ~0,
> + KVM_MEMORY_ATTRIBUTE_PRIVATE))
> + continue;
> +#endif
> +
> if (!r.found_memslot) {
> r.found_memslot = true;
> if (!range->lockless) {
> --
> 2.43.2
>
next prev parent reply other threads:[~2025-08-25 21:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 8:01 [PATCH v3 0/3] KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking Yan Zhao
2025-08-22 8:02 ` [PATCH v3 1/3] " Yan Zhao
2025-08-25 20:42 ` Sean Christopherson
2025-08-26 1:22 ` Yan Zhao
2025-08-22 8:02 ` [PATCH v3 2/3] KVM: Skip invoking shared memory handler for entirely private GFN ranges Yan Zhao
2025-08-25 21:05 ` Sean Christopherson [this message]
2025-08-26 6:51 ` Yan Zhao
2025-08-22 8:03 ` [PATCH v3 3/3] KVM: selftests: Test resetting dirty ring in gmem slots in protected VMs Yan Zhao
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=aKzQEi4fykQwvqLE@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=rick.p.edgecombe@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.