On Tue, May 19, 2026, Ackerley Tng wrote: > Sean Christopherson <[email protected]> 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/[email protected] > >> 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.
