[PATCH 00/10] KVM: selftests: Convert to kernel-style types

[David Matlack]

On Thu, Nov 13, 2025 at 4:52 PM Sean Christopherson <seanjc at google.com> wrote:
>
> On Fri, Oct 17, 2025, David Matlack wrote:
> > On Thu, May 1, 2025 at 2:03 PM Sean Christopherson <seanjc at google.com> wrote:
> > > On Thu, May 01, 2025, David Matlack wrote:
> > > > This series renames types across all KVM selftests to more align with
> > > > types used in the kernel:
> > > >
> > > >   vm_vaddr_t -> gva_t
> > > >   vm_paddr_t -> gpa_t
> > >
> > > 10000% on these.
> > >
> > > >   uint64_t -> u64
> > > >   uint32_t -> u32
> > > >   uint16_t -> u16
> > > >   uint8_t  -> u8
> > > >
> > > >   int64_t -> s64
> > > >   int32_t -> s32
> > > >   int16_t -> s16
> > > >   int8_t  -> s8
> > >
> > > I'm definitely in favor of these renames.  I thought I was the only one that
> > > tripped over the uintNN_t stuff; at this point, I've probably lost hours of my
> > > life trying to type those things out.
> >
> > What should the next step be here? I'd be happy to spin a new version
> > whenever on whatever base commit you prefer.
>
> Sorry for the slow reply, I've had this window sitting open for something like
> two weeks.

No worries, thanks for taking a look :)

>
> My slowness is largely because I'm not sure how to land/approach this.  I'm 100%
> in favor of the renames, it's the timing and coordination I'm unsure of.
>
> In hindsight, it probably would have best to squeeze it into 6.18, so at least
> the most recent LTS wouldn't generate conflicts all over the place.  The next
> best option would probably be to spin a new version, bribe Paolo to apply it at
> the end of the next merge window, and tag the whole thing for stable@ (maybe
> limited to 6.18+?) to minimize downstream pain.

With LPC coming up I won't have cycles to post a new version before
the 6.19 merge window closes.

I'm tempted to say let's just wait for the next LTS release and merge
it in then. This is low priorit, so I'm fine with waiting.