From: Sean Christopherson <seanjc@google.com>
To: Takahiro Itazuri <itazur@amazon.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Fuad Tabba <tabba@google.com>,
Brendan Jackman <jackmanb@google.com>,
David Hildenbrand <david@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Paul Durrant <pdurrant@amazon.com>,
Nikita Kalyazin <kalyazin@amazon.com>,
Patrick Roy <patrick.roy@campus.lmu.de>,
Takahiro Itazuri <zulinx86@gmail.com>
Subject: Re: [RFC PATCH v3 5/6] KVM: Rename mn_* invalidate-related fields to generic ones
Date: Wed, 11 Mar 2026 13:57:30 -0700 [thread overview]
Message-ID: <abHXOvAaK3X2FIkt@google.com> (raw)
In-Reply-To: <20260310064403.22218-1-itazur@amazon.com>
On Tue, Mar 10, 2026, Takahiro Itazuri wrote:
> The addition of guest_memfd support to pfncaches introduces additional
> sources of pfncache invalidation beyond the MMU notifier path. The
> existing mn_* naming implies that they are only relevant to MMU
> notifiers, which is no longer true.
I very strongly disagree. Except for kvm_swap_active_memslots() and
kvm_create_vm(), literally every function here has mmu_notifier in its name.
They no longer are used only the for the _kernel's_ MMU-notifier implementation,
but they're still very much scoped explicitly to KVM's overarching MMU notification
system.
If we want to come up with a "better" name, then it needs to capture that somewhere
in the prefix. Because e.g. invalidate_lock is way, way too generic. I read that
and my very first question is "ivalidate what, exactly?". Ditto for
memslots_update_rcuwait and pretty much every other field.
next prev parent reply other threads:[~2026-03-11 20:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 6:36 [RFC PATCH v3 0/6] KVM: pfncache: Add guest_memfd support to pfncache Takahiro Itazuri
2026-03-10 6:41 ` [RFC PATCH v3 1/6] KVM: pfncache: Resolve PFNs via kvm_gmem_get_pfn() for gmem-backed GPAs Takahiro Itazuri
2026-03-10 6:43 ` [RFC PATCH v3 2/6] KVM: pfncache: Obtain KHVA via vmap() for gmem with NO_DIRECT_MAP Takahiro Itazuri
2026-03-10 6:43 ` [RFC PATCH v3 3/6] KVM: Rename invalidate_begin to invalidate_start for consistency Takahiro Itazuri
2026-03-11 20:53 ` Sean Christopherson
2026-03-12 14:17 ` Takahiro Itazuri
2026-03-10 6:43 ` [RFC PATCH v3 4/6] KVM: pfncache: Rename invalidate_start() helper Takahiro Itazuri
2026-03-10 6:44 ` [RFC PATCH v3 5/6] KVM: Rename mn_* invalidate-related fields to generic ones Takahiro Itazuri
2026-03-11 20:57 ` Sean Christopherson [this message]
2026-03-12 14:33 ` Takahiro Itazuri
2026-03-10 6:44 ` [RFC PATCH v3 6/6] KVM: pfncache: Invalidate on gmem invalidation and memattr updates Takahiro Itazuri
2026-03-11 12:04 ` [RFC PATCH v3 0/6] KVM: pfncache: Add guest_memfd support to pfncache David Woodhouse
2026-03-12 14:02 ` [RFC PATCH v3 0/6] KVM: pfncache: Add guest_memfd support to Takahiro Itazuri
2026-03-11 22:32 ` [RFC PATCH v3 0/6] KVM: pfncache: Add guest_memfd support to pfncache Sean Christopherson
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=abHXOvAaK3X2FIkt@google.com \
--to=seanjc@google.com \
--cc=david@kernel.org \
--cc=dwmw2@infradead.org \
--cc=itazur@amazon.com \
--cc=jackmanb@google.com \
--cc=kalyazin@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=patrick.roy@campus.lmu.de \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.com \
--cc=tabba@google.com \
--cc=vkuznets@redhat.com \
--cc=zulinx86@gmail.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.