Bug 1598151

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Still relevant. Not sure how easy it is to implement this generally, if qemu has some API that reports the default CPU model or if libvirt has to hardcode it.

Kashyap is this still important? If so please move it to the upstream tracker, product=Virtualization Tools component=libvirt

Moving to upstream tracker, since Fedora doesn't do RFEs

QEMU doesn't report default CPU model against query-cpu-definitions since this varies per machine type and QMP probing is done with "none" machine type.

The challenge with hardcoding it is that we don't know if what libvirt hardcodes really matches what QEMU runs with later.

Machine types are not easily introspectable, but we have dealt with this on a case by case basis to expose some limited info via query-machines.

I think it would be viable to get this to expose default CPU model per machine type.

Proposed a QEMU patch that could help for libvirt https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg04906.html

Patches sent for review: https://www.redhat.com/archives/libvir-list/2019-October/msg00140.html

Acked version 3 of the series: https://www.redhat.com/archives/libvir-list/2019-November/msg00070.html

Implemented by

commit 5e939cea896fb3373a6f68f86e325c657429ed3d
Refs: v5.9.0-352-g5e939cea89
Author:     Jiri Denemark <jdenemar>
AuthorDate: Thu Sep 26 18:42:02 2019 +0200
Commit:     Jiri Denemark <jdenemar>
CommitDate: Wed Nov 20 17:22:07 2019 +0100

    qemu: Store default CPU in domain XML

    When starting a domain without a CPU model specified in the domain XML,
    QEMU will choose a default one. Which is fine unless the domain gets
    migrated to another host because libvirt doesn't perform any CPU ABI
    checks and the virtual CPU provided by QEMU on the destination host can
    differ from the one on the source host.

    With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
    a particular machine type and store it in the domain XML. This way the
    chosen CPU model is more visible to users and libvirt will make sure
    the guest will see the exact same CPU after migration.

    Architecture specific notes
    - aarch64: We only set the default CPU for TCG domains as KVM requires
      explicit "-cpu host" to work.

    - ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU,
      we will translate the default model to the model corresponding to the
      host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.).
      This is not a problem as the corresponding CPU model is in fact an
      alias for "host". This is probably not ideal, but it's not wrong and
      the default virtual CPU configured by libvirt is the same QEMU would
      use. TCG uses various CPU models depending on machine type and its
      version.

    - s390x: The default CPU for KVM is "host" while TCG defaults to "qemu".

    - x86_64: The default CPU model (qemu64) is not runnable on any host
      with KVM, but QEMU just disables unavailable features and starts
      happily.

    https://bugzilla.redhat.com/show_bug.cgi?id=1598151
    https://bugzilla.redhat.com/show_bug.cgi?id=1598162

    Signed-off-by: Jiri Denemark <jdenemar>
    Reviewed-by: Ján Tomko <jtomko>