Setup up SEV-SNp failed to initialize ret=-22(EINVAL), but SEV-es can function

[pw0rld]

I'm currently encountering a persistent issue when attempting to boot up SEV-SNP and could not figure out what the cause might be. During boot-up, an error message appears signifying a failure in the process.

sudo ./launch-qemu.sh -sev-snp
32+0 records in
1+0 records out
512 bytes copied, 0.000187366 s, 2.7 MB/s
qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=255 -m 2048M,slots=5,maxmem=10240M 
-no-reboot -bios OVMF_CODE.fd -drive if=pflash,format=raw,unit=0,file=centos.fd -drive 
file=centos.qcow2,if=none,id=disk0,format=qcow2 -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true 
-device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object memory-backend-
memfd,id=ram1,size=2048M,share=true,prealloc=false -machine memory-backend=ram1 -object sev-snp-
guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -nographic -monitor pty -monitor unix:monitor,server,nowait
Mapping CTRL-C to CTRL-]
Launching VM ...
  /tmp/cmdline.4048
char device redirected to /dev/pts/5 (label compat_monitor0)
qemu-system-x86_64: warning: Number of hotpluggable cpus requested (255) exceeds the recommended cpus supported by KVM (64)
qemu-system-x86_64: sev_kvm_init: failed to initialize ret=-22 fw_error=0 ''
qemu-system-x86_64: failed to initialize kvm: Operation not permitted

The error message indicated that the return value was -22, which, as I discovered from this previous issue here, implies 'EINVAL'.

I have made several attempts to troubleshoot this error by also considering the Linux kernel, Qemu version, OVMF, and BIOS, but it seems like the issue is still present. Here's a detail of the host environment I am currently operating on:

Host kernel version: Linux sev-snp 6.9.0-rc1-1-snp+， patched from link, branch snp-latest Qemu version: QEMU emulator version 8.0.0, build from link, branch: snp-latest Ovmf: link branch: snp-latest Dmesg information:

dmesg | grep -i -e rmp -e sev
  [    0.000000] SEV-SNP: RMP table physical range [0x0000000036000000 - 0x00000000568fffff]
  [    0.019652] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.9.0-rc1-1-snp+ root=/dev/mapper/SnpMainGroup-rootvol splash=silent quiet security=apparmor mem_encrypt=on kvm_amd.sev=1 mitigations=auto
  [    1.311667] systemd[1]: Hostname set to <sev-snp>.
  [    2.270992] ccp 0000:42:00.1: sev enabled
  [    2.334791] ccp 0000:42:00.1: SEV firmware update successful
  [    4.181420] ccp 0000:42:00.1: SEV API:1.55 build:8
  [    4.181431] ccp 0000:42:00.1: SEV-SNP API:1.55 build:8
  [   15.565239] kvm_amd: SEV enabled (ASIDs 100 - 509)
  [   15.565241] kvm_amd: SEV-ES enabled (ASIDs 1 - 99)
  [   15.565243] kvm_amd: SEV-SNP enabled (ASIDs 1 - 99)

cat /sys/module/kvm_amd/parameters/sev_snp
Y
cat /sys/module/kvm_amd/parameters/sev_es
Y
cat /sys/module/kvm_amd/parameters/sev
Y

lscpu
      Architecture:            x86_64
            CPU op-mode(s):        32-bit, 64-bit
            Address sizes:         43 bits physical, 48 bits virtual
            Byte Order:            Little Endian
      CPU(s):                  64
            On-line CPU(s) list:   0-63
      Vendor ID:               AuthenticAMD
            Model name:            AMD EPYC 7513 32-Core Processor

Additionally, I'd like to point out that initial SEV-SNP initialization seems successful according to the dmesg information, however the subsequent steps still yield the same boot-up error. I've noticed that in the same environment, SEV-ES and SEV setup executes without any problems, only SEV-SNP seems to be affected.

I suspect that the problem I am experiencing could be related to the SEV firmware. This presumption arises from the fact that, following the recent update to the latest kernel, my SEV firmware was also automatically upgraded. Previously, the firmware version was 1.51, but it has since been updated to 1.55. Despite my efforts to understand and resolve this problem, it persists. Any guidance or suggestions on how to troubleshoot and rectify this issue would be greatly appreciated.

[DiWangShePi]

I also encountered a similar problem

[tlendacky]

Be sure that your Qemu and Linux are kept in sync. If you recently updated the kernel without updating Qemu or vice versa, you're probably running into a KVM_SEV_INIT vs KVM_SEV_INIT2 usage issue.

[pw0rld]

Be sure that your Qemu and Linux are kept in sync. If you recently updated the kernel without updating Qemu or vice versa, you're probably running into a KVM_SEV_INIT vs KVM_SEV_INIT2 usage issue.

Indeed, you were correct. Thank you! Because of my oversight, I had not rebuilt my qemu success since the conflict issue to my local workspace. Now, having merged the latest version, everything is functionally smoothly. 👍 :)