Re: [PATCH] KVM: nSVM: Reset the virtual VMLOAD/VMSAVE bit in vmcb02 on every nested VMRUN

[Amirmohammad Eftekhar]

On Wed, Oct 22, 2026, Yosry Ahmed wrote:
> So this test case passing should be confirming my allegation that
> intercepts take precedence over VLS.

I could be missing something, but a hardware repro points the other way,
at least on this part (Zen 4, Ryzen 5 PRO 8500GE, mainline 7.3-rc3). The
L2 runs "vmload; cpuid", so the exit code says whether VMLOAD was
intercepted (SVM_EXIT_VMLOAD, 0x82) or virtualized and run on to the
cpuid (SVM_EXIT_CPUID, 0x72):

  - Single VMRUN, vmcb12 VLS off, L1 intercepting VMLOAD: 0x82. The
    intercept is honored, as expected.
  - VMRUN #1 enables VLS legitimately (0x72), then VMRUN #2 with vmcb12
    VLS=0 and L1 intercepting VMLOAD: still 0x72. 3/3.

The difference from nested_vmsave_vmload_test.c is that the test only
looks at a single VMRUN. On VMRUN #2 vmcb12 has VLS off, so
nested_vmcb_needs_vls_intercept() returns true and
nested_vmcb02_recalc_intercepts() sets INTERCEPT_VMLOAD/VMSAVE in vmcb02.
But vmcb02->control.misc_ctl2 still has the VLS enable bit from VMRUN #1,
since it is only ever OR-set and never cleared, so vmcb02 enters VMRUN #2
with both INTERCEPT_VMLOAD and VLS set and the CPU virtualizes VMLOAD
anyway. That is the dropped intercept.

So with both bits live in the same vmcb02, VLS wins over the intercept on
this hardware, which is why I think the stale bit is an actual
intercept-drop (an L1 that intercepts VMLOAD/VMSAVE for its own L2 loses
that intercept after it has used VLS even once) rather than only untidy
state.

I haven't managed to square that with your reading of the test, so it is
entirely possible I am wrong about the precedence. If it helps I can send
the reproducer, or dump vmcb02->control (the intercept bitmap plus
misc_ctl2) right before the VMRUN #2 that virtualizes VMLOAD, so we can
confirm both bits are set going in.

Thanks,
Amirmohammad