Bug 1731439 - QEMU should report an error and return failure if AMD SEV is not enabled in the kernel
Summary: QEMU should report an error and return failure if AMD SEV is not enabled in t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.3
Assignee: Paolo Bonzini
QA Contact: zixchen
URL:
Whiteboard:
Depends On: 1731440
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-19 12:27 UTC by Paolo Bonzini
Modified: 2020-11-17 17:45 UTC (History)
6 users (show)

Fixed In Version: qemu-kvm-5.1.0-2.module+el8.3.0+7652+b30e6901
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 17:45:27 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Paolo Bonzini 2019-07-19 12:27:51 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 1 Guo, Zhiyi 2019-08-01 05:39:26 UTC
Hi Paolo,

   I suppose this bug should be Future Feature request bug, can we add a Future Feature keyword? Thanks!

BR/
Zhiyi, Guo

Comment 2 Paolo Bonzini 2019-08-02 13:34:22 UTC
It's a small enhancement to error reporting so it will be 8.2 material, but I don't think it's FutureFeature.

Comment 3 Ademar Reis 2020-02-05 23:01:10 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

Comment 7 zixchen 2020-08-18 08:35:19 UTC
Test with qemu-kvm-4.2.0-32.module+el8.3.0+7629+c86ce105.x86_64, reported bug is not exits, test steps return RuntimeError: SEV launch security is not supported on this platform which is correct error report for this test.

Test version:
qemu-kvm-5.1.0-2.module+el8.3.0+7652+b30e6901.x86_64
kernel-4.18.0-232.el8.x86_64


Test steps:
. 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| grep sev
    <sev supported='no'/>
4. try launching a sev VM
virt-install --name rhel83sev --cpu EPYC-IBPB,-hypervisor --ram=4096 --memtune hard_limit=5000000 --vcpus=2,sockets=1,cores=1,threads=2 --boot uefi --machine q35 --noreboot --network bridge=br0 --os-variant rhel8.3 --os-type=linux --location=http://download.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/latest-RHEL-8.3.0/compose/BaseOS/x86_64/os/ --disk path=/home/rhel83sev.qcow2,bus=scsi,format=qcow2,cache=none,size=80 --controller type=scsi,model=virtio-scsi,driver.iommu=on --controller type=virtio-serial,driver.iommu=on --network network=default,model=virtio,driver.iommu=on --rng type=/dev/random,driver.iommu=on --memballoon driver.iommu=on --launchSecurity sev --graphics vnc,listen=0.0.0.0 --console unix,path=/tmp/rhel83sev,mode=bind --debug --extra-args console=ttyS0,115200
[Tue, 18 Aug 2020 03:23:40 virt-install 38372] DEBUG (cli:208) Launched with command line: /usr/share/virt-manager/virt-install --name rhel83sev --cpu EPYC-IBPB,-hypervisor --ram=4096 --memtune hard_limit=5000000 --vcpus=2,sockets=1,cores=1,threads=2 --boot uefi --machine q35 --noreboot --network bridge=br0 --os-variant rhel8.3 --os-type=linux --location=http://download.eng.bos.redhat.com/rhel-8/rel-eng/RHEL-8/latest-RHEL-8.3.0/compose/BaseOS/x86_64/os/ --disk path=/home/rhel83sev.qcow2,bus=scsi,format=qcow2,cache=none,size=80 --controller type=scsi,model=virtio-scsi,driver.iommu=on --controller type=virtio-serial,driver.iommu=on --network network=default,model=virtio,driver.iommu=on --rng type=/dev/random,driver.iommu=on --memballoon driver.iommu=on --launchSecurity sev --graphics vnc,listen=0.0.0.0 --console unix,path=/tmp/rhel83sev,mode=bind --debug --extra-args console=ttyS0,115200

Actual result:
[Tue, 18 Aug 2020 04:34:32 virt-install 64727] ERROR (cli:264) SEV launch security is not supported on this platform
[Tue, 18 Aug 2020 04:34:32 virt-install 64727] DEBUG (cli:266) 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-install", line 1009, in <module>
    sys.exit(main())
  File "/usr/share/virt-manager/virt-install", line 997, in main
    guest, installer = build_guest_instance(conn, options)
  File "/usr/share/virt-manager/virt-install", line 564, in build_guest_instance
    installer.set_install_defaults(guest)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 340, in set_install_defaults
    guest.set_defaults(None)
  File "/usr/share/virt-manager/virtinst/guest.py", line 746, in set_defaults
    self.launchSecurity.set_defaults(self)
  File "/usr/share/virt-manager/virtinst/domain/launch_security.py", line 56, in set_defaults
    return self._set_defaults_sev(guest)
  File "/usr/share/virt-manager/virtinst/domain/launch_security.py", line 39, in _set_defaults_sev
    raise RuntimeError(_("SEV launch security is not supported on this platform"))
RuntimeError: SEV launch security is not supported on this platform


Expected result:
Same with actual result.

Comment 8 zixchen 2020-08-18 08:39:16 UTC
Sorry, I made a tying error in Comment 7, this bug is verified by qemu-kvm-5.1.0-2.module+el8.3.0+7652+b30e6901.x86_64.

Comment 11 errata-xmlrpc 2020-11-17 17:45:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5137


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