Re: [PATCH 06/11] KVM: x86: Move kvm_<reg>_{read,write}() definitions to x86.h

[Sean Christopherson <seanjc@google.com>]

On Tue, Apr 21, 2026, Yosry Ahmed wrote:
> On Thu, Apr 09, 2026 at 04:56:17PM -0700, Sean Christopherson wrote:
> > Move the direct GPR accessors to x86.h so that they can use
> > is_64_bit_mode().
> > 
> > No functional change intended.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/kvm_cache_regs.h | 34 ----------------------------------
> >  arch/x86/kvm/x86.h            | 34 ++++++++++++++++++++++++++++++++++
> 
> That's a shame, register accessors semantically fit in kvm_cache_regs.h,

Sort of.  I actually had the opposite reaction.  KVM very specifically doesn't
do available/dirty tracking for GPRs, in large part because it's not a caching
behavior per se: vcpu->arch.regs[] is _the_ source of truth for GPRs (modulo
RSP on Intel).

> but taking a step back.. is it even worth having kvm_cache_regs.h
> anymore?
> 
> At some point I needed to move guest mode helpers out of there too (as
> they should be):
> 
> https://lore.kernel.org/kvm/20260326031150.3774017-3-yosry@kernel.org/
> 
> With this patch and that one, we'd have <200 lines left. Is there a
> reason why it can't just be merged with x86.h? I don't see any of the
> headers included by x86.h including kvm_cache_regs.h.

What if we go in the opposite direction?  I didn't try moving e.g. is_64_bit_mode()
into kvm_cache_regs.h because that reaaaaaly stretches the meaning of "cache regs".

But if we rename kvm_cache_regs.h to something like kvm_regs.h, then I think we
can move more of the simpler accessors (and mutators?) into kvm_regs.h.  The
motivation would be to keep x86.h from becoming a chonker.  One of the regrets
with x86.c is that it became a dumping ground for everything that didn't have an
obvious home, and now it's sitting at nearly 15k LoC.

Naming is hard, but if we can come up with a kvm_blah.{h,c} pair, maybe we can
kill two birds with one stone?  Or at least kill one, and injure the other :-)