Re: [PATCH v2 0/9] RFC: Add versioned CPUs to libvirt
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