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