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@redhat.com> 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