Re: Versioned CPU types in libvirt
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 :|