This bug was initially created as a copy of Bug #1689341
I am copying this bug because the fix spans both kernel and qemu-kvm.
Description of problem:
Libvirt queries SEV support via QEMU's qmp_query_sev_capabilities command the result of which then reports in its domain capabilities. The problem is that QEMU returns success even if SEV is not enabled in the kernel module (although the platform supports it), so libvirt reports SEV as supported, but any attempt launching a SEV VM will fail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Take an AMD EPYC machine and disable SEV in the kernel
# cat /sys/module/kvm_amd/parameters/sev
2. make sure to clear libvirt capabilities
# systemctl stop libvirtd
# rm -f /var/cache/libvirt/qemu/capabilities
# systemctl restart libvirtd
3. check libvirt's domain capabilities
# virsh domcapabilities
4. try launching a sev VM
# virsh start <vm>
Failed to start domain <vm>
the following will be contained in the internal error reported by libvirt:
"sev_guest_init: failed to initialize ret=-25 fw_error=0 ''"
QEMU returns data about SEV making libvirt think SEV is supported on the platform while actually it is disabled in kernel
QEMU's qmp_query_sev_capabilities can already report "SEV feature is not available" error when it fails to provide the data to libvirt for some reason. The same error should be reported in this case too which will result in libvirt reporting <sev supported='no'> in the domain capabilities.
This is the plan:
(b) In the kernel, introduce a *VM-independent* KVM ioctl, for
checking whether KVM_MEMORY_ENCRYPT_OP is generally available.
This could take the form of e.g. a KVM_CHECK_EXTENSION ioctl,
with KVM_CAP_MEMORY_ENCRYPTION as arg. Then propagate this new
feature all the way from the host kernel through QEMU/QMP to
As I quoted above, the existent documentation for
"KVM_MEMORY_ENCRYPT_OP" starts with, "If the platform supports
creating encrypted VMs [...]" -- so introduce a way to query KVM
about that fact precisely (as a read-only operation).
I suppose this bug should be Future Feature request bug, can we add a Future Feature keyword? Thanks!
It's a small enhancement to error reporting so it will be 8.2 material, but I don't think it's FutureFeature.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks