[libvirt] What is the strategy to update the CPU Models in src/cpu/cpu_map.xml based on?

[Jiri Denemark]

On Wed, May 30, 2018 at 12:55:19 -0300, Eduardo Habkost wrote:
> The main question that I'm still unable to answer is: when
> cpu_map.xml is still used?  Does it affect libvirt behavior in
> any way when using a recent QEMU version?

Yes, it is still used. Mainly for reporting host CPU capabilities (even
those retrieved from QEMU), because we only get a list of features (both
from QEMU and CPUID) and need to somehow choose a corresponding CPU
model.

And its also partially used to check whether a particular CPU can be
provided on the host when we start a domain. But this checking is done
mostly for backward compatibility and it is not very strict, the final
decision of what can or cannot be used is on QEMU. In other words, we
accept any feature which is either supported by the host CPU (using
CPUID) or reported by QEMU as enabled for the "host" CPU model. Any
requested features which cannot be provided by QEMU would just be
disabled in the virtual CPU. This is of course all about the default
check='partial'. Libvirt doesn't do any checks with check='full' and
just asks QEMU whether it disabled any requested features.

> Is the file considered part of the libvirt API?

The file format is not considered an API and it can change, but the CPU
models, features and any other names defined there which can be used to
describe a CPU are an API similarly to domain XML, for example. That is,
each name has the same meaning across all versions of libvirt which
support it.

Jirka