On Sat, Oct 28, 2023 at 09:49:32AM -0500, 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. There's two aspects - what QEMU is supposed todo and what libvirt was intended todo, and only the QEMU part really got done. On the QEMU side, when the user specifies an unversioned CPU model, QEMU shouuld expand that to a versioned model, based on a definition tied to the machine type. This ensures that if the machine type doesn't change, the CPU model expansion will be guest ABI-stable. Most non-libvirt users of QEMU use a non-versioned machine type though so they have no ABI stability guarantee for the machine type or the CPU model. Initially all CPUs were mapped to v1, and it was thought that newer machine types might map to newer CPU versions. Life it not that simple though, because choice of CPU version affects runability on any given host :-( IOW, if QEMU added a new machine type that changed the mapping to a -v2 CPU model, existing users of the unversioned machine type 'q35' might suddenly find themselves unable to run the guest. eg consider -v2 adds feature 'foo' which depends on a microcode update, and the user does not have the microcode present. Thus, in practice I think it is unlikely QEMU will ever do much with the machine <-> CPU version mappings. At the libvirt level though, we can do better. Since we record our expansions in the XML, we don't have to rely on the machine type mapping for ABI sability of the CPU models Libvirt could expand a non-versioned CPU model to any version it desires, as long as it records that expansion in the XML. This could mean libvirt can dynamically expand the non-versioned CPU, taking account of what the host microcode supports. Libvirt should also allow users to request a versioned CPU model directly of course. > 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. This is another example of where libvirt could do a better job at expansion. We ought to "do the right thing" and expand to a version that is compatible with SNP (somehow). While we should of course have a way for users to request a specific version, we should not expect users to care about versions - we must "do the right thing" with SNP (and TDX in future). With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
