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".
