FYI - On the Libvirt side the new 3.2 release has the following statement which is - at least -
related to the semantics of a host-* cpu specification. That is really a major change which we will unlikely SRU, but pick up naturally when we move to this or a later libvirt version - likely on aa-relase. On top this change still is x86_64 only for now, I'd expect further changes for other architectures down the road (CPU Feat detection is very different per arch anyway, so other arches might go different routes - but this sheds some light on some of the insufficiencies of the old detection at least).
So far just FYI:
- qemu: Detect host CPU model by asking QEMU on x86_64
Previously, libvirt detected the host CPU model using CPUID
instruction, which caused libvirt to detect a lot of CPU features that
are not supported by QEMU/KVM. Asking QEMU makes sure we don't start it
with unsupported features.
FYI - On the Libvirt side the new 3.2 release has the following statement which is - at least -
related to the semantics of a host-* cpu specification. That is really a major change which we will unlikely SRU, but pick up naturally when we move to this or a later libvirt version - likely on aa-relase. On top this change still is x86_64 only for now, I'd expect further changes for other architectures down the road (CPU Feat detection is very different per arch anyway, so other arches might go different routes - but this sheds some light on some of the insufficiencies of the old detection at least).
So far just FYI:
- qemu: Detect host CPU model by asking QEMU on x86_64
Previously, libvirt detected the host CPU model using CPUID
instruction, which caused libvirt to detect a lot of CPU features that
are not supported by QEMU/KVM. Asking QEMU makes sure we don't start it
with unsupported features.