Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Hemanth Selam <hemanth.selam@gmail.com>
To: seanjc@google.com, pbonzini@redhat.com, shuah@kernel.org
Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Hemanth Selam <hemanth.selam@gmail.com>
Subject: [PATCH v2 0/2] KVM: selftests: SEV: address two TODOs in the SEV tests
Date: Thu,  9 Jul 2026 23:19:53 +0530	[thread overview]
Message-ID: <20260709174955.628913-1-hemanth.selam@gmail.com> (raw)
In-Reply-To: <20260709164751.621326-1-hemanth.selam@gmail.com>

This small series fills in two pre-existing TODOs in the x86 SEV
selftests. Both are test-only changes; there is no functional change to
the kernel.

Patch 1 adds negative coverage to sev_init2_tests: when the platform
does not support a given SEV VM type (SEV-ES or SEV-SNP), it verifies
that KVM_CREATE_VM rejects that type with -EINVAL. Previously the test
only exercised the VM types that were supported, so a mismatch between
KVM_CAP_VM_TYPES and the actual KVM_CREATE_VM enforcement would have
gone unnoticed.

Patch 2 makes sev_smoke_test capture the launch measurement returned by
KVM_SEV_LAUNCH_MEASURE for SEV and SEV-ES guests and asserts that it is
not all zeros, instead of discarding it. A full attestation-style
validation is not possible from the selftest (userspace does not hold
the transport keys used to derive the measurement), but a non-zero
check catches a PSP/plumbing failure that silently leaves the buffer
untouched. SEV-SNP uses a different launch flow and is skipped.

Testing: built and run on an AMD EPYC 9755 (Turin) host running this
tree (7.2.0-rc2), with sev/sev_es/sev_snp all enabled. Both tests pass.
The new rejection path was additionally exercised by reloading kvm_amd
with sev_snp=0 so the unsupported types are rejected: under strace,
KVM_CREATE_VM for the SEV-ES and SNP types both return -EINVAL and the
test passes. checkpatch --strict is clean on both patches.

Changes in v2:
 - Patch 1: fix unreachable fd cleanup in test_create_invalid_type().
   TEST_ASSERT() aborts on failure, so the trailing "if (fd >= 0)
   close(fd)" could never run; close the fd (and latch errno) before
   the assert instead, so an unexpectedly-created VM is not leaked.
   Reported-by: Sashiko AI review.
 - Trimmed the added in-code comments to short high-level notes and
   moved the detailed rationale into the commit messages.
 - No functional change to patch 2.

v1: https://lore.kernel.org/all/20260709164751.621326-1-hemanth.selam@gmail.com/

Hemanth Selam (2):
  KVM: selftests: SEV: Verify unsupported VM types are rejected at
    creation
  KVM: selftests: SEV: Sanity check the launch measurement

 .../selftests/kvm/x86/sev_init2_tests.c       | 27 +++++++++++++++++--
 .../selftests/kvm/x86/sev_smoke_test.c        | 23 +++++++++++++++--
 2 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.43.7


  parent reply	other threads:[~2026-07-09 17:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 16:47 [PATCH v1 0/2] KVM: selftests: SEV: address two TODOs in the SEV tests Hemanth Selam
2026-07-09 16:47 ` [PATCH v1 1/2] KVM: selftests: SEV: Verify unsupported VM types are rejected at creation Hemanth Selam
2026-07-09 16:47 ` [PATCH v1 2/2] KVM: selftests: SEV: Sanity check the launch measurement Hemanth Selam
2026-07-09 17:49 ` Hemanth Selam [this message]
2026-07-09 17:49   ` [PATCH v2 1/2] KVM: selftests: SEV: Verify unsupported VM types are rejected at creation Hemanth Selam
2026-07-09 20:21     ` Sean Christopherson
2026-07-10  5:06     ` Hemanth Selam
2026-07-09 17:49   ` [PATCH v2 2/2] KVM: selftests: SEV: Sanity check the launch measurement Hemanth Selam
2026-07-10  5:04   ` [PATCH v3] KVM: selftests: Add a test for KVM_CREATE_VM VM type enforcement Hemanth Selam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260709174955.628913-1-hemanth.selam@gmail.com \
    --to=hemanth.selam@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox