Re: [PATCH v3 13/13] KVM: selftests: Add and use double-underscore versions of vmlaunch() and vmresume()

[Sean Christopherson]

On Thu, Aug 27, 2026, Yosry Ahmed wrote:
> On Thu, Aug 27, 2026 at 1:28 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > Yeah.  Another idea would be:
> >
> >   void vmenter(bool do_vmlaunch)
> >   {
> >         if (do_vmlaunch)
> >                 vmlaunch();
> >         else
> >                 vmresume();
> >   }
> >
> > To yield:
> >
> >         vmenter(vector == SS_VECTOR);
> >         vmenter(!i);
> >
> > Never mind, that's a terrible idea, the call sites are inscrutable.
> 
> Yeah, but I do agree that vmlaunch() vs vmresume() handling in
> selftests is annoying (e.g. see run_l2() in [1]).
> 
> If you wanna go scorched earth on the nested VMX infra, what if we
> track launch vs resume (e.g. set launch=true in prepare_vmcs() and
> lauch=false in vmlaunch()), then provide a single vmenter() API for
> tests (with no arguments)?

For selftests, it would be much more difficult to do correctly, as compared to
KUT.  KUT has a "fixed" number of vCPUs, doesn't need to worry about pCPU:vCPU
bindings, and has a strong need for per-vCPU state for other reasons (because
it's more like per-pCPU state than per-vCPU state).

Selftests doesn't have per-vCPU state, so making the tracking thread-safe would
be challenging.  And I don't really want to add per-vCPU state because making
GS (or FS) off-limits is actually problematic when the goal is often to do "bad"
things to vCPU state (I've debugged weird KUT failures due to GS getting clobbered
more than once).
 
> [1]https://lore.kernel.org/kvm/20260728003557.1136583-29-yosry@xxxxxxxxxx