From: Sean Christopherson <seanjc@google.com>
To: Tycho Andersen <tycho@kernel.org>
Cc: Ashish Kalra <ashish.kalra@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
John Allen <john.allen@amd.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 2/4] selftests/kvm: check that SEV-ES VMs are allowed in SEV-SNP mode
Date: Thu, 26 Feb 2026 14:28:03 -0800 [thread overview]
Message-ID: <aaDI83LDFj9Be-sH@google.com> (raw)
In-Reply-To: <aaC0KGXmfhOMOrJ9@tycho.pizza>
On Thu, Feb 26, 2026, Tycho Andersen wrote:
> On Wed, Feb 25, 2026 at 09:44:15AM -0800, Sean Christopherson wrote:
> > Ya, I don't have a better idea. Bleeding VM types into the CCP driver might be
> > a bit wonky, though I guess it is uAPI so it's certainly not a KVM-internal detail.
>
> Turns out this approach breaks the selftests, which is at least one
> userspace:
>
> # ./sev_init2_tests
> Random seed: 0x6b8b4567
> ==== Test Assertion Failure ====
> x86/sev_init2_tests.c:141: have_sev_es == !!(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM))
> pid=12498 tid=12498 errno=0 - Success
> 1 0x0000000000402747: main at sev_init2_tests.c:141 (discriminator 2)
> 2 0x00007f9adae2a1c9: ?? ??:0
> 3 0x00007f9adae2a28a: ?? ??:0
> 4 0x0000000000402934: _start at ??:?
> sev-es: KVM_CAP_VM_TYPES (15) does not match cpuid (checking 8)
>
> As near as I can tell qemu doesn't do the same anywhere. SNP guests
> run fine, and SEV-ES says something reasonable:
>
> qemu-system-x86_64: sev_launch_start: LAUNCH_START ret=1 fw_error=21 'Feature not supported'
> qemu-system-x86_64: sev_common_kvm_init: failed to create encryption context
> qemu-system-x86_64: failed to initialize kvm: Operation not permitted
>
> Thoughts?
Breaking selftests is totally fine, they don't count as real users (the whole
point is to validate KVM behavior; if we weren't allowed to break selftests, we
literally couldn't fix a huge pile of KVM bugs).
Even if a real VMM has a similar sanity check, I wouldn't consider an assertion
firing to be a breaking flaw. No matter what, the VMM won't be able to launch an
SEV-ES guest.
For selftests, something like this?
have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);
TEST_ASSERT(!have_sev_es || kvm_cpu_has(X86_FEATURE_SEV_ES),
"sev-es: SEV_ES_VM supported without SEV_ES in CPUID");
have_snp = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SNP_VM);
TEST_ASSERT(!have_snp || kvm_cpu_has(X86_FEATURE_SEV_SNP),
"sev-snp: SNP_VM supported with SEV_SNP in CPUID");
next prev parent reply other threads:[~2026-02-26 22:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 16:28 [PATCH 0/4] Allow setting RAPL_DIS during SNP_INIT_EX Tycho Andersen
2026-02-23 16:28 ` [PATCH 1/4] selftests/kvm: allow retrieving underlying SEV firmware error Tycho Andersen
2026-02-23 16:28 ` [PATCH 2/4] selftests/kvm: check that SEV-ES VMs are allowed in SEV-SNP mode Tycho Andersen
2026-02-23 16:36 ` Sean Christopherson
2026-02-23 16:48 ` Tycho Andersen
2026-02-23 17:15 ` Sean Christopherson
2026-02-23 22:12 ` Tycho Andersen
2026-02-24 18:02 ` Sean Christopherson
2026-02-25 17:29 ` Tycho Andersen
2026-02-25 17:44 ` Sean Christopherson
2026-02-26 20:59 ` Tycho Andersen
2026-02-26 22:28 ` Sean Christopherson [this message]
2026-02-23 16:28 ` [PATCH 3/4] crypto/ccp: support setting RAPL_DIS in SNP_INIT_EX Tycho Andersen
2026-02-23 16:40 ` Sean Christopherson
2026-02-23 22:14 ` Tycho Andersen
2026-02-24 17:50 ` Sean Christopherson
2026-02-25 18:05 ` Tycho Andersen
2026-02-23 16:29 ` [PATCH 4/4] selftests/kvm: smoke test support for RAPL_DIS Tycho Andersen
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=aaDI83LDFj9Be-sH@google.com \
--to=seanjc@google.com \
--cc=ashish.kalra@amd.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=tycho@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.