Bug 1852311 - virNodeGetSEVInfo API return error and can not get the information
Summary: virNodeGetSEVInfo API return error and can not get the information
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 8.3
Assignee: Erik Skultety
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-30 06:16 UTC by yalzhang@redhat.com
Modified: 2020-11-17 17:49 UTC (History)
4 users (show)

Fixed In Version: libvirt-6.6.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 17:49:34 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description yalzhang@redhat.com 2020-06-30 06:16:12 UTC
Description of problem:
virNodeGetSEVInfo API  return error and can not get the information

Version-Release number of selected component (if applicable):
# rpm -q python3-libvirt libvirt-libs
python3-libvirt-6.0.0-1.module+el8.2.0+5453+31b2b136.x86_64
libvirt-libs-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64

How reproducible:
100%

Steps to Reproduce:
1. On a host supports "SEV", add “amd_iommu=on kvm_amd.sev=1” in kernel cmd line and reboot the host;

2. check the setting exists:
# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.18.0-193.10.1.el8_2.x86_64 root=/dev/mapper/rhel_amd--daytona--06-root ro crashkernel=auto resume=/dev/mapper/rhel_amd--daytona--06-swap rd.lvm.lv=rhel_amd-daytona-06/root rd.lvm.lv=rhel_amd-daytona-06/swap console=ttyS0,115200n81 amd_iommu=on kvm_amd.sev=1

3. check the sev related information:
 # ll -Z /dev/sev
crw-------. 1 root root system_u:object_r:sev_device_t:s0 10, 57 Jun 29 21:40 /dev/sev

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

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

4. There is no guest defined in the system, check virNodeGetSEVInfo API function:
# python3
Python 3.6.8 (default, Dec  5 2019, 15:45:45) 
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> con = libvirt.open()
>>> con.getSEVInfo()
libvirt: QEMU Driver error : invalid argument: unable to find any emulator to serve 'x86_64' architecture
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 4235, in getSEVInfo
    if ret is None: raise libvirtError ('virNodeGetSEVInfo() failed', conn=self)
libvirt.libvirtError: invalid argument: unable to find any emulator to serve 'x86_64' architecture
>>> 

Actual results:
in step 4, the con.getSEVInfo() return error

Expected results:
it should get the correct information like "
{...
 'cbitpos': 47,
 'reduced-phys-bits': 1}"

Additional info:
After define a guest, the virNodeGetSEVInfo API can get the expected information.

Comment 1 Jaroslav Suchanek 2020-07-01 21:32:07 UTC
Erik, since you implemented the libvirt part. Is this gap in libvirt-python bindings? Thanks.

Comment 2 Erik Skultety 2020-07-02 09:20:00 UTC
(In reply to Jaroslav Suchanek from comment #1)
> Erik, since you implemented the libvirt part. Is this gap in libvirt-python
> bindings? Thanks.

I need to get access to an SEV-capable machine to confirm or refute that. Looking at the code the problem very likely originates in the driver's cache in core libvirt, but that one is taken from the connection object's private data. I'll investigate at which end the problem comes from.

Comment 3 Erik Skultety 2020-07-03 13:17:14 UTC
The problem is that you don't have any capabilities generated. Normally, we'd generated them when they're missing, but qemuNodeGetSEVInfo() failed to do it properly.

Posted an upstream fix to libvirt:
https://www.redhat.com/archives/libvir-list/2020-July/msg00168.html

Comment 4 Erik Skultety 2020-07-08 08:58:42 UTC
Fixed upstream by:

commit f3d838237d55ee636163825c1e4ee573d8437968
Refs: v6.5.0-43-gf3d838237d
Author:     Erik Skultety <eskultet@redhat.com>
AuthorDate: Fri Jul 3 14:26:13 2020 +0200
Commit:     Erik Skultety <eskultet@redhat.com>
CommitDate: Wed Jul 8 10:55:07 2020 +0200

    qemu: Use virQEMUCapsCacheLookupDefault instead of lookup by arch
    
    Firstly, SEV is present only on AMD, so we can safely assume x86.
    Secondly, the problem with looking up capabilities in the cache by arch
    is that it's using virHashSearch with a callback to find the right
    capabilities and get the binary name from it as well, but since the
    cache is empty, it will return NULL and we won't get the corresponding
    binary name out of the lookup either. Then, during the cache validation
    we try to create a new cache entry for the emulator, but since we don't
    have the binary name, nothing gets created.
    Therefore, virQEMUCapsCacheLookupDefault is used to fix this issue,
    because it doesn't rely on the capabilities cache to construct the
    emulator binary name.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1852311
    
    Signed-off-by: Erik Skultety <eskultet@redhat.com>
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Comment 7 yalzhang@redhat.com 2020-08-11 05:42:39 UTC
test on:
# rpm -q libvirt-libs python3-libvirt
libvirt-libs-6.6.0-2.module+el8.3.0+7567+dc41c0a9.x86_64
python3-libvirt-6.6.0-1.module+el8.3.0+7572+bcbf6b90.x86_64

on system support SEV, test with below steps:
# rmmod kvm_amd
# modprobe kvm_amd sev=1
# ll -Z  /dev/sev
crw-------. 1 root root system_u:object_r:sev_device_t:s0 10, 60 Aug 11  2020 /dev/sev
# cat  /sys/module/kvm_amd/parameters/sev
1

# python3
Python 3.6.8 (default, Jun 26 2020, 12:10:09) 
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> con = libvirt.open()
>>> con.getSEVInfo()
{'pdh': 'AQAAAAAWAAADEAAAAwAAAAIAAADjMa5EBdErta4MeoeduMCZyGLlum5SL1lULFczhWV5JtPA979TRIEJzwNgpCXBLTsAAA..(very long string)..AAAA', 
'cert-chain': 'AQAAAA....(very long string)..AAAA',
'cbitpos': 47, 
'reduced-phys-bits': 1}

the result is as expected, set the bug to be verified.

Comment 10 errata-xmlrpc 2020-11-17 17:49:34 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.