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. >> Also, setjmp/longjmp felt like it was introducing state that could be messed >> up easily. > > Meh, same goes for the kselftests_harness.h. I can point you at a half dozen > bugs where enhancements to the core framework wreaked havoc for unsuspecting > subsystems. I'm not trying to throw shade at the harness; there's a _lot_ of > goodness in there. My point is that doing complex things that impact a huge > variety of downstream users is going to have many sharp edges, regardless of > where the complexity resides. > > I'm not wedded to setjmp/longjmp by any means, but for me this isn't a > compelling > argument against the approach. > >> I also found recent work that removed setjmp/longjmp from kselftest harness >> [2]. > > KVM selftests don't support building with nolibc. > Not particularly against setting it up with setjmp/longjmp either, I think the discussion here is mostly between 1. Wrap kselftest_harness for KVM 2. Improving kselftest_harness so KVM can benefit from it setjmp/longjmp has already been removed from kselftest_harness so that option doesn't make sense if we go with (2). If we go with (1), I could (a) store the _metadata pointer in a global variable within KVM or (b) go with setjmp/longjmp (c) some other suggestion. >> The kselftests harness is running tests sequentially anyway, and the >> function pointers in _metadata wouldn't be changing all that often in most >> selftests. >> >> Would maintainers be open to having the kselftest harness expose a pointer >> to the metadata globally? >> >> 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"? 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.
