Re: [PATCH RFC 0/4] selftests: harness: Provide global metadata pointer to allow clean teardown from selftest libraries

[Sean Christopherson <seanjc@google.com>]

On Tue, May 19, 2026, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > On Tue, Apr 14, 2026, Ackerley Tng wrote:
> >> Sean suggested using setjmp and longjmp [1] to back to the top level
> >> TEST_F(). I looked at [1] and found myself wishing to use TEST_F() the from
> >> kselftest harness directly.
> >
> > Can you elaborate?  If you have a need for direct TEST_F() in KVM selftests, odds
> > are good someone/something else will have a similar need, sooner or later.
> >
> 
> I guess I like the consistency of working with TEST_F(), there's also
> TEST_F_TIMEOUT() and friends and all the usefulness of the rest of the
> kselftest_harness as you described, all of which will probably need
> re-wrapping if we proceed with the approach of wrapping.

FWIW, utilizing the TIMEOUT functionality could get tricky.  KVM tests often have
highly variable runtimes based on the underlying environment.  E.g. as an extreme
case, see the never ending game of whack-a-mole we've been playing with flavors
of KVM-Unit-Tests' access test[*].

I can definitely see it being useful, e.g. for tests where we *know* the runtime
is O(ms), just want to call out that this is yet another case where KVM tests tend
to have more annoying requirements than other selftests.

[*] https://lore.kernel.org/all/20260317225327.4068448-1-yosry@kernel.org

> >> Another option would be to expose the current teardown function pointer
> >> globally instead of the pointer to the entire metadata struct.
> >
> > I'm strongly opposed to any idea effectively requires special casing KVM selftests
> > in the common harness.  In my experience, the common harness is already quite
> > brittle, in large part because there is no singular maintainer(s) that is responsible
> > for ensuring changes work for all downstream users.  Adding odd bits of code that
> > is only ever used by a handful of KVM selftests is only going to increase the
> > probability that that code is broken.
> 
> If Kees likes the idea of exposing a pointer to the metadata globally,
> does that make KVM selftests less "special"?

Yes.  I don't particuarly care about the code, I just don't want to be in a
situation where KVM is doing something "weird" relative to the rest of the world.

> If the community likes the global metadata pointer, I could update the
> harness to adopt the global metadata pointer and then KVM wouldn't be
> special at all.