On 3/1/24 10:13 AM, Daniel P. Berrangé wrote:
On Tue, Feb 20, 2024 at 05:08:02PM -0700, Jim Fehlig wrote:
On 12/15/23 15:11, 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.
Related to migration safety, do we need to be concerned with the expansion
of 'host-model' CPU? E.g. is it possible 'host-model' expands to EPYC before
introducing the new models, and EPYC-v4 afterwards? If so, what are the
ramifications of that?
Yes, I see that happening on my laptop in domcapabilities:
Currently libvirt reports:
<mode name='host-model' supported='yes'>
<model fallback='forbid'>Snowridge</model>
<vendor>Intel</vendor>
<maxphysaddr mode='passthrough' limit='46'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
...snip...
and after this series it reports:
<mode name='host-model' supported='yes'>
<model fallback='forbid'>Snowridge-v4</model>
<vendor>Intel</vendor>
<maxphysaddr mode='passthrough' limit='46'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
...snip...
That's not wrong per-se, becasue Snowrigde-v4 has a smaller
delta against my host CPU.
The problem is that libvirt updates the *live* XML for the
guest with this expansion. IIUC, if we now attempt to
live migrate to a compatible machine running older libvirt
the migrate will fail as old libvirt doesn't know the -v4
CPU.
I'm not sure how to address this ?
But don't we have this issue any time we add a new CPU model to libvirt?
Anytime there's a new model, it has the potential to be a closer match
to the host CPU than an existing model definition was. As I mentioned in
my previous reply, when e.g. the -noTSX CPU variants were added, didn't
the same sort of thing (potentially) happen? Or am I doing something
meaningfully different in this patch set than what happens in those
scenarios?
Jonathon
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
