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

[Yosry Ahmed]

On Thu, Aug 27, 2026 at 1:48 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> 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).

Isn't vmx_pages effectively per-vCPU state (for nested)?

>
> > [1]https://lore.kernel.org/kvm/20260728003557.1136583-29-yosry@xxxxxxxxxx