Re: [PATCH 2/4] selftests/kvm: check that SEV-ES VMs are allowed in SEV-SNP mode

[Sean Christopherson <seanjc@google.com>]

On Wed, Feb 25, 2026, Tycho Andersen wrote:
> On Tue, Feb 24, 2026 at 10:02:28AM -0800, Sean Christopherson wrote:
> > Hmm, I like the idea of clearing supported_vm_types.  The wrinkle is that "legacy"
> > deployments that use KVM_SEV_INIT instead of KVM_SEV_INIT2 will use
> > KVM_X86_DEFAULT_VM, and probably won't check for SEV and SEV_ES VM types.
> 
> Does that matter?

Yes, but I don't think it matters so much that it's worth dealing with.  For me,
being slightly nicer to userspace doesn't justify the risk of confusing KVM.

> If in the case of CiphertextHiding we would revoke KVM_X86_SEV_VM, users
> already couldn't start a VM anyway in the configuration.
> 
> The firmware update is more tricky, but I don't think you can blame
> the kernel there...

Yeah, that's about where I'm at. 

> > Alternatively, or in addition to, we could clear X86_FEATURE_SEV_ES.  But clearing
> > SEV_ES while leaving X86_FEATURE_SEV_SNP makes me nervous.  KVM doesn't *currently*
> > check for any of those in kvm_cpu_caps, but that could change in the future.  And
> > it's somewhat misleading, e.g. because sev_snp_guest() expects sev_es_guest() to
> > be true.
> > 
> > Given that it doesn't make sense for KVM to actively prevent the admin from upgrading
> > the firmware, I think it's ok if KVM can't "gracefully" handle *every* case.  E.g.
> > even if KVM clears X86_FEATURE_SEV_ES, userspace could have cached that information
> > at system boot. 
> > 
> > > > Hrm, I think we also neglected to communicate when SEV and SEV-ES are effectively
> > > > unusable, e.g. due to CipherTextHiding, so maybe we can kill two birds with one
> > > > stone?  IIRC, we didn't bother enumerating the limitation with CipherTextHiding
> > > > because making SEV-ES unusable would require a deliberate act from the admin.
> > > 
> > > We know these parameters at module load time so we could unset the
> > > supported bit, but...
> > > 
> > > > "Update firmware" is also an deliberate act, but the side effect of SEV-ES being
> > > > disabled, not so much.
> > > 
> > > since this could be a runtime thing via DOWNLOAD_FIRMWARE_EX at some
> > > point, I guess we need a new RUNTIME_STATUS ioctl or similar. Then the
> > > question is: does it live in /dev/sev, or /dev/kvm?
> > 
> > Ugh.  Yeah, updating supported_vm_types definitely seems like the least-awful
> > option.
> 
> Since firmware update only happens on init right now, I think we can
> add a:
> 
>     int sev_firmware_supported_vm_types();
> 
> that will do the feature detection from the ccp, and merge that with
> the results based on asid assignments during module init.

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.

> We'll eventually need some callback into KVM to say say "hey the
> firmware got updated here's a new list of vm types".