On Fri, Dec 15, 2023 at 04:11:57PM -0600, Jonathon Jongsma wrote: > Previously, the script only generated the parent CPU and any versions > that had a defined alias. The script now generates all CPU versions. Any > version that had a defined alias will continue to use that alias, but > those without aliases will use the generated name $BASECPUNAME-vN. > > The reason for this change is two-fold. First, we need to add new models > that support new features (such as SEV-SNP). To deal with this, the > script now generates model definitions for all versions. > > But we also need to ensure that our CPU definitions are migration-safe. > To deal with this issue we need to make sure we're always using the > canonical versioned names for CPUs. > > Qemu documentation states that unversioned names for CPU models (e.g. > 'EPYC') are actually aliases to a specific versioned CPU model (e.g. > 'EPYC-v1'). The documentation further states that the specific version > targeted by the alias may change based on the machine type of the > domain. Management software such as libvirt is directed to translate > these aliases to a concrete version in order to make sure that the CPU > definition is safe when migrating between different qemu versions that > may make different choices for which underlying versioned model > represents the alias. Our CPU models are already migration safe, since we expand the unversioned machine type to a versioned machine, and thus as a result our unversioned CPU model is implicitly turned into the versioned CPU model associated with that versioned machine type. It is still compelling for libvirt to deal with versioned CPU models, but we don't directly need that in order to be migration safe. Where versioned models are interesting is if the applicatio does not care about the specific machine type, so just asks for 'q35', but /does/ care about a specific CPU model in order to establish migration compat between a certain set of hosts. Letting them give a versioned CPU model gives more direct control which is good. > > In practice, at the time of writing qemu always maps the unversioned > aliases to the -v1 model. And libvirt's CPU model definitions also > assume that this is the case. For example, the 'x86_EPYC.xml' file > contains the features that are defined for the EPYC-v1 inside of qemu. > But if qemu ever changes their alias mapping, libvirt's idea of what an > 'EPYC' CPU means and qemu's idea of what an 'EPYC' CPU means will no > longer match. So when choosing a CPU model for a domain, we should > always pass the canonical versioned name to libvirt rather than the > unversioned alias. To enable this, the script will generate a new > 'canonical_name' field to the CPU model xml definition. > > Signed-off-by: Jonathon Jongsma <jjongsma@xxxxxxxxxx> > --- > src/cpu_map/sync_qemu_models_i386.py | 42 ++++++++++++++++++++++------ > 1 file changed, 34 insertions(+), 8 deletions(-) Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> 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 :| _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
