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? 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...
> 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.
We'll eventually need some callback into KVM to say say "hey the
firmware got updated here's a new list of vm types".
Tycho
