Bug 1731440 - QEMU should report an error and return failure if AMD SEV is not enabled in the kernel [NEEDINFO]
Summary: QEMU should report an error and return failure if AMD SEV is not enabled in t...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Paolo Bonzini
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-19 12:27 UTC by Paolo Bonzini
Modified: 2020-02-10 09:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
coli: needinfo? (pbonzini)


Attachments (Terms of Use)

Description Paolo Bonzini 2019-07-19 12:27:57 UTC
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):
libvirt-5.1.0
qemu-kvm-3.1.0

How reproducible:


Steps to Reproduce:
1. Take an AMD EPYC machine and disable SEV in the kernel

# cat /sys/module/kvm_amd/parameters/sev
0

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

<features>
  ...
    <sev supported='yes'>
      <cbitpos>47</cbitpos>
      <reducedPhysBits>1</reducedPhysBits>
    </sev>
...
  </features>

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

Actual results:
QEMU returns data about SEV making libvirt think SEV is supported on the platform while actually it is disabled in kernel

Expected results:
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.

Additional info:
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
        libvirt.

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

Comment 2 Ademar Reis 2020-02-05 23:01:13 UTC
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


Note You need to log in before you can comment on or make changes to this bug.