On 12/8/23 5:03 AM, Daniel P. Berrangé wrote:
On Thu, Dec 07, 2023 at 04:07:48PM -0600, Jonathon Jongsma wrote:
For SEV-SNP support we will need to be able to specify versioned CPU models
that are not yet available in libvirt. Rather than just adding a versioned CPU
or two that would satisfy that immediate need, I decided to try to add
versioned CPUs in a more standard way. This series generates CPU definitions
for all cpu versions that are defined in upstream qemu (at least for
recent Intel and AMD CPUs).
libvirt already provides a select subset of these versions as configurable CPU
models. But we only include the ones that have defined aliases in qemu, such as
EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu
will be available in libvirt.
Note that I'm only adding versions that are not already available via their
alias. For example, I am not adding an EPYC-v2 CPU model since it is already
available as EPYC-IBPB.
That is not reliable, as the alias mapping between a short name "EPYC"
and a version is set by the choice of machine type.
ie one machine type might map EPYC to v1, and another machine type
might map EPYC to v2.
It just happens to be the case that currently all machine types have
the same alias expansion, but that's not guaranteed.
So if we're going down this route, we need to bring in all versioned
machine types.
I suppose this is true, but it doesn't seem meaningfully different than
our current situation where we have already introduced a subset of
versioned types. It's just that we've only added the ones with
human-readable names. So while this patch doesn't solve the issue you
mentioned, I don't think that it makes the situation any worse. We are
already susceptible to any changes that qemu might make with respect to
machine-specific CPU aliases. But I'll try to figure out a more
comprehensive approach.
Jonathon
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
