On 11/6/23 6:25 PM, Jim Fehlig wrote:
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
Cole would know for sure, but it's possible that the packages from this
repository include a couple different cherry-picked patch series.
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
In case it helps I've just pushed my rough libvirt branch to my gitlab
account as well. Be warned that some of it is still pretty rough and it
may be rewritten frequently. In fact, I just rebased it on top of my cpu
version patch series before I pushed, so I can't even guarantee that it
is currently in a working state. But for what it's worth, feel free to
look around and ping me if you have questions:
https://gitlab.com/jjongsma/libvirt/-/tree/sev-snp?ref_type=heads
Cheers,
Jonathon
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
