On Wed, Dec 14, 2022, Ben Gardon wrote: > On Tue, Dec 13, 2022 at 4:59 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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...
