On 11/3/23 15:19, Jim Fehlig wrote:
Hi Jonathon,
I too on occasion poke at SEV-SNP support in libvirt. I've now pushed the dusty,
hacky branch to my public fork
https://gitlab.com/jfehlig/libvirt/-/tree/sev-snp?ref_type=heads
Looking at the git log, it seems I fiddle with it every 2 months or so. It's
been that long since I last worked on the task, so I'm due to give it some
cycles next week :-).
On 10/28/23 08:49, Jonathon Jongsma wrote:
I'm currently looking at getting libvirt working with AMD's SEV-SNP encrypted
virtualization technology. I have access to a test machine with an AMD EPYC
7713 processor which I can use to launch SNP guests with qemu, but only when I
specify one of the following versioned -cpu values:
- EPYC-v4
- EPYC-Milan-v2
- EPYC-Rome-v3
From what I understand, the unversioned CPU models in qemu are supposed to
resolve to a specific versioned CPU model depending on the machine type. But
I'm not exactly sure how machine type influences it.
I've got some libvirt patches to launch an SEV-SNP guest working now except
for the CPU model specification. As far as I can tell, I can currently only
specify the un-versioned model in libvirt. Is there any way to request a
particular versioned CPU from qemu? I feel like I'm missing something here.
I should perhaps also mention that I'm running a development version of qemu
from Cole's copr repo[1], which could still have some related bugs
[1] https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/sev-snp-coconut/
Do you know the corresponding git branches the host packages are built from? One
of the biggest challenges I face is keeping track of the latest repos/branches
to use for all the snp and tdx work. I _think_ this is still the oracle for the
snp patches
https://github.com/AMDESE/AMDSEV/blob/snp-latest/stable-commits
Yes, seems to be the case. I noticed the head commit in the qemu branch is
commit bbc1bfb6bfb3cde4c22755cedd5b71e651ca35e8
Author: Cole Robinson <crobinso@xxxxxxxxxx>
Date: Fri Oct 13 13:53:26 2023 -0400
*sev: fix query-sev-capabilities as called by libvirt
The last time I tried starting a SNP guest using libvirt with my hacks, qemu
crashed when libvirt probed sev_get_capabilities.
Which fixed this issue :-). With the latest kernel, qemu, and ovmf referenced in
stable-commits, qemu fails when attempting to start a SNP guest via libvirt with
latest patches in my git branch
# virsh start snp-test
error: Failed to start domain 'snp-test'
error: internal error: QEMU unexpectedly closed the monitor (vm='snp-test'):
2023-11-07T00:01:06.888232Z qemu-system-x86_64: warning: creating ROM device
with private memory.
2023-11-07T00:01:06.888516Z qemu-system-x86_64: warning: kvm_create_gmemfd:
created memfd: 36, size: 37c000, flags: 0
2023-11-07T00:01:06.891968Z qemu-system-x86_64: warning: kvm_create_gmemfd:
created memfd: 38, size: 20000, flags: 0
2023-11-07T00:01:06.892215Z qemu-system-x86_64: warning: creating ROM device
with private memory.
2023-11-07T00:01:06.892256Z qemu-system-x86_64: warning: kvm_create_gmemfd:
created memfd: 40, size: 84000, flags: 0
2023-11-07T00:01:06.892949Z qemu-system-x86_64: warning: kvm_create_gmemfd:
created memfd: 42, size: 20000, flags: 0
2023-11-07T00:01:06.928511Z qemu-system-x86_64: kvm_set_user_memory_region:
KVM_SET_USER_MEMORY_REGION2 failed, slot=65536, start=0x0, size=0x80000000,
flags=0x0, gmem_fd=0, gmem_offset=0x0: Invalid argument (22)
kvm_set_phys_mem: error registering slot: Invalid argument
The memory backend is not being configured properly. From the qemu log file
-machine
pc-q35-7.1,usb=off,dump-guest-core=off,memory-backend=pc.ram,kvm-type=protected,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,hpet=off,acpi=on
\
-object
'{"qom-type":"memory-backend-file","id":"pc.ram","mem-path":"/var/lib/libvirt/qemu/ram/1-tw-snp-test/pc.ram","share":false,"x-use-canonical-path-for-ramblock-id":false,"size":8589934592}'
\
I'll continue poking on Wednesday. I've dedicated Tuesday to working on hardware
in our lab.
Regards,
Jim
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
