A couple of fixes for nested VMLOAD/VMSAVE and a selftest that verifies
correct behavior. The test fails without patch 1.

Patch 4 is a proposed added WARNING, I am not sure if such warnings are
generally acceptable and if that's the correct place for it (hence RFC),
but I think it's useful to WARN if VMSAVE/VMLOAD are neither intercepted
nor virtualized by the CPU, because it means that the guest is directly
accessing host memory with them, a massive security hole.

The warning doesn't fire with or without the fixes, but at some point I
thought there might be such a security bug, and having a warning will
give me some peace of mind.

Yosry Ahmed (4):
  KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
  KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc
  KVM: selftests: Add a selftests for nested VMLOAD/VMSAVE
  RFC: KVM: SVM: WARN if VMSAVE/VMLOAD are not intercepted or
    virtualized

 arch/x86/kvm/svm/svm.c                        |  23 +-
 tools/testing/selftests/kvm/Makefile.kvm      |   1 +
 .../selftests/kvm/include/x86/processor.h     |   1 +
 .../kvm/x86/nested_vmsave_vmload_test.c       | 197 ++++++++++++++++++
 4 files changed, 218 insertions(+), 4 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86/nested_vmsave_vmload_test.c

-- 
2.52.0.457.g6b5491de43-goog

On Sat, 10 Jan 2026 00:48:17 +0000, Yosry Ahmed wrote:
> A couple of fixes for nested VMLOAD/VMSAVE and a selftest that verifies
> correct behavior. The test fails without patch 1.
> 
> Patch 4 is a proposed added WARNING, I am not sure if such warnings are
> generally acceptable and if that's the correct place for it (hence RFC),
> but I think it's useful to WARN if VMSAVE/VMLOAD are neither intercepted
> nor virtualized by the CPU, because it means that the guest is directly
> accessing host memory with them, a massive security hole.

Sanity checks in KVM are definitely acceptable/encourage, but this particular
check goes too far.  There are sooooo many things that KVM _must_ get right;
asserting on every single one without strong evidence that we're likely to
screw up without noticing isn't something I want to encourage.

In other words, for me, "the consequences are really bad" isn't sufficient
justification on its own, there also needs to be some amount of "we've botched
this multiple times in the past", "it's tricky to get right", and/or "this is a
low level API that makes assumptions about how the rest of KVM works".

> [...]

Applied 1-2 to kvm-x86 svm, and 3 to kvm-x86 selftests due to its dependency
on the selftests NPT support.  Note, this means running the selftests branch
without the fixes from the svm branch will fail.  Far from ideal, but IMO it's
not worth doing a merge for something that is unlikely to ever be a problem in
practice (and now I've jinxed myself).

[1/4] KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
      https://github.com/kvm-x86/linux/commit/127ccae2c185
[2/4] KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc
      https://github.com/kvm-x86/linux/commit/55780d8a1dcc
[3/4] KVM: selftests: Add a selftests for nested VMLOAD/VMSAVE
      https://github.com/kvm-x86/linux/commit/55058e32151f
[4/4] RFC: KVM: SVM: WARN if VMSAVE/VMLOAD are not intercepted or virtualized
      [DROPPED]

--
https://github.com/kvm-x86/linux/tree/next