From: Sean Christopherson <seanjc@google.com>
To: Ben Gardon <bgardon@google.com>
Cc: David Matlack <dmatlack@google.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
Vipin Sharma <vipinsh@google.com>
Subject: Re: [PATCH 2/7] KVM: x86/MMU: Move rmap_iterator to rmap.h
Date: Thu, 15 Dec 2022 00:34:30 +0000 [thread overview]
Message-ID: <Y5prluKIKax5o8N9@google.com> (raw)
In-Reply-To: <CANgfPd9xkRgm691Hy=Zbk=SAx-gaW-Hkk0XWQE0UsH9mJwLU-A@mail.gmail.com>
On Wed, Dec 14, 2022, Ben Gardon wrote:
> On Tue, Dec 13, 2022 at 4:59 PM Sean Christopherson <seanjc@google.com> wrote:
> > And if we rename pte_list_head, then we might as well commit 100% and use consisnent
> > nomenclature across the board, e.g. end up with
...
> I'd be happy to see some consistent SPTE-based naming in the Shadow
> MMU and more or less get rid of the rmap naming scheme. Once you
> change to spte_list_head or whatever, the use of the actual rmap (an
> array of spte_list_heads) becomes super narrow.
Yeah. And at least for me, the more literal "walk a list of SPTEs" is much
easier for me to wrap my head around than "walk rmaps".
> Given the potential for enormous scope creep on what's already going
> to be a long series, I'm inclined to split this work into two parts:
> 1. Move code from mmu.c to shadow_mmu.c with minimal cleanups /
> refactors / renames; just move the code
> 2. Clean up naming conventions: make the functions exported in
> shadow_mmu.h consistent, get rid of the whole rmap naming scheme, etc.
>
> That way git-blame will preserve context around the renames /
> refactors which would be obfuscated if we did 2 before 1,
+1
> and we can reduce merge conflicts.
That might be wishful thinking ;-)
One thought for the rename would be to gather all the reviews and feedback, and
then wait to send the final version until shortly before the merge window, i.e.
wait for everything else to land so that only future development gets affected.
That would give Paolo and I a bit of extra motiviation to get the x86 queue
solidified sooner than later too...
next prev parent reply other threads:[~2022-12-15 0:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 17:35 [PATCH 0/7] KVM: x86/MMU: Factor rmap operations out of mmu.c Ben Gardon
2022-12-06 17:35 ` [PATCH 1/7] KVM: x86/MMU: Move pte_list operations to rmap.c Ben Gardon
2022-12-07 22:58 ` Vipin Sharma
2022-12-14 0:11 ` Ben Gardon
2022-12-09 22:22 ` David Matlack
2022-12-14 0:07 ` Ben Gardon
2022-12-06 17:35 ` [PATCH 2/7] KVM: x86/MMU: Move rmap_iterator to rmap.h Ben Gardon
2022-12-09 23:04 ` David Matlack
2022-12-14 0:12 ` Ben Gardon
2022-12-14 0:59 ` Sean Christopherson
2022-12-14 17:53 ` Ben Gardon
2022-12-15 0:34 ` Sean Christopherson [this message]
2022-12-06 17:35 ` [PATCH 3/7] KVM: x86/MMU: Move gfn_to_rmap() to rmap.c Ben Gardon
2022-12-09 23:32 ` David Matlack
2022-12-06 17:35 ` [PATCH 4/7] KVM: x86/MMU: Move rmap_can_add() and rmap_remove() " Ben Gardon
2022-12-06 17:35 ` [PATCH 5/7] KVM: x86/MMU: Move the rmap walk iterator out of mmu.c Ben Gardon
2022-12-06 17:36 ` [PATCH 6/7] KVM: x86/MMU: Move rmap zap operations to rmap.c Ben Gardon
2022-12-09 22:44 ` David Matlack
2022-12-06 17:36 ` [PATCH 7/7] KVM: x86/MMU: Move rmap_add() " Ben Gardon
2022-12-09 23:27 ` David Matlack
2022-12-09 23:14 ` [PATCH 0/7] KVM: x86/MMU: Factor rmap operations out of mmu.c David Matlack
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=Y5prluKIKax5o8N9@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=vipinsh@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox