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 The last time I tried starting a SNP guest using libvirt with my hacks, qemu crashed when libvirt probed sev_get_capabilities. Do you have any libvirt patches for early review/testing? I also have access to a SNP-capable test machine. Regards, Jim